Security Lab
26 tools for governance, analysis, investigation and learning. Choose a tab to find a tool.
38 ECC-2 controls crosswalked to ISO 27001, 37 to SAMA CSF
114 ECC-1 → ECC-2 lineage rows mapped
4 incident tabletop scenarios
Governance
NCA ECC-2 → ISO 27001 Crosswalk
Covers selected controls from NCA ECC-2:2024's 108 controls, mapped one way to ISO/IEC 27001:2022 and SAMA CSF. These are the author's mappings, not NCA's or SAMA's interpretation.
NCA ECC-2:2024 mapped to ISO/IEC 27001:2022SAMA CSF v1.0 (May 2017). Coverage is one-directional (ECC → mapped framework). Mapped at control / control-consideration level. Scope: a curated subset of ECC-2:2024's 108 main controls, selected across all four domains, not full-framework coverage. AI-assisted and source-checked against the official framework texts (last pass 2026-08-05); independently verify before use. Version watch: mappings track SAMA CSF v1.0 (May 2017) and will be re-based when SAMA publishes a successor.
All 38 mapped ECC controls have an ISO 27001 counterpart (15 direct, 23 partial).37 of the 38 also map to SAMA CSF v1.0 (19 direct, 18 partial); 1 has no CSF equivalent.
Mapped on ECC-2:2024; ECC-1:2018 lineage preserved in the 114-row re-map.
- Direct same control
- Partial related; bundled or split
- No equivalent outside framework scope
| NCA ECC | Control | Domain | ISO/IEC 27001SAMA CSF | Mapping |
|---|---|---|---|---|
1-1-1 |
Cybersecurity strategy defined, documented, approved | Governance |
5.1
Policies for information security
3.1.2
Cyber Security Strategy
|
Partial Direct |
2-1-1 |
Asset-management requirements defined | Defense |
5.9
Inventory of information and other associated assets
3.3.3
Asset Management
|
Partial Direct |
3-1-1 |
Resilience requirements within BCM defined | Resilience |
5.29
Information security during disruption
3.1.3
Cyber Security Policy
|
Direct Partial |
4-1-1 |
Third-party contract cybersecurity requirements defined | Third-Party & Cloud |
5.20
Addressing information security within supplier agreements
3.4.1
Contract and Vendor Management
|
Direct Direct |
1-2-1 |
Independent cybersecurity department established | Governance |
Clause 5.3
Organizational roles, responsibilities and authorities (ISMS clause)
3.1.1
Cyber Security Governance
|
Partial Direct |
Showing 5 of 38 controls; representative sample across domains.
Show all 38 controls
| NCA ECC | Control | Domain | ISO/IEC 27001SAMA CSF | Mapping |
|---|---|---|---|---|
| Cybersecurity strategy defined, documented, approved | Governance |
5.1
Policies for information security
3.1.2
Cyber Security Strategy
|
Partial Direct | |
| ECC-2 1-1-1 is the approved cybersecurity strategy; A.5.1 is the policy set (see 1-3-1): strategic-direction overlap only. ECC-1 lineage: 1-1-1 (retained). Approved cybersecurity strategy in both; ECC requires Authorized Official support, while CSF 3.1.4 assigns committee approval and board endorsement. | ||||
| Independent cybersecurity department established | Governance |
Clause 5.3
Organizational roles, responsibilities and authorities (ISMS clause)
3.1.1
Cyber Security Governance
|
Partial Direct | |
| Establishing the cybersecurity function and assigning its authority is Clause 5.3 territory; ISO has no analogue to the required independence from IT. ECC-1 lineage: 1-2-1 (retained). CSF 3.1.1 requires a cyber security function established and independent from the IT function, with separate reporting lines, budgets and staff evaluations: the same obligation as 1-2-1. | ||||
| Cybersecurity supervisory committee | Governance |
5.2
Information security roles and responsibilities
3.1.1
Cyber Security Governance
|
Partial Direct | |
| A.5.2 requires roles to be defined and allocated; ISO nowhere requires a supervisory committee. The committee's oversight function (ensure compliance, monitor the programme) has its ISO home in ISMS Clause 5.1 leadership and 9.3 management review, not in any Annex A control, so Partial. ECC-1 lineage: 1-2-3 (retained). CSF 3.1.1 requires a board-mandated cyber security committee with an approved charter covering objectives, roles and meeting frequency. | ||||
| Policies and procedures documented and approved | Governance |
5.1
Policies for information security
3.1.3
Cyber Security Policy
|
Direct Direct | |
| Identify, document, approve and communicate policies: A.5.1 almost verbatim. ECC-1 lineage: 1-3-1 (changed). Approved and communicated cybersecurity policy supported by documented standards and procedures in both (CSF 3.1.3.1, 3.1.3.3(b)). | ||||
| Risk-management methodology approved | Governance |
Clause 6.1.2
Information security risk assessment (ISMS clause)
3.2.1
Cyber Security Risk Management
|
Partial Direct | |
| Risk-management methodology and procedures defined, documented and approved; Clause 6.1.2 covers assessment, while treatment is Clause 6.1.3. ECC-1 lineage: 1-5-1 (retained). Same cyber security risk-management methodology. | ||||
| Compliance with nationally approved international commitments | Governance |
5.31
Legal, statutory, regulatory and contractual requirements
3.2.2
Regulatory Compliance
|
Direct Partial | |
| Identify and comply with nationally approved international cybersecurity commitments: A.5.31. ECC-1 lineage: 1-7-2 (changed). CSF 3.2.2.1 requires compliance with relevant regulatory requirements but does not expressly identify nationally approved international agreements and commitments. | ||||
| Periodic internal cybersecurity review | Governance |
5.36
Compliance with policies, rules and standards for information security
3.2.4
Cyber Security Review
|
Direct Direct | |
| Periodic review of cybersecurity-control implementation by the cybersecurity department: A.5.36; independent review is addressed separately by 1-8-2. ECC-1 lineage: 1-8-1 (retained). Review by the cybersecurity function itself (second line): SAMA 3.2.4; independent audit is 3.2.5, mapped from 1-8-2. | ||||
| Independent cybersecurity audit | Governance |
5.35
Independent review of information security
3.2.5
Cyber Security Audits
|
Direct Direct | |
| Independent review and audit outside the cybersecurity department: A.5.35; Clause 9.2 also supports the internal-audit aspect. ECC-1 lineage: 1-8-2 (retained). Independent audit by parties outside the cybersecurity function under conflict-of-interest principles: SAMA 3.2.5 (third line). | ||||
| Personnel cybersecurity requirements defined | Governance |
6.2
Terms and conditions of employment
3.3.1
Human Resources
|
Partial Direct | |
| Personnel security requirements defined, documented and approved across employment; A.6.2 is the contractual anchor, with screening under A.6.1 and post-employment responsibilities under A.6.5. ECC-1 lineage: 1-9-1 (retained). Cyber security embedded in HR lifecycle. | ||||
| Pre-employment requirements (security responsibilities, NDA clauses, screening/vetting) | Governance |
6.2
Terms and conditions of employment
3.3.1
Human Resources
|
Partial Direct | |
| A.6.2 covers the contractual half; the NDA clauses are A.6.6 and vetting is A.6.1. ECC-1 lineage: 1-9-3 (retained). CSF 3.3.1(3)(a)/(d) covers contractual cybersecurity responsibilities, non-disclosure clauses and screening/background checks, matching both ECC sub-controls. | ||||
| Awareness program developed and approved | Governance |
6.3
Information security awareness, education and training
3.1.6
Cyber Security Awareness
|
Direct Direct | |
| Awareness programme developed, approved and delivered through multiple channels: A.6.3's awareness limb; role-based training is 1-10-4. ECC-1 lineage: 1-10-1 (retained). Awareness-programme control matching SAMA 3.1.6 one-to-one; specialised training is 1-10-4 (SAMA 3.1.7). | ||||
| Asset-management requirements defined | Defense |
5.9
Inventory of information and other associated assets
3.3.3
Asset Management
|
Partial Direct | |
| Asset-management requirements defined, documented and approved; A.5.9 covers the inventory aspect of the broader obligation. ECC-1 lineage: 2-1-1 (retained). CSF 3.3.3.1 requires the asset management process to be defined, approved and implemented: the same requirements-and-approval obligation. | ||||
| Acceptable-use policy defined and communicated | Defense |
5.10
Acceptable use of information and other associated assets
No SAMA CSF equivalent
|
Direct No equivalent | |
| Acceptable-use policy identified, documented, approved and communicated: A.5.10. ECC-1 lineage: 2-1-3 (retained). Checked 3.1.3, 3.1.4, 3.1.6, 3.3.1, 3.3.3 and 3.3.10: no explicit requirement to define, document, approve and communicate an organization-wide acceptable-use policy. | ||||
| Assets classified, labeled, and handled per regulation | Defense |
5.12
Classification of information
3.3.3
Asset Management
|
Partial Direct | |
| Asset classification maps to A.5.12; labelling and handling extend into A.5.13 and A.5.10. ECC-1 lineage: 2-1-5 (retained). CSF 3.3.3(3)(d) explicitly covers information asset classification, labeling and handling. | ||||
| IAM requirements defined | Defense |
5.15
Access control
3.3.5
Identity and Access Management
|
Partial Direct | |
| IAM requirements defined, documented and approved; A.5.15 covers access-control rules, with identity management under A.5.16. ECC-1 lineage: 2-2-1 (retained). CSF 3.3.5(1) requires the IAM policy to be defined and approved, matching ECC's requirements-setting obligation. | ||||
| Minimum IAM requirements (authentication, MFA, least privilege, PAM, periodic review) | Defense |
8.5
Secure authentication
3.3.5
Identity and Access Management
|
Partial Partial | |
| Authentication maps to A.8.5; need-to-know to A.8.3/A.5.15, segregation of duties to A.5.3, privileged access to A.8.2 and access review to A.5.18. ECC-1 lineage: 2-2-3 (changed). CSF 3.3.5 covers access restriction, MFA, privileged access and reviews; its privileged-MFA scope differs, and segregation of duties is explicit in 3.3.6/3.3.8. | ||||
| System-protection requirements defined | Defense |
8.7
Protection against malware
3.3.8
Infrastructure Security
|
Partial Partial | |
| System and processing-facility protection requirements defined, documented and approved; A.8.7 covers the malware-protection aspect. ECC-1 lineage: 2-3-1 (retained). CSF 3.3.8(1) requires approved infrastructure security standards; system and processing-facility protection is one part of that broader scope. | ||||
| Minimum system protection (anti-malware, external media, patching, clock sync) | Defense |
8.7
Protection against malware
3.3.8
Infrastructure Security
|
Partial Partial | |
| Sub-controls are anti-malware, external-media restriction, patching and clock sync: A.8.7 with A.7.10/A.8.8/A.8.17 aspects; no configuration or hardening obligation here. ECC-1 lineage: 2-3-3 (retained). Malware protection and vulnerability/patch management are named in the CSF 3.3.8 infrastructure standard; external-media restriction and clock synchronisation are not. | ||||
| Email-protection requirements defined | Defense |
5.14
Information transfer
3.3.8
Infrastructure Security
|
Partial Partial | |
| Email-protection requirements defined, documented and approved; A.5.14 covers information-transfer rules, with malware protection under A.8.7. ECC-1 lineage: 2-4-1 (retained). No dedicated email subdomain; email gateways are named in the CSF 3.3.8 infrastructure standard. | ||||
| Network-security requirements defined | Defense |
8.20
Networks security
3.3.8
Infrastructure Security
|
Direct Partial | |
| Requirements for securing and managing the entity's networks identified, documented and approved: A.8.20's subject matter; segmentation itself is A.8.22 (see 2-5-3). ECC-1 lineage: 2-5-1 (retained). No dedicated network subdomain; covered under infrastructure security. | ||||
| Minimum network security (segmentation, secure browsing, wireless, IPS, DNS, DDoS) | Defense |
8.20
Networks security
3.3.8
Infrastructure Security
|
Partial Partial | |
| A.8.20 anchors network protection; A.8.22 covers segmentation, A.8.31 production/test separation, A.8.21 network services and A.8.23 browsing restrictions. ECC-1 lineage: 2-5-3 (changed). Network services security is a subset of infrastructure security. | ||||
| Mobile/BYOD security requirements defined | Defense |
8.1
User endpoint devices
3.3.10
Bring Your Own Device (BYOD)
|
Direct Partial | |
| Mobile + endpoint device security. ECC-1 lineage: 2-6-1 (retained). Partial overlap; BYOD does not cover all corporate-managed mobile. | ||||
| Data-protection requirements defined per legal requirements | Defense |
8.12
Data leakage prevention
3.3.3
Asset Management
|
Partial Partial | |
| Data-protection requirements defined, documented and approved; A.8.12 covers leakage prevention, while A.5.12, A.5.33 and A.5.34 cover other aspects. ECC-1 lineage: 2-7-1 (retained). CSF 3.3.3(3)(d) covers classification and handling within asset management; ECC separately requires approved data-protection and handling requirements. | ||||
| Cryptography requirements defined | Defense |
8.24
Use of cryptography
3.3.9
Cryptography
|
Direct Direct | |
| Cryptography requirements defined, documented and approved: A.8.24. ECC-1 lineage: 2-8-1 (retained). CSF 3.3.9(1) requires a defined and approved cryptographic security standard. | ||||
| Backup-and-recovery requirements defined | Defense |
8.13
Information backup
3.3.8
Infrastructure Security
|
Direct Partial | |
| Backup and recovery requirements defined, documented and approved: A.8.13; recovery testing is separately specified in 2-9-3-3. ECC-1 lineage: 2-9-1 (retained). SAMA control consideration 6(i) "back-up and recovery procedures". | ||||
| Vulnerability-management requirements defined | Defense |
8.8
Management of technical vulnerabilities
3.3.17
Vulnerability Management
|
Direct Direct | |
| Technical vulnerability-management requirements defined, documented and approved: A.8.8. ECC-1 lineage: 2-10-1 (retained). CSF 3.3.17(1) requires a defined and approved vulnerability-management process. | ||||
| Penetration-testing requirements defined | Defense |
8.8
Management of technical vulnerabilities
3.2.4
Cyber Security Review
|
Partial Partial | |
| ISO 27001 does not have a dedicated pen-test control; it folds under 8.8. ECC-1 lineage: 2-11-1 (retained). CSF 3.2.4(2) explicitly requires penetration tests for customer and internet-facing services; ECC requires penetration-testing requirements to be defined, documented and approved. | ||||
| Logging-and-monitoring requirements defined | Defense |
8.15
Logging
3.3.14
Cyber Security Event Management
|
Partial Direct | |
| Logging and monitoring requirements defined, documented and approved; A.8.15 covers logging and A.8.16 covers monitoring activities. ECC-1 lineage: 2-12-1 (retained). CSF 3.3.14(1)/(3) requires a defined and approved event-management process and monitoring standard. | ||||
| Minimum logging (critical assets, privileged/remote access, SIEM, continuous monitoring, 12-month retention) | Defense |
8.15
Logging
3.3.14
Cyber Security Event Management
|
Partial Partial | |
| Logging maps to A.8.15 and continuous monitoring to A.8.16; the fixed 12-month retention minimum is ECC-specific. ECC-1 lineage: 2-12-3 (retained). CSF 3.3.14 covers SIEM and continuous monitoring, but specifies neither ECC's 12-month retention minimum nor its explicit privileged/remote-access logging requirements. | ||||
| Incident-and-threat-management requirements defined | Defense |
5.24
Information security incident management planning and preparation
3.3.15
Cyber Security Incident Management
|
Partial Partial | |
| Incident and threat-management requirements defined, documented and approved; A.5.24 covers incident planning, with threat intelligence under A.5.7. ECC-1 lineage: 2-13-1 (retained). CSF 3.3.15 defines and approves incident-management processes; threat-intelligence management is separately addressed by 3.3.16. | ||||
| Physical-security requirements defined | Defense |
7.1
Physical security perimeters
3.3.2
Physical Security
|
Partial Direct | |
| Requirements for physical protection against unauthorized access, loss, theft and damage defined, documented and approved; A.7.1 covers only the perimeter aspect. ECC-1 lineage: 2-14-1 (retained). Physical and environmental protection of facilities and assets. | ||||
| External web-application security requirements defined | Defense |
8.26
Application security requirements
3.3.6
Application Security
|
Direct Direct | |
| External web-application security requirements defined, documented and approved: A.8.26. ECC-1 lineage: 2-15-1 (retained). CSF 3.3.6(1) requires defined and approved application-security standards; its application scope includes external web applications. | ||||
| Resilience requirements within BCM defined | Resilience |
5.29
Information security during disruption
3.1.3
Cyber Security Policy
|
Direct Partial | |
| Umbrella obligation to embed cybersecurity within BCM: maintaining security through disruption (A.5.29). ECC-1 lineage: 3-1-1 (retained). CSF 3.1.3(4)(f)(8) embeds cybersecurity in BCM through the approved cybersecurity policy; ECC separately specifies BCM cybersecurity requirements. | ||||
| Minimum resilience requirements (continuity of security systems, incident response plans, DRP) | Resilience |
5.30
ICT readiness for business continuity
3.3.15
Cyber Security Incident Management
|
Partial Partial | |
| Minimums combine security continuity (A.5.29), incident-response planning (A.5.24) and ICT recovery (A.5.30); A.5.30 alone covers only part. ECC-1 lineage: 3-1-3 (retained). CSF 3.3.15 covers incident response and recovery; 3-1-3 additionally requires continuity of cybersecurity systems and disaster recovery plans. | ||||
| Third-party contract cybersecurity requirements defined | Third-Party & Cloud |
5.20
Addressing information security within supplier agreements
3.4.1
Contract and Vendor Management
|
Direct Direct | |
| Third-party contract security requirements defined, documented and approved: A.5.20 addresses security within supplier agreements. ECC-1 lineage: 4-1-1 (retained). Cyber security requirements for third parties and vendors. | ||||
| Minimum third-party contract clauses (NDA/secure removal, incident communication, policy compliance) | Third-Party & Cloud |
5.20
Addressing information security within supplier agreements
3.4.1
Contract and Vendor Management
|
Direct Partial | |
| Contractual cybersecurity clauses. ECC-1 lineage: 4-1-2 (retained). CSF 3.4.1 covers confidentiality, incident escalation and exit requirements; it does not explicitly require third-party secure data removal at service end. | ||||
| Outsourcing safeguards (risk assessment, mitigation, KSA location for remotely accessed managed SOCs) | Third-Party & Cloud |
5.20
Addressing information security within supplier agreements
3.4.2
Outsourcing
|
Partial Partial | |
| Outsourcing contract safeguards overlap A.5.20; ECC additionally specifies pre-contract risk assessment and mitigation, plus KSA location for remotely accessed managed SOCs. ECC-1 lineage: 4-1-3 (changed). CSF 3.4.1(5)(a) addresses procurement risk assessment; 3.4.2 addresses outsourcing but does not state ECC's KSA-location requirement for remotely accessed managed SOCs. | ||||
| Cloud/hosting cybersecurity requirements defined | Third-Party & Cloud |
5.23
Information security for use of cloud services
3.4.3
Cloud Computing
|
Partial Partial | |
| Cloud and hosting security requirements defined, documented and approved; A.5.23 covers cloud services, with non-cloud hosting addressed through supplier controls. ECC-1 lineage: 4-2-1 (retained). CSF 3.4.3 covers hybrid/public cloud and expressly excludes private cloud; ECC 4-2-1 addresses cloud and hosting services. | ||||
Showing 38 ECC↔ISO 27001 mappings. Conservative pass: only confident Direct and Partial mappings included.
SAMA CSF mappings are author-reviewed and checked against the SAMA Rulebook at control-consideration level. Six ECC controls (2-3-1, 2-3-3, 2-4-1, 2-5-1, 2-5-3, 2-9-1) fan into SAMA 3.3.8 Infrastructure Security, which bundles these into control considerations rather than dedicated subdomains.
How the SAMA references were checked
Scope: the ITGF references in the three-way SAMA CSF ↔ ITGF ↔ ECC-2 crosswalk (38 rows; the ECC controls and SAMA CSF mappings in this table, carried over field-by-field). The record below is rendered from that dataset's own metadata.
Date: 2026-08-09
Verified against: Official SAMA ITGF full text captured from https://rulebook.sama.gov.sa/en/information-technology-governance-framework (chapters 1-3 and appendices A-E, including the glossary).
Quotation convention: Phrases in single quotes inside itgf_rationale are quoted from the captured rulebook text. Two mechanical normalisations were applied and affect no wording: stray spaces the site's inline-link markup inserts before punctuation were closed up (for example 'SAMA Cyber Security , Business Continuity Management' becomes 'SAMA Cyber Security, Business Continuity Management'), and an ellipsis marks any elision, including where a numbered sub-list was collapsed. Every quoted phrase was checked programmatically against the captured text.
Method: The complete Control Domains chapter was read subdomain by subdomain at Control Requirement level, not by title. For each of the 38 ECC-2 rows the candidate ITGF subdomains were compared against the ECC obligation at requirement level, and the mapping type was set from what the Control Requirements actually mandate. Absences were confirmed by full-text term search over the captured document: COBIT, cloud, email/e-mail, mobile, BYOD, malware, antivirus/anti-virus, penetration, cryptograph, screening, vetting, background check, DDoS, DNS, multi-factor/two-factor/MFA and DLP each return zero occurrences. Rows whose anchor remained a judgement call between competing subdomains were left verified: false rather than forced.
Medium-confidence ITGF anchors:
1-8-1medium confidence ITGF splits periodic internal review across 3.1.9 KPI monitoring, the CIO's compliance-monitoring accountability in 3.1.5, and the section 2.3 self-assessment obligation outside the control domains; no single subdomain is the unambiguous counterpart.2-2-1medium confidence ITGF has no IAM subdomain; access control is distributed across 3.3.1, 3.3.6, 3.3.11 and 3.4.1, so the choice of primary anchor is a judgement call.2-2-3medium confidence Same distribution problem as 2-2-1, and the strongest least-privilege and strong-authentication language sits in 3.3.11, scoped to virtual environments; anchoring the general IAM minimums on one subdomain overstates ITGF's structure.2-3-1medium confidence ITGF has no system-protection or hardening subdomain; the only approved security-baseline requirement is virtualization-scoped (3.3.11) and anti-malware is absent entirely, so the configuration-management anchor is the least-bad rather than the evident home.
Corrections since v1:
- v1 described the ITGF as 'COBIT-2019-aligned'. The published ITGF text contains no reference to COBIT anywhere (zero occurrences). The alignment is an analytical inference, not a statement of the framework, and has been removed from the framework descriptor. COBIT objectives are retained only in the per-row cobit_context field, explicitly labelled as external annotation.
- v1 described the ITGF maturity model as 'levels 0-5 with level 3 the minimum target'. The ITGF text mandates no minimum level. It states only the objective 'To achieve an appropriate maturity level of IT controls within the Member Organizations' (section 1.1) and, in section 2.4, 'The information technology governance maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5) ... In order to achieve levels 3, 4 or 5, Member Organizations should first meet all criteria of the preceding maturity levels.' The framework body sets no target level; the issuing circular No. 43028139 (4/11/2021G) required each institution to submit a roadmap to achieve Maturity Level 3 by end of January 2022G, with full compliance by end of Q4 2022G (clause Second: roadmap 'to achieve "Maturity Level 3"'). Attribute the level-3 target to the circular, not to the framework body.
- v1 asserted no ITGF control numbers at all and used normalised domain labels. All 38 rows now carry official ITGF subdomain numbers and verbatim subdomain titles, or an explicit null where the framework has no counterpart.
- 2026-09-06: three of the four 'None' SAMA CSF rows were re-mapped against the Rulebook text. 1-3-1 -> 3.1.3 Cyber Security Policy, Direct (3.1.3.1 'defined, approved and communicated'; 3.1.3.3(b) supporting procedures). 1-7-1 -> 3.2.2 Regulatory Compliance, Partial (3.2.2.1 covers regulatory requirements without naming international commitments). 3-1-1 -> 3.1.3, Partial (3.1.3.4(f)(8) requires cyber security to be reflected in BCM). 2-1-3 remains None with a negative-evidence rationale. Checked by an independent model against rulebook.sama.gov.sa; the mapping is an analytical reading, not SAMA's interpretation, which CSF 1.6 reserves to SAMA.
Incident Tabletop Exercise
Fictional scenarios with simplified regulatory checkpoints. The after-action score is a rough training measure, not a readiness assessment. This is not incident-response advice.
ECC-1 → ECC-2 Transition
Not an NCA-published crosswalk. Statuses use NCA Appendix C where it specifies a change; otherwise, they reflect the author's reading of the English PDFs. The Arabic edition is binding. Each blank cell states why it is blank.
Open the ECC-1 → ECC-2:2024 control re-map (114 lineage rows)
NCA ECC-2:2024 4 domains, 28 subdomains, 108 controls, 92 subcontrols. Source: NCA. Supersedes ECC-1:2018. Lineage and mappings AI-assisted and source-checked against the official NCA publications (last pass 2026-08-05); independently verify before use.
1 Cybersecurity Governance
1-1Cybersecurity Strategy1-2Cybersecurity Management1-3Cybersecurity Policies and Procedures1-4Cybersecurity Roles and Responsibilities1-5Cybersecurity Risk Management1-6Cybersecurity in Information and Technology Project Management1-7Compliance with Cybersecurity Standards, Laws and Regulations1-8Periodical Cybersecurity Review and Audit1-9Cybersecurity in Human Resources1-10Cybersecurity Awareness and Training Program
2 Cybersecurity Defense
2-1Asset Management2-2Identity and Access Management2-3Information Systems and Information Processing Facilities Protection2-4Email Protection2-5Network Security Management2-6Mobile Devices Security2-7Data and Information Protection2-8Cryptography2-9Backup and Recovery Management2-10Vulnerability Management2-11Penetration Testing2-12Cybersecurity Event Logs and Monitoring Management2-13Cybersecurity Incident and Threat Management2-14Physical Security2-15Web Application Security
3 Cybersecurity Resilience
3-1Cybersecurity Resilience Aspects of Business Continuity Management (BCM)
4 Third-Party and Cloud Computing Cybersecurity
4-1Third-Party Cybersecurity4-2Cloud Computing and Hosting Cybersecurity
- retained
- Same obligation as ECC-1, possibly renumbered.
- changed
- Obligation materially reworded / expanded / narrowed.
- split
- One ECC-1 control became several ECC-2 controls.
- merged
- Several ECC-1 controls collapsed into one ECC-2 control.
- moved-out
- Left ECC entirely (e.g. to OT controls, SDAIA/NDMO).
- deleted
- Dropped with no ECC-2 successor.
- new
- New in ECC-2 with no ECC-1 predecessor.
Coverage: of 114 lineage rows, 38 carry an ISO 27001 mapping and 38 a SAMA CSF mapping. Blank cells are labelled by cause: "not in curated pass" means not yet mapped; "no equivalent identified" means the curated pass checked the control and found none (1 row); "no ECC-2 control" marks the 6 moved-out or deleted rows, which have nothing to map.
| ECC ref | Control | Status vs ECC-1 | ISO 27001 | SAMA CSF |
|---|---|---|---|---|
1-1-1 |
Cybersecurity strategy defined, documented, approved | retained | 5.1Policies for information security |
3.1.2Cyber Security Strategy |
1-1-2 |
Action plan executed to apply the strategy | retained | not in curated pass | not in curated pass |
1-1-3 |
Periodic strategy review | retained | not in curated pass | not in curated pass |
1-2-1 |
Independent cybersecurity department established | retained | Clause 5.3Organizational roles, responsibilities and authorities (ISMS clause) |
3.1.1Cyber Security Governance |
1-2-2 |
Full-time, qualified Saudi cybersecurity staff ECC-1 required Saudis in CISO, supervisory, and critical positions; ECC-2 extends the full-time Saudi requirement to all cybersecurity positions. | changed | not in curated pass | not in curated pass |
1-2-3 |
Cybersecurity supervisory committee | retained | 5.2Information security roles and responsibilities |
3.1.1Cyber Security Governance |
1-3-1 |
Policies and procedures documented and approved Core obligation retained (documented, approved, communicated policies), but ECC-2 drops ECC-1's explicit dissemination to parties outside the organization and widens the drafting duty to include cybersecurity controls and requirements. | changed | 5.1Policies for information security |
3.1.3Cyber Security Policy |
1-3-2 |
Policies and procedures implemented | retained | not in curated pass | not in curated pass |
1-3-3 |
Policies supported by technical security standards | retained | not in curated pass | not in curated pass |
1-3-4 |
Periodic policy review | retained | not in curated pass | not in curated pass |
1-4-1 |
Cybersecurity roles and responsibilities defined | retained | not in curated pass | not in curated pass |
1-4-2 |
Periodic roles-and-responsibilities review | retained | not in curated pass | not in curated pass |
1-5-1 |
Risk-management methodology approved | retained | Clause 6.1.2Information security risk assessment (ISMS clause) |
3.2.1Cyber Security Risk Management |
1-5-2 |
Risk-management methodology implemented | retained | not in curated pass | not in curated pass |
1-5-3 |
Risk-assessment trigger cases (projects, changes, third parties, launches) | retained | not in curated pass | not in curated pass |
1-5-4 |
Periodic risk-methodology review | retained | not in curated pass | not in curated pass |
1-6-1 |
Cybersecurity in project and asset change management | retained | not in curated pass | not in curated pass |
1-6-2 |
Minimum project/change security requirements | retained | not in curated pass | not in curated pass |
1-6-3 |
Secure software and application development requirements | retained | not in curated pass | not in curated pass |
1-6-4 |
Periodic project-security review | retained | not in curated pass | not in curated pass |
1-7-1 |
Compliance with nationally approved international commitments Carries ECC-1 1-7-2, renumbered after 1-7-1 was deleted; Appendix C reworks it into conditional form (identify and comply with cybersecurity requirements inside applicable international agreements). | changed | 5.31Legal, statutory, regulatory and contractual requirements |
3.2.2Regulatory Compliance |
1-8-1 |
Periodic internal cybersecurity review | retained | 5.36Compliance with policies, rules and standards for information security |
3.2.4Cyber Security Review |
1-8-2 |
Independent cybersecurity audit | retained | 5.35Independent review of information security |
3.2.5Cyber Security Audits |
1-8-3 |
Audit results documented and presented to committee and Authorized Official | retained | not in curated pass | not in curated pass |
1-9-1 |
Personnel cybersecurity requirements defined | retained | 6.2Terms and conditions of employment |
3.3.1Human Resources |
1-9-2 |
Personnel cybersecurity requirements implemented | retained | not in curated pass | not in curated pass |
1-9-3 |
Pre-employment requirements (security responsibilities, NDA clauses, screening/vetting) | retained | 6.2Terms and conditions of employment |
3.3.1Human Resources |
1-9-4 |
During-employment requirements (awareness, compliance) | retained | not in curated pass | not in curated pass |
1-9-5 |
Immediate access revocation on termination | retained | not in curated pass | not in curated pass |
1-9-6 |
Periodic personnel-requirements review | retained | not in curated pass | not in curated pass |
1-10-1 |
Awareness program developed and approved | retained | 6.3Information security awareness, education and training |
3.1.6Cyber Security Awareness |
1-10-2 |
Awareness program implemented | retained | not in curated pass | not in curated pass |
1-10-3 |
Minimum awareness topics (phishing, mobile, browsing, social media) | retained | not in curated pass | not in curated pass |
1-10-4 |
Specialized training for cybersecurity-linked roles | retained | not in curated pass | 3.1.7Cyber Security Training |
1-10-5 |
Periodic awareness-program review | retained | not in curated pass | not in curated pass |
2-1-1 |
Asset-management requirements defined | retained | 5.9Inventory of information and other associated assets |
3.3.3Asset Management |
2-1-2 |
Asset-management requirements implemented | retained | not in curated pass | not in curated pass |
2-1-3 |
Acceptable-use policy defined and communicated | retained | 5.10Acceptable use of information and other associated assets |
no equivalent identified |
2-1-4 |
Acceptable-use policy implemented | retained | not in curated pass | not in curated pass |
2-1-5 |
Assets classified, labeled, and handled per regulation | retained | 5.12Classification of information |
3.3.3Asset Management |
2-1-6 |
Periodic asset-requirements review | retained | not in curated pass | not in curated pass |
2-2-1 |
IAM requirements defined | retained | 5.15Access control |
3.3.5Identity and Access Management |
2-2-2 |
IAM requirements implemented | retained | not in curated pass | not in curated pass |
2-2-3 |
Minimum IAM requirements (authentication, MFA, least privilege, PAM, periodic review) MFA becomes risk-based: authentication factors are chosen from an impact assessment for remote access and privileged accounts, where ECC-1 mandated MFA for remote access outright. | changed | 8.5Secure authentication |
3.3.5Identity and Access Management |
2-2-4 |
Periodic IAM review | retained | not in curated pass | not in curated pass |
2-3-1 |
System-protection requirements defined | retained | 8.7Protection against malware |
3.3.8Infrastructure Security |
2-3-2 |
System-protection requirements implemented | retained | not in curated pass | not in curated pass |
2-3-3 |
Minimum system protection (anti-malware, external media, patching, clock sync) | retained | 8.7Protection against malware |
3.3.8Infrastructure Security |
2-3-4 |
Periodic system-protection review | retained | not in curated pass | not in curated pass |
2-4-1 |
Email-protection requirements defined | retained | 5.14Information transfer |
3.3.8Infrastructure Security |
2-4-2 |
Email-protection requirements implemented | retained | not in curated pass | not in curated pass |
2-4-3 |
Minimum email protection (filtering, MFA, archiving, APT, SPF/DKIM/DMARC) Adds DKIM and DMARC alongside ECC-1's SPF-only domain validation, and moves email MFA to risk-based factor selection. | changed | not in curated pass | not in curated pass |
2-4-4 |
Periodic email-protection review | retained | not in curated pass | not in curated pass |
2-5-1 |
Network-security requirements defined | retained | 8.20Networks security |
3.3.8Infrastructure Security |
2-5-2 |
Network-security requirements implemented | retained | not in curated pass | not in curated pass |
2-5-3 |
Minimum network security (segmentation, secure browsing, wireless, IPS, DNS, DDoS) Adds an explicit DDoS-protection subcontrol (2-5-3-9; Appendix C itemized addition). | changed | 8.20Networks security |
3.3.8Infrastructure Security |
2-5-4 |
Periodic network-security review | retained | not in curated pass | not in curated pass |
2-6-1 |
Mobile/BYOD security requirements defined | retained | 8.1User endpoint devices |
3.3.10Bring Your Own Device (BYOD) |
2-6-2 |
Mobile/BYOD security requirements implemented | retained | not in curated pass | not in curated pass |
2-6-3 |
Minimum mobile/BYOD security (encryption, restriction, secure deletion, awareness) | retained | not in curated pass | not in curated pass |
2-6-4 |
Periodic mobile-security review | retained | not in curated pass | not in curated pass |
2-7-1 |
Data-protection requirements defined per legal requirements | retained | 8.12Data leakage prevention |
3.3.3Asset Management |
2-7-2 |
Data protection implemented by classification level Appendix C: implementation is now driven by the data's classification level; ECC-1's separate ownership/classification/privacy minimums control (2-7-3) moved out of ECC (privacy to SDAIA/NDMO; classification continues under 2-1-5). | changed | not in curated pass | not in curated pass |
2-7-3 |
Periodic data-protection review | retained | not in curated pass | not in curated pass |
2-8-1 |
Cryptography requirements defined | retained | 8.24Use of cryptography |
3.3.9Cryptography |
2-8-2 |
Cryptography requirements implemented | retained | not in curated pass | not in curated pass |
2-8-3 |
National Cryptographic Standards applied by level (keys, in-transit/at-rest) Now mandates the NCA National Cryptographic Standards (NCS-1:2020) at the level matched to data sensitivity; ECC-1 referenced approved standards generically. | changed | not in curated pass | not in curated pass |
2-8-4 |
Periodic cryptography review | retained | not in curated pass | not in curated pass |
2-9-1 |
Backup-and-recovery requirements defined | retained | 8.13Information backup |
3.3.8Infrastructure Security |
2-9-2 |
Backup-and-recovery requirements implemented | retained | not in curated pass | not in curated pass |
2-9-3 |
Minimum backup requirements (critical scope, quick recovery, periodic testing) | retained | not in curated pass | not in curated pass |
2-9-4 |
Periodic backup-requirements review | retained | not in curated pass | not in curated pass |
2-10-1 |
Vulnerability-management requirements defined | retained | 8.8Management of technical vulnerabilities |
3.3.17Vulnerability Management |
2-10-2 |
Vulnerability-management requirements implemented | retained | not in curated pass | not in curated pass |
2-10-3 |
Minimum vulnerability management (assessment, classification, remediation, verified patching, intel subscription) Patch fixes must now be verified in a non-production environment before rollout (direct text comparison of 2-10-3-4; not itemized in the official Appendix C table). | changed | not in curated pass | not in curated pass |
2-10-4 |
Periodic vulnerability-management review | retained | not in curated pass | not in curated pass |
2-11-1 |
Penetration-testing requirements defined | retained | 8.8Management of technical vulnerabilities |
3.2.4Cyber Security Review |
2-11-2 |
Penetration-testing requirements implemented | retained | not in curated pass | not in curated pass |
2-11-3 |
Minimum penetration-testing scope (all internet-facing services) and cadence | retained | not in curated pass | not in curated pass |
2-11-4 |
Periodic penetration-testing review | retained | not in curated pass | not in curated pass |
2-12-1 |
Logging-and-monitoring requirements defined | retained | 8.15Logging |
3.3.14Cyber Security Event Management |
2-12-2 |
Logging-and-monitoring requirements implemented | retained | not in curated pass | not in curated pass |
2-12-3 |
Minimum logging (critical assets, privileged/remote access, SIEM, continuous monitoring, 12-month retention) | retained | 8.15Logging |
3.3.14Cyber Security Event Management |
2-12-4 |
Periodic logging review | retained | not in curated pass | not in curated pass |
2-13-1 |
Incident-and-threat-management requirements defined | retained | 5.24Information security incident management planning and preparation |
3.3.15Cyber Security Incident Management |
2-13-2 |
Incident-and-threat-management requirements implemented | retained | not in curated pass | not in curated pass |
2-13-3 |
Minimum incident management (response plans, classification, NCA reporting and sharing, threat intel) | retained | not in curated pass | not in curated pass |
2-13-4 |
Periodic incident-management review | retained | not in curated pass | not in curated pass |
2-14-1 |
Physical-security requirements defined | retained | 7.1Physical security perimeters |
3.3.2Physical Security |
2-14-2 |
Physical-security requirements implemented | retained | not in curated pass | not in curated pass |
2-14-3 |
Minimum physical security (critical-area access, CCTV, log protection, secure destruction, device security) | retained | not in curated pass | not in curated pass |
2-14-4 |
Periodic physical-security review | retained | not in curated pass | not in curated pass |
2-15-1 |
External web-application security requirements defined | retained | 8.26Application security requirements |
3.3.6Application Security |
2-15-2 |
Web-application-security requirements implemented | retained | not in curated pass | not in curated pass |
2-15-3 |
Minimum web-application security (WAF, multi-tier, HTTPS, usage policy, risk-based authentication) ECC-1's blanket user MFA (2-15-3-5) becomes risk-based authentication driven by an impact assessment of authentication failure and bypass. | changed | not in curated pass | not in curated pass |
2-15-4 |
Periodic web-application-security review | retained | not in curated pass | not in curated pass |
3-1-1 |
Resilience requirements within BCM defined | retained | 5.29Information security during disruption |
3.1.3Cyber Security Policy |
3-1-2 |
Resilience requirements within BCM implemented | retained | not in curated pass | not in curated pass |
3-1-3 |
Minimum resilience requirements (continuity of security systems, incident response plans, DRP) | retained | 5.30ICT readiness for business continuity |
3.3.15Cyber Security Incident Management |
3-1-4 |
Periodic BCM-resilience review | retained | not in curated pass | not in curated pass |
4-1-1 |
Third-party contract cybersecurity requirements defined | retained | 5.20Addressing information security within supplier agreements |
3.4.1Contract and Vendor Management |
4-1-2 |
Minimum third-party contract clauses (NDA/secure removal, incident communication, policy compliance) | retained | 5.20Addressing information security within supplier agreements |
3.4.1Contract and Vendor Management |
4-1-3 |
Outsourcing safeguards (risk assessment, mitigation, KSA location for remotely accessed managed SOCs) Appendix C broadens scope from IT outsourcing/managed services to third parties providing IT outsourcing, cybersecurity outsourcing, or managed services. | changed | 5.20Addressing information security within supplier agreements |
3.4.2Outsourcing |
4-1-4 |
Periodic third-party-requirements review | retained | not in curated pass | not in curated pass |
4-2-1 |
Cloud/hosting cybersecurity requirements defined | retained | 5.23Information security for use of cloud services |
3.4.3Cloud Computing |
4-2-2 |
Cloud/hosting cybersecurity requirements implemented | retained | not in curated pass | not in curated pass |
4-2-3 |
Minimum cloud requirements (classification-based protection and data return, environment separation) ECC-1's in-Kingdom hosting subcontrol (4-2-3-3) is removed. Data localization now sits with SDAIA/NDMO; classification-based protection and environment separation remain. | changed | not in curated pass | not in curated pass |
4-2-4 |
Periodic cloud-requirements review | retained | not in curated pass | not in curated pass |
ECC-1 5-1-1 |
ICS/OT cybersecurity requirements defined ECC-1 Domain 5 (ICS) left ECC entirely; operational technology now falls under NCA OTCC-1:2022. | moved-out | no ECC-2 control | no ECC-2 control |
ECC-1 5-1-2 |
ICS/OT cybersecurity requirements implemented ECC-1 Domain 5 (ICS) left ECC entirely; operational technology now falls under NCA OTCC-1:2022. | moved-out | no ECC-2 control | no ECC-2 control |
ECC-1 5-1-3 |
Minimum ICS/OT requirements (network segmentation, SIS isolation, monitoring, removable-media and mobile-device restrictions, hardening, vulnerability/patch management, anti-malware) ECC-1 Domain 5 (ICS) left ECC entirely; operational technology now falls under NCA OTCC-1:2022. | moved-out | no ECC-2 control | no ECC-2 control |
ECC-1 5-1-4 |
Periodic ICS/OT requirements review ECC-1 Domain 5 (ICS) left ECC entirely; operational technology now falls under NCA OTCC-1:2022. | moved-out | no ECC-2 control | no ECC-2 control |
ECC-1 1-7-1 |
Compliance with national cybersecurity laws and regulations No standalone ECC-2 successor; national-law compliance is embedded in every ECC-2 control's 'relevant legislative and regulatory requirements' phrasing. | deleted | no ECC-2 control | no ECC-2 control |
ECC-1 2-7-3 |
Data ownership, classification/labeling, and privacy minimums Appendix C removes ECC-1 2-7-3: privacy obligations transfer to SDAIA/NDMO mandates; classification and labeling continue inside ECC-2 under 2-1-5. | moved-out | no ECC-2 control | no ECC-2 control |
Board Risk Brief
Bank X and all figures are fictional. This example shows a board decision brief's format, not a real organisation's risk position.
How technology-risk data becomes a board decision: a one-page decision brief in the format I use: residual risk against appetite, KRIs that drive the ask, evidence lineage per data point. All figures fictional and labeled as such.
Examination Evidence Index
The five practice columns reflect general sector practice and the author's judgement. This is not a SAMA or NCA document or a complete examination request list.
What a supervisory examination typically requests, per control area: the artifact, its owner, the cadence, the form examiners accept it in, and the question asked in the room. 38 control areas mapped across ECC-2, SAMA CSF, and ITGF, with PDF and Excel downloads. Independent, illustrative guide; verified 2026-08-09.
KSA Regulatory Scope
A starting point by entity type, not a legal determination. Applicability depends on licence class, designation and data. Check each row against current official texts.
Saudi Arabia is not one regulatory stack. A scoping matrix by entity type (bank, government, CNI, cloud/telecom, personal-data processor, Aramco supplier) with each row’s primary obligation, likely add-ons, and source. Last verified 2026-08-09.
SAMA CSF ↔ ITGF ↔ NCA ECC-2 Crosswalk
The author's reading of published texts, not SAMA's interpretation; SAMA CSF §1.6 reserves that to SAMA. No maturity ratings per row or examination findings or outcomes from any institution.
The question the “SAMA CSF vs ITGF” button keeps asking, answered: the 38-control ECC-2 curated pass mapped to both SAMA frameworks, with the evidence a supervisory examination typically requests per control area. ITGF references source-verified against the official framework text on the SAMA Rulebook (AI-assisted review, last pass 2026-08-09); independently verify before use.
Also in the lab: Analysers (9) Investigate (4) Demos (5)
Analysers
Everything runs in your browser. Nothing you paste leaves this page.
Certificate & Chain Checker Paste a PEM certificate or chain. A custom DER decoder reads the fields; WebCrypto checks supported signatures. Checks internal consistency and supported signatures in the pasted chain, not platform trust. No root trust store, hostname check, online revocation check or AIA fetch.
Sample: malyahya.com's own certificate chain, captured 2026-09-10. It is a snapshot, not a live fetch.
Email Header Analyser Paste raw email headers to trace message hops, read recorded SPF/DKIM/DMARC results and spot identity mismatches. Reads the receiving server's recorded results; trusts the Authentication-Results header. Does not recheck DKIM, query DNS or inspect the message body.
Email DNS Record Checker Paste TXT records in dig or zone-file format to grade SPF, DKIM key strength and DMARC policy. Use Email Header Analyser for receiver-recorded results. Checks pasted records only, not live DNS. Makes no queries and does not follow include: targets. The lookup count covers top-level terms only.
Classical Cipher Solver Paste ciphertext to remove common encodings and try Caesar, Vigenère and XOR solutions. Vigenère analysis uses repeated sequences (Kasiski) and the index of coincidence. Handles Base64, hex and ROT encodings; attempts Caesar, Atbash, Vigenère, XOR and transposition ciphers. Scores candidates against English only. No modern-cipher analysis or other languages.
Security Header & CSP Checker Paste response headers for a grade using this tool's published rubric and suggested directive changes. The same input gets the same grade. Checks pasted headers only, not the live site. Fetches nothing and does not check allowed hosts for known CSP bypasses.
Sample: malyahya.com's own response headers, captured 2026-09-10. It is a snapshot, not a live fetch.
Nmap Output Analyser Paste Nmap output to review reported exposure, potentially risky services, possible end-of-support flags and suggested NCA ECC-2:2024 references. No scan runs here. Reads pasted output only. Uses reported versions and bundled support-status rules; does not verify versions or establish CVEs. Framework references are suggestions, not compliance findings.
JWT Decoder Paste a JWT to decode its header and payload and inspect alg: none, expiry, issuer and audience claims. Does not verify the signature, key strength, issuer match or audience match. Signature verification requires the relevant HMAC secret or issuer's public key.
Subnet Calculator Enter an IPv4 address/CIDR, such as 192.168.1.0/24, and press Enter for network details, masks and the binary split. Calculates one IPv4 address/CIDR locally. The type label classifies the range using the IANA special-purpose registry, not the entered host.
Log Pattern Checker Paste server logs or choose a sample to flag possible brute force, SQL injection, path traversal, XSS probes and sensitive-file access. Includes activity by IP address. Uses patterns and per-IP timing rules on the first 2 KB of each line. No reputation or location lookups. No matches does not mean safe; unmatched or unrecognised lines remain unchecked.
Also in the lab: Governance (8) Investigate (4) Demos (5)
Investigations
Four browser-based tools for data you paste or import, with fictional samples to start. Each one states its limits.
Also in the lab: Governance (8) Analysers (9) Demos (5)
Learning demos
Five local tools and scripted walkthroughs I use in awareness sessions and mentoring. No live network queries; pasted markup stays inert.
Also in the lab: Governance (8) Analysers (9) Investigate (4)
Hiring for a security role, or scoping an engagement?
Replies within two business days, in English or Arabic.