Introduction: What is FRA Decision No. 139?
FRA Decision No. 139 is the Egyptian Financial Regulatory Authority's comprehensive mandatory framework for Information Technology, Governance, and Cybersecurity. It applies to all entities under FRA supervision — including insurance companies, capital market firms, fintech operators, and investment funds.
The decision defines 473 regulatory requirements across five domains. Non-compliance can result in regulatory sanctions, financial penalties, or suspension of operating licenses. This guide provides a practical, step-by-step roadmap to achieve and sustain full compliance.
How to Use This Guide
Each section below covers one regulatory domain and is structured as:
1What the regulation requires — the exact mandate
2How to implement it — practical steps and technology choices
3Evidence to collect — documents and artifacts required during audits
---
Domain 1: Infrastructure & Security Baseline (32 Requirements)
What It Requires
FRA 139 mandates a dedicated, licensed, highly available technology stack for all core systems — databases, application servers, and web servers — and requires robust perimeter and endpoint security.
Step-by-Step Implementation
Step 1: Audit Your Current Infrastructure
Inventory all servers (physical and virtual) hosting customer or financial data.
Identify which are dedicated vs. shared hosting environments.
Confirm operating system and database licenses are enterprise-grade.
Step 2: Achieve High Availability (HA)
Deploy database servers in Active/Active or Active/Passive HA clusters. Minimum recommendation: two nodes with automatic failover.
Application and web servers should be behind a load balancer with at least two instances in separate availability zones or physical racks.
Technology recommendations: Microsoft SQL Server AlwaysOn, Oracle RAC, or PostgreSQL with Patroni for databases; NGINX Plus or HAProxy for web-tier HA; on-premises Kubernetes or Docker Swarm for application HA. All hardware must be physically deployed within a data center located in Egypt.
Step 3: Deploy Perimeter Security
Install a Next-Gen Firewall (NGFW) at all network ingress/egress points. Configure it to perform deep packet inspection (DPI), application-layer filtering, and IPS rules.
Deploy a Web Application Firewall (WAF) in front of all public-facing applications. Configure OWASP Top 10 rule sets, rate limiting, and bot protection.
Technology recommendations: Palo Alto Networks PA-Series appliances, Fortinet FortiGate, Cisco Firepower (NGFW) — all deployed as on-premises hardware appliances; F5 Advanced WAF or Barracuda Web Application Firewall deployed on-premises or as a physical appliance in your Egypt-based data center.
Step 4: Deploy SIEM, EPP, and EDR
Implement SIEM to centralize log collection from all servers, network devices, and security tools. Configure correlation rules for detecting suspicious activity.
Deploy Endpoint Protection Platform (EPP) on all endpoints for real-time malware scanning and prevention.
Pair EPP with Endpoint Detection & Response (EDR) for behavioral threat hunting and response capabilities.
Technology recommendations: Splunk Enterprise (self-hosted), IBM QRadar on-premises, or Elastic SIEM (self-managed) for SIEM — all deployed on servers within Egypt; Symantec Endpoint Security (on-premises), Trend Micro Apex One (on-premises), or ESET Endpoint Protection (on-premises) for EPP/EDR. Avoid cloud-only SaaS security tools where the data is processed outside Egypt.
Step 5: Implement Database Encryption
Enable Transparent Data Encryption (TDE) on all databases containing customer or financial records.
Enforce SSL/TLS (minimum TLS 1.2) on all application and web server communications. Obtain certificates from a trusted CA.
Implement unique session identifiers and timestamps for all authenticated sessions. Avoid predictable or reusable session tokens.
Step 6: Enforce Strict Egypt-Only Data Residency
All customer and financial data must be stored exclusively on servers and storage hardware physically located within the borders of Egypt. This is a hard regulatory requirement with no exceptions.
Cloud services that store or process data on infrastructure outside Egypt are non-compliant. All systems must be deployed in Egyptian on-premises data centers or colocation facilities within Egypt in accordance with Egyptian law.
Engage a specialist Egyptian data center (e.g., Telecom Egypt DC, Raya IT, or a licensed colocation provider) to host all production and backup infrastructure.
Document data flow maps clearly showing that no customer data crosses Egypt's borders. Have the data residency attestation letter signed by your CTO or CISO and retained as audit evidence.
Step 7: Log Retention & Penetration Testing
Configure log retention policies for 5 years for system, application, security, and transaction logs. Use a dedicated on-premises log archive solution — such as a NAS (Network Attached Storage) or SAN with WORM (Write Once Read Many) storage deployed within Egypt. All log data must remain on Egyptian soil.
Schedule annual penetration tests by a qualified third-party firm. Address all critical and high findings before the next audit cycle.
Establish an incident notification SLA: critical security incidents must be reported to the FRA within 24 hours of detection.
Evidence to Collect for Audit
Server inventory with license documentation
HA configuration screenshots/documentation
NGFW and WAF configuration exports
SIEM deployment documentation and sample alert reports
TDE and SSL/TLS configuration certificates
Data residency attestation letter
Log retention policy document and retention proof (date-stamped archive samples)
Latest penetration test report with remediation evidence
---
Domain 2: Technology Governance (56 Requirements)
What It Requires
FRA 139 mandates a three-tier governance structure: Board-level oversight, Executive-level strategy execution, and Operational-level procedure management — across three pillars: IT Governance (ITG), Tech Risk Management (TRM), and Cyber Security Management (CSM).
Step-by-Step Implementation
Step 1: Establish Board-Level Committees (Tier 1 — 15 Requirements)
Formally establish three separate BoD-level committees: one for ITG, one for TRM, and one for CSM. Each committee must include at least one board member with demonstrated domain expertise.
Draft and obtain BoD approval for three strategy documents: IT Strategy, Risk Management Strategy, and Cybersecurity Strategy. Review and re-approve these annually.
Each committee must formally approve its respective framework: ITG-Framework, TRM-Framework, CSM-Framework.
Document required: BoD meeting minutes recording the committee establishment and strategy/framework approvals.
Step 2: Configure Executive Management Layer (Tier 2 — 27 Requirements)
Establish a Technology Steering Committee at the executive level, chaired by the CTO or equivalent. This committee bridges BoD decisions with operational reality.
Appoint three dedicated Executive Managers — one each for ITG, TRM, and CSM. These can be existing C-suite roles (CISO, CRO, CTO) but each must have a clear mandate and direct reporting line to the BoD committees.
Map each strategy to operational planning: define policies, assign clear roles, select tooling, and allocate budget. Document this in a Strategy-to-Planning mapping document.
Deploy Decisional Support Systems (DSS) — dashboards and reporting tools that allow executives to view real-time security metrics. Examples: self-hosted Grafana or Kibana dashboards fed from your on-premises SIEM, or on-premises GRC platforms such as Archer RSA (deployed on your own servers) or OpenGRC for automated compliance tracking.
Step 3: Operationalize at the Operational Management Level (Tier 3 — 14 Requirements)
Appoint a Technology Operations Manager (Tech-Ops Manager) who owns day-to-day execution of IT, risk, and cybersecurity procedures.
Ensure the Tech-Ops Manager has documented role definition, required qualifications (typically 5+ years in IT operations or cybersecurity management), and adequate staffing under them.
Create detailed Standard Operating Procedures (SOPs) for every operational process. Each SOP must link back to the executive strategy.
Implement a reporting cadence: Tech-Ops Manager reports effectiveness metrics to each executive (ITG/TRM/CSM) on a monthly basis. BoD committees receive quarterly reports.
Step 4: Implement the Governance Cascade
Ensure the chain works end-to-end: BoD Committees → approve frameworks → Executive Managers → operationalize → Tech-Ops Manager → execute and report back. Any gap in this chain is an audit finding.
Evidence to Collect for Audit
BoD resolution documents establishing the three committees
Approved IT Strategy, Risk Strategy, Cybersecurity Strategy documents
Approved ITG-F, TRM-F, CSM-F framework documents
Technology Steering Committee charter and meeting records
Executive Manager appointment letters and org chart
Strategy-to-Planning mapping document
DSS/dashboard screenshots showing KPI reporting
Tech-Ops Manager job description, qualifications, and appointment letter
SOPs for all operational domains
Monthly and quarterly reporting templates and completed reports
---
Domain 3: IT Service Management (138 Requirements)
What It Requires
FRA 139 requires a complete ITSM framework covering 5 life-cycle processes and 12 supporting processes — totaling 62+ documented and active activities.
Step-by-Step Implementation
Step 1: Implement the 5 Life-Cycle Processes (LP1–LP5)
Each life-cycle process must have documented procedures and measurable outcomes:
LP1 — Set Strategic Direction: Document IT service objectives aligned to the business strategy. Includes defining the service portfolio, target customers, and the service value proposition. Review annually.
LP2 — Design Services: Define service architecture, SLAs, continuity plans, and capacity requirements for every IT service before deployment. Use design documents and service blueprints.
LP3 — Build Services: Implement a formal release and deployment procedure. All new systems must pass through development, testing, staging, and production stages with documented release notes.
LP4 — Operate Services: Establish 24/7 IT operational monitoring. Define on-call rotas, escalation paths, and service desk procedures. Track incidents by severity.
LP5 — Improve Services: Run a quarterly service review process. Measure against SLAs, identify improvement opportunities, and implement CSI (Continual Service Improvement) plans.
Step 2: Deploy the 12 Supporting Processes (SP1–SP12)
SP1 — Service Management System (7 activities): Implement an ITSM tool (e.g., ServiceNow, Jira Service Management, Freshservice). Configure it for incident, problem, change, and request management.
SP2 — Service Portfolio Management (4 activities): Maintain a service catalog listing all IT services, their owners, SLAs, and costs. Update it whenever services are added or retired.
SP3 — Customer Relationship Management (6 activities): Define a formal customer satisfaction measurement process (e.g., quarterly surveys). Document escalation paths for customer complaints.
SP4 — Configuration Management (4 activities): Build and maintain a Configuration Management Database (CMDB). Every production asset must be recorded with its relationships to other assets and services.
SP5 — Change Management (7 activities): Implement a Change Advisory Board (CAB). All changes must be risk-assessed, approved, and documented. Maintain a change calendar.
SP6 — Project Management (4 activities): All IT initiatives must follow a formal project management methodology (e.g., PRINCE2 or PMI). Maintain project charters, status reports, and closure documents.
SP7 — Security Management (6 activities): Integrate security controls into every service lifecycle stage. Minimum: access control reviews, vulnerability scanning, and security testing before go-live.
SP8 — Disaster Preparedness (6 activities): Document a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP). Conduct tabletop exercises annually and full DR failover tests at least once per year.
SP9 — Compliance Management (3 activities): Schedule internal audits against FRA 139 requirements at least twice per year. Track findings in a remediation register with owners and due dates.
SP10 — Human Resources (3 activities): Maintain an IT skills matrix. Ensure all IT staff have role-appropriate certifications (e.g., ITIL for service managers, CompTIA Security+ for junior security staff). Track training completion rates.
SP11 — Supplier Management (8 activities): Maintain a vendor register with risk ratings. Conduct annual due diligence on all critical vendors. Ensure contracts include security clauses, SLAs, and audit rights.
SP12 — Financial Management (4 activities): Maintain an IT budget aligned to the approved IT strategy. Track actuals vs. budget monthly. Include IT cost allocation in management reporting.
Evidence to Collect for Audit
Life-cycle process procedures (LP1–LP5) with version control
ITSM tool configuration and sample tickets
Service catalog/portfolio document
CMDB export or screenshot showing production assets
CAB meeting minutes and change logs
BCP and DRP documents with last test dates and results
Internal audit reports and remediation registers
Vendor register with risk ratings and due diligence records
IT training matrix and staff certification records
---
Domain 4: Technology Risk Management (83 Requirements)
What It Requires
FRA 139 mandates a structured risk management lifecycle (Frame, Assess, Respond, Monitor) and a seven-step Security Control process (Prepare through Monitor).
Step-by-Step Implementation
Step 1: Establish the Risk Framework (LRP1 — Frame)
Document your risk management assumptions (e.g., threat environment assumptions, data classification levels).
Define risk tolerance levels for each business unit. Express tolerance as quantitative thresholds (e.g., maximum acceptable annual loss expectancy of EGP X million).
Identify risk priorities aligned to business strategy.
Output: Risk Management Framework document approved by the TRM Executive Manager and BoD TRM Committee.
Step 2: Conduct Risk Assessments (LRP2 — Assess)
Build a threat library tailored to your industry. Sources: FRA advisory notices, NIST NVD, ENISA threat landscape reports.
Conduct vulnerability assessments at least quarterly (automated scanning) plus annual manual risk assessments for each critical asset.
Calculate inherent risk using likelihood × impact matrices. Document residual risk after existing controls are applied.
Output: Risk Register maintained in a GRC tool deployed on-premises (e.g., Archer RSA on-premises, OpenGRC, or a well-structured spreadsheet at minimum). Do not use SaaS GRC platforms that store risk data on servers outside Egypt.
Step 3: Define and Implement Risk Responses (LRP3 — Respond)
For each identified risk, select a response: Accept, Avoid, Transfer (insurance), or Mitigate.
For mitigation: document the specific control to be implemented, the owner, the timeline, and the expected residual risk after control implementation.
Formally evaluate alternatives — document why the chosen response was selected over others.
Output: Risk Response Plan with assigned owners and delivery dates.
Step 4: Ongoing Risk Monitoring (LRP4 — Monitor)
Define Key Risk Indicators (KRIs) for each major risk category. Examples: number of critical unpatched vulnerabilities, mean time to remediate findings, number of security incidents per month.
Review KRIs monthly. Report to executive management and quarterly to the BoD TRM committee.
Trigger a full risk reassessment whenever a major change occurs (new system deployment, M&A, regulatory change).
Step 5: Execute Security Control Processes (SCP1–SCP7)
SCP1 — Prepare (21 requirements): Define risk management roles (CISO, Risk Officer, Control Owners). Build the organizational risk management strategy. Select and document control baselines tailored to your risk profile.
SCP2 — Categorize (3 requirements): Classify all information systems by impact level: Low, Moderate, or High. Use a data classification policy as the basis (e.g., Public, Internal, Confidential, Restricted).
SCP3 — Select (6 requirements): Select appropriate security controls from the FRA-mandated NIST-based catalog. Document control selections and tailoring decisions in a System Security Plan (SSP).
SCP4 — Implement (2 requirements): Deploy selected controls. Track implementation progress against a controls implementation plan.
SCP5 — Assess (6 requirements): Engage internal or third-party assessors to evaluate control effectiveness. Produce a Security Assessment Report (SAR). Identify and document weaknesses in a Plan of Action & Milestones (POA&M).
SCP6 — Authorize (5 requirements): Based on the SAR and POA&M, the designated Authorizing Official (typically the CISO or CRO) issues a formal Authorization to Operate (ATO) for each system, accepting residual risk.
SCP7 — Monitor (7 requirements): Implement continuous monitoring of all controls. Automate where possible (e.g., use SIEM rules that map to specific controls). Report control status to the Authorizing Official whenever a significant change occurs.
Evidence to Collect for Audit
Risk Management Framework document (BoD-approved)
Threat library and risk assessment methodology document
Risk register (current, with dates and owner names)
Risk response plan with implementation status
KRI definitions and tracking dashboard/reports
Data classification policy
System Security Plans (SSP) for each critical system
Security Assessment Report (SAR) with assessor credentials
Plan of Action & Milestones (POA&M) with remediation progress
Authorization to Operate (ATO) letters for each critical system
Continuous monitoring reports
---
Domain 5: Cyber Security Framework (164 Requirements)
What It Requires
FRA 139's largest domain is built entirely on the NIST Cybersecurity Framework (CSF) v1.1, covering all five functions: Identify, Protect, Detect, Respond, and Recover.
Step-by-Step Implementation
IDENTIFY — 29 Requirements
Asset Management (ID.AM — 6 reqs): Maintain a comprehensive asset inventory covering hardware, software, data, and users. Use automated discovery tools that reconcile against your CMDB monthly. Every asset must have an owner and classification.
Business Environment (ID.BE — 5 reqs): Document the organization's mission, objectives, and critical business processes. Map IT resources to business functions. Define and communicate the role of cybersecurity in supporting the business.
Governance (ID.GV — 4 reqs): Establish and maintain an Information Security Policy approved by the BoD CSM Committee. Define cybersecurity roles and responsibilities. Ensure legal and regulatory requirements (including FRA 139) are identified and factored into cybersecurity planning.
Risk Assessment (ID.RA — 6 reqs): Conduct threat and vulnerability assessments for all critical assets. Identify threat actors relevant to the financial services sector (cybercriminals, insider threats, nation-states). Document risk responses.
Risk Management Strategy (ID.RM — 3 reqs): Ensure organizational risk tolerance is documented and communicated. Cybersecurity risk decisions must be aligned to this tolerance.
Supply Chain Risk (ID.SC — 5 reqs): Assess the cybersecurity posture of all critical vendors. Require vendors to provide security assessments or third-party audit reports (e.g., SOC 2 Type II). Include cybersecurity requirements in all vendor contracts.
PROTECT — 39 Requirements
Access Control (PR.AC — 7 reqs): Implement IAM processes enforcing least privilege for all users. Deploy Multi-Factor Authentication (MFA) for all privileged access and all remote access. Review access rights quarterly. Implement zero-trust network access (ZTNA) for remote workers.
Awareness & Training (PR.AT — 5 reqs): Conduct security awareness training for all staff at onboarding and annually thereafter. Run phishing simulation exercises quarterly. Provide specialized training for privileged users. Document training completion rates.
Data Security (PR.DS — 8 reqs): Implement data-at-rest encryption for all sensitive data. Enforce data-in-transit encryption (TLS 1.2+). Implement a Data Loss Prevention (DLP) solution to prevent unauthorized exfiltration. Define and enforce a data retention and disposal policy.
Information Protection (PR.IP — 12 reqs): Maintain a configuration management baseline for all systems (hardening standards). Implement patch management with SLAs: Critical patches in 24 hours, High in 72 hours, Medium in 30 days. Maintain network diagrams and data flow documentation. Enforce a formal vulnerability management program.
Maintenance (PR.MA — 2 reqs): Controlled maintenance and repair of assets. Log all maintenance activities. Restrict remote maintenance sessions to approved, monitored channels.
Protective Technology (PR.PT — 5 reqs): Implement audit logging on all critical systems. Deploy network segmentation — separate production, development, and management networks. Deploy anti-malware solutions and ensure real-time protection is active.
DETECT — 18 Requirements
Anomalies & Events (DE.AE — 5 reqs): Define a baseline of normal network and user behavior. Configure SIEM alerts for deviations. Establish thresholds for alert escalation. Integrate threat intelligence feeds.
Continuous Monitoring (DE.CM — 8 reqs): Monitor the network for unauthorized devices and connections. Scan for vulnerabilities continuously (weekly automated scans minimum). Monitor employee activity for insider threat indicators. Monitor external service provider access.
Detection Processes (DE.DP — 5 reqs): Define and document detection processes. Establish roles and responsibilities for the monitoring team (SOC). Test detection capabilities annually through red team exercises or tabletop simulations.
RESPOND — 16 Requirements
Response Planning (RS.RP — 1 req): Maintain a documented and board-approved Incident Response Plan (IRP). Review and update it at least annually.
Communications (RS.CO — 5 reqs): Define internal and external communication protocols during incidents. Include FRA notification within 24 hours of a material incident. Coordinate with law enforcement, legal counsel, and external IR providers as needed.
Analysis (RS.AN — 5 reqs): Document the incident analysis process. Perform root cause analysis for all significant incidents. Produce incident reports within 72 hours of containment.
Mitigation (RS.MI — 3 reqs): Contain and eradicate incidents promptly. Document mitigation steps taken. Prevent recurrence by implementing remediation before marking an incident closed.
Improvements (RS.IM — 2 reqs): Conduct post-incident reviews (PIRs). Incorporate lessons learned into the IRP and security controls.
RECOVER — 6 Requirements
Recovery Planning (RC.RP — 1 req): Maintain a tested Recovery Plan for all critical systems. Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each system. Test at least annually with documented results.
Improvements (RC.IM — 2 reqs): Incorporate recovery lessons learned from actual incidents and test exercises into the Recovery Plan.
Communications (RC.CO — 3 reqs): Define communication plans for restoring trust with stakeholders after a cybersecurity incident. This includes internal communications, customer notifications (if data was affected), and regulatory notifications.
Evidence to Collect for Audit
Asset inventory and CMDB reconciliation reports
Information Security Policy (BoD-approved, current version)
IAM configuration demonstrating least privilege and MFA enforcement
Security awareness training records and phishing simulation results
Data classification policy and DLP configuration documentation
Hardening baselines and patch management SLA compliance reports
SIEM configuration showing active alerting and correlation rules
Vulnerability scan reports (weekly/quarterly)
Incident Response Plan (IRP)
Incident logs and post-incident review reports
Disaster Recovery test plans and results
Vendor security assessments or SOC 2 reports
---
Implementing a Compliance Program: Recommended Approach
Rather than addressing requirements individually, successful organizations build a compliance program that systematically delivers evidence across all domains. A recommended approach:
Phase 1 — Gap Assessment (Months 1–2)
Conduct a formal gap assessment against all 473 requirements. Score each requirement as Compliant, Partially Compliant, or Non-Compliant. Assign an owner and a remediation priority to every gap.
Phase 2 — Quick Wins (Months 1–3)
Prioritize controls that are both high-impact and fast to implement:
Enable MFA across all systems.
Implement HA for critical databases and application servers.
Deploy EPP and EDR on all endpoints.
Establish BoD committees with meeting records.
Implement a log retention policy.
Phase 3 — Framework Build-out (Months 3–9)
Implement frameworks across all five domains sequentially, starting with governance (since it enables all others):
1Governance frameworks (ITG-F, TRM-F, CSM-F) — approved by BoD.
2Risk framework and risk register.
3ITSM tooling and process documentation.
4Security control implementation (NIST CSF mapping).
5Monitoring and detection capabilities (SIEM, SOC).
Phase 4 — Evidence Collection and Internal Audit (Months 9–11)
Run an internal audit using the evidence checklists in each domain above. Address any remaining gaps before the FRA regulatory examination.
Phase 5 — Sustained Compliance (Ongoing)
Monthly: KRI reviews, vulnerability scan reviews, change board meetings.
Quarterly: Risk register updates, penetration test execution, BoD committee reporting, phishing simulations.
Annually: Full risk assessment, BCP/DR tests, penetration testing, framework document reviews, staff training.
---
Conclusion
FRA Decision No. 139 is demanding — but it is also a mature, internationally-aligned framework. Organizations that achieve compliance will not only satisfy the regulator, but will have built genuinely resilient infrastructure and governance that protects customers, reduces operational risk, and enables business growth in Egypt's regulated financial ecosystem.
Asfaleia-Tech specializes in helping organizations navigate and achieve FRA 139 compliance. Our team provides gap assessments, framework development, technical implementations, and audit preparation services. Contact us to begin your compliance journey.