Introduction: Understanding the Saudi NCA Essential Cybersecurity Controls
The Essential Cybersecurity Controls (ECC-1:2018, updated as ECC-2:2024) are the foundational cybersecurity mandate issued by the National Cybersecurity Authority (NCA) of the Kingdom of Saudi Arabia. Born out of Royal Decree and the Kingdom's Vision 2030 digital transformation agenda, the ECC establish a minimum baseline of cybersecurity requirements that in-scope national organisations must implement, operate and continuously improve. Unlike a voluntary best-practice guide, the ECC is a regulatory instrument: compliance is not optional for the organisations to which it applies, and the NCA actively supervises adherence through self-assessment reporting, evidence submission and audit.
This deep-dive is written from the perspective of a practising cybersecurity and compliance auditor. It walks through what the ECC is, precisely who must comply, how the control framework is structured across its main and sub-domains, and — most importantly — provides a master, auditor-grade assessment checklist covering every domain, subdomain and control area, complete with what an assessor should verify and the typical evidence expected. It then sets out scoping guidance, a phased implementation approach, the NCA compliance scoring/maturity model, a repeatable assessment methodology, an evidence request list, roles and responsibilities, KPIs, a readiness checklist, common gaps, and a mapping to other major frameworks. The objective is to give a Chief Information Security Officer (CISO), GRC lead or internal auditor a genuinely usable playbook for achieving and demonstrating ECC compliance.
Copyright and licensing note
The Essential Cybersecurity Controls (ECC) are the intellectual property of the National Cybersecurity Authority (NCA), Kingdom of Saudi Arabia, and are published under the NCA's terms of use. The official document is authoritative and available from the NCA. This guide is an original, independently authored commentary and assessment aid produced by CyberSigma; it paraphrases the intent of the controls for educational purposes and does not reproduce the NCA's copyrighted control text verbatim. Always refer to the official NCA ECC publication and any sector-specific NCA directives for the exact, binding requirement wording. Control identifiers cited here follow the NCA's published numbering scheme for ease of cross-reference.
What is NCA ECC?
The NCA Essential Cybersecurity Controls are a set of mandatory cybersecurity requirements designed to raise and standardise the cybersecurity posture of Saudi Arabian organisations, with a particular focus on protecting national infrastructure, government entities and organisations that handle sensitive or critical assets. The first edition, ECC-1:2018, was issued by the NCA following its establishment in 2017 as the Kingdom's central authority for cybersecurity. A revised edition, ECC-2:2024, refreshed and clarified the controls while preserving the overall architecture.
The ECC framework is built on a layered structure of main cybersecurity domains, each broken down into subdomains, which in turn contain individual controls and sub-controls (specific, testable requirements). The 2018 edition comprises 5 main domains, 29 subdomains and 114 main controls (expanding to a larger number of sub-controls). The controls draw on and are harmonised with international standards and frameworks — including ISO/IEC 27001, the NIST Cybersecurity Framework, NIST SP 800-53, PCI DSS and CIS Controls — but are adapted to the Saudi regulatory context and national priorities.
Crucially, the ECC are risk-agnostic in the sense that they define a mandatory floor: an in-scope organisation must implement the applicable controls regardless of its own risk appetite, and may implement additional controls above the baseline where its risk assessment demands. The NCA also publishes complementary control frameworks — such as the Critical Systems Cybersecurity Controls (CSCC), the Cloud Cybersecurity Controls (CCC), the Telework Cybersecurity Controls, the Data Cybersecurity Controls (DCC) and the Operational Technology Cybersecurity Controls (OTCC) — which extend or specialise the ECC for particular contexts. The ECC remain the base layer on which these sit.
- Purpose: establish a minimum, mandatory cybersecurity baseline for in-scope national organisations.
- Legal basis: issued by the NCA under Royal Order/Decree authority; supervised and enforced by the NCA.
- Editions: ECC-1:2018 (original) and ECC-2:2024 (revised).
- Architecture: main domains -> subdomains -> controls -> sub-controls.
- Alignment: mapped to ISO 27001, NIST CSF, NIST 800-53, PCI DSS, CIS and other frameworks.
- Ecosystem: base layer beneath the NCA's CSCC, CCC, DCC, OTCC and other specialised control sets.
Who must comply with NCA ECC?
The ECC apply to a defined population of organisations operating in or serving the Kingdom of Saudi Arabia. The NCA describes the scope broadly as government organisations and organisations affiliated with them, private-sector organisations that own, operate or host Critical National Infrastructure (CNI), and — as strongly encouraged good practice — other organisations in the Kingdom. In practice, compliance obligations flow from the NCA's mandate letters, sector regulators and the classification of an organisation's systems.
| Entity category | Applicability of ECC |
|---|
| Government ministries, authorities and agencies | Mandatory — full applicability. |
| Government-affiliated / semi-government bodies and their subsidiaries | Mandatory — full applicability. |
| Owners/operators of Critical National Infrastructure (CNI) | Mandatory — full applicability, often layered with CSCC for critical systems. |
| Private-sector organisations providing services to government entities | Mandatory in respect of the relevant systems/services; contractually cascaded. |
| Operators of critical systems (per NCA critical-system classification) | Mandatory ECC baseline PLUS the Critical Systems Cybersecurity Controls (CSCC). |
| Cloud service providers and tenants serving in-scope entities | ECC baseline PLUS Cloud Cybersecurity Controls (CCC) as applicable. |
| Other private-sector organisations in the Kingdom | Strongly encouraged as best practice; may become mandatory via sector regulators. |
Third-party and supply-chain cascade
Even where an organisation is not directly named by the NCA, ECC obligations frequently cascade contractually. A private company that hosts, processes or provides services to a government or CNI entity will typically be required, through contract clauses, to meet the relevant ECC controls for the systems in question. Vendors should assume ECC exposure if any of their Saudi public-sector clients handle national or critical data.
Structure of NCA ECC
The ECC-1:2018 framework is organised into five main cybersecurity domains, subdivided into 29 subdomains and 114 main controls. The five domains reflect a lifecycle view of cybersecurity: governance to establish direction and accountability; defence to protect assets; resilience to withstand and recover from disruption; third-party and cloud security to manage external dependencies; and industrial control systems security to protect operational technology. The table below summarises the domains and their subdomains.
| Domain # | Main domain | Subdomains (indicative) | Approx. controls |
|---|
| 1 | Cybersecurity Governance | Strategy; Management; Policies & Procedures; Roles & Responsibilities; Risk Management; Cybersecurity in Project Management; Compliance with Regulations; Periodic Review & Audit; Human Resources; Awareness & Training | ~30 |
| 2 | Cybersecurity Defence | Asset Management; Identity & Access Management; Information System & Processing Facilities Protection; Email Protection; Networks Security Management; Mobile Devices Security; Data & Information Protection; Cryptography; Backup & Recovery Management; Vulnerability Management; Penetration Testing; Cybersecurity Event Logs & Monitoring; Cybersecurity Incident & Threat Management; Physical Security; Web Application Security | ~52 |
| 3 | Cybersecurity Resilience | Cybersecurity Resilience Aspects of Business Continuity Management (BCM) | ~3 |
| 4 | Third-Party & Cloud Computing Cybersecurity | Third-Party Cybersecurity; Cloud Computing & Hosting Cybersecurity | ~7 |
| 5 | Industrial Control Systems (ICS) Cybersecurity | Industrial Control Systems (ICS) Protection | ~22 (across sub-controls) |
Each control is identified by a hierarchical number of the form Domain-Subdomain-Control (for example, 1-1-1 is the first control of the first subdomain of the Governance domain). Sub-controls extend this further (for example, 2-2-3-1). The NCA's compliance tooling requires organisations to record an implementation status against each applicable control and to hold evidence supporting the claimed status.
Master assessment checklist
This is the core of the guide. Below, every ECC main domain is broken down into its subdomains, and for each subdomain an assessment table sets out what an auditor should verify and the typical evidence expected. The checklist is designed so that a reviewer can walk it control-by-control. It deliberately covers ALL five domains and every subdomain so that no control area is skipped. Where a subdomain contains multiple related controls, the assessment rows group verification points logically; assessors should still map findings back to the specific NCA control identifier.
1-1 to 1-2 Cybersecurity Strategy and Management
| What to verify | Typical evidence |
|---|
| A documented cybersecurity strategy exists, is approved by the head of the organisation (or delegate), and aligns with the organisation's objectives and the NCA's national priorities. | Signed cybersecurity strategy document; approval minutes; alignment statement to organisational strategy. |
| A dedicated cybersecurity function/department exists, is independent of IT operations and internal audit, and reports to a senior/executive level. | Organisation chart; charter of the cybersecurity function; reporting-line evidence; CISO appointment letter. |
| The strategy is supported by an implementation roadmap and adequate budget and resources. | Roadmap; approved budget lines; resource/headcount plan. |
| The strategy and management arrangements are reviewed periodically and after major changes. | Review records; version history; change-triggered review notes. |
1-3 Cybersecurity Policies and Procedures
| What to verify | Typical evidence |
|---|
| A comprehensive set of cybersecurity policies and supporting procedures exists, covering the ECC control areas, and is formally approved. | Policy register; approved master information security policy and sub-policies; approval signatures. |
| Policies are communicated to relevant personnel and are accessible. | Communication logs; intranet/portal links; acknowledgement records. |
| Policies are reviewed at planned intervals and updated after significant changes or incidents. | Review schedule; version history; post-incident policy updates. |
| Compliance with policies is enforced and monitored. | Compliance monitoring reports; exception/waiver register; disciplinary policy linkage. |
1-4 Cybersecurity Roles and Responsibilities
| What to verify | Typical evidence |
|---|
| Cybersecurity roles and responsibilities are defined, documented, assigned and approved across the organisation. | RACI matrix; role descriptions; appointment records for CISO and key roles. |
| Segregation of duties is applied to prevent conflicts of interest (e.g., between security operation and audit). | SoD matrix; access review evidence; role-conflict analysis. |
| Responsibilities are reviewed and kept current as the organisation changes. | Periodic review of RACI; updates following restructures. |
1-5 Cybersecurity Risk Management
| What to verify | Typical evidence |
|---|
| A documented cybersecurity risk-management methodology is defined, approved and applied. | Risk-management methodology/policy; risk criteria and appetite statement. |
| Cybersecurity risks are identified, assessed and treated, with a maintained risk register. | Risk register; risk assessment reports; treatment plans. |
| Risk assessments are performed at least annually, before major changes, and for new projects/systems. | Assessment records with dates; change-triggered assessments; project risk assessments. |
| Residual risks are formally accepted by risk owners at the appropriate level. | Risk-acceptance sign-offs; residual-risk register. |
1-6 Cybersecurity in Information Technology Projects
| What to verify | Typical evidence |
|---|
| Cybersecurity requirements are embedded in the project and change-management lifecycle from initiation. | Project management framework; secure SDLC standard; security gate/checklist in project stages. |
| Security requirements are defined for new/modified systems and validated before go-live. | Security requirement specifications; pre-go-live security review/sign-off. |
| Software development follows secure coding and testing practices. | Secure coding standard; SAST/DAST results; code review records. |
1-7 Cybersecurity Compliance with Standards, Laws and Regulations
| What to verify | Typical evidence |
|---|
| The organisation identifies and complies with applicable cybersecurity laws, regulations and NCA directives. | Legal/regulatory register; compliance obligations mapping to controls. |
| Compliance status is monitored and reported to management and, where required, to the NCA. | Compliance reports; NCA submission records; management review minutes. |
| Non-compliance is tracked and remediated. | Non-compliance/CAP register; remediation evidence. |
1-8 Periodic Cybersecurity Review and Audit
| What to verify | Typical evidence |
|---|
| Cybersecurity implementation is reviewed periodically by the cybersecurity function. | Internal review reports; review schedule. |
| Independent cybersecurity audits are conducted (by internal audit or an independent third party) at planned intervals. | Audit plan; audit reports; auditor independence confirmation. |
| Audit findings are tracked to closure with corrective action plans. | Findings/CAP tracker; closure evidence; follow-up audit records. |
1-9 Cybersecurity in Human Resources
| What to verify | Typical evidence |
|---|
| Cybersecurity responsibilities are addressed before, during and after employment. | HR security policy; employment contracts with security clauses; NDAs. |
| Screening/vetting is performed for personnel, especially those in sensitive roles. | Background-check records (subject to law); role sensitivity classification. |
| Access is revoked and assets returned promptly on role change or termination. | Joiner-mover-leaver process; deprovisioning tickets; asset-return forms. |
1-10 Cybersecurity Awareness and Training
| What to verify | Typical evidence |
|---|
| A cybersecurity awareness programme exists and reaches all personnel. | Awareness programme plan; attendance/completion records; campaign materials. |
| Awareness content covers current threats (e.g., phishing, social engineering, secure handling of data). | Course content; phishing simulation results and trends. |
| Specialised/technical training is provided to cybersecurity and privileged personnel. | Training records; certifications; competency matrix. |
2-1 Asset Management
| What to verify | Typical evidence |
|---|
| A complete, accurate and maintained inventory of information and technology assets exists, with ownership assigned. | Asset inventory/CMDB; asset owner assignments; reconciliation records. |
| Assets are classified and handled according to a classification scheme. | Classification policy; labelled assets; handling procedures. |
| Acceptable-use requirements are defined and acknowledged. | Acceptable-use policy; user acknowledgements. |
2-2 Identity and Access Management (IAM)
| What to verify | Typical evidence |
|---|
| User access is provisioned on the principle of least privilege and need-to-know, and approved. | Access request/approval workflow; least-privilege standard; role-based access model. |
| Multi-factor authentication (MFA) is enforced for remote access and privileged/critical access. | MFA configuration; VPN/remote-access policy; MFA enrolment reports. |
| Privileged access is restricted, monitored and reviewed; shared/default accounts are controlled. | PAM tooling records; privileged-account inventory; session monitoring logs. |
| Periodic access reviews (recertification) are performed and stale/orphan accounts removed. | Access recertification reports; disabled-account evidence; review sign-offs. |
| Strong password/authentication policy is enforced. | Password policy configuration; identity provider settings. |
2-3 Information System and Information Processing Facilities Protection
| What to verify | Typical evidence |
|---|
| Systems and servers are hardened to approved secure baselines/benchmarks. | Hardening standards (e.g., CIS-based); configuration compliance scans; golden images. |
| Anti-malware/endpoint protection is deployed, updated and monitored across endpoints and servers. | EPP/EDR console reports; coverage metrics; signature/engine status. |
| Patch management ensures timely deployment of security updates. | Patch policy with SLAs; patch compliance reports; exception register. |
| Change management governs configuration changes. | Change records; CAB approvals; rollback plans. |
2-4 Email Protection
| What to verify | Typical evidence |
|---|
| Email is protected against spam, phishing and malware through filtering and scanning. | Secure email gateway configuration; filtering reports; quarantine logs. |
| Email authentication (SPF, DKIM, DMARC) is configured to prevent spoofing. | DNS records for SPF/DKIM/DMARC; DMARC reports. |
| Email content and attachments are inspected; suspicious activity is monitored. | Attachment sandboxing config; alerting evidence. |
2-5 Networks Security Management
| What to verify | Typical evidence |
|---|
| The network is segmented/zoned to isolate critical systems and limit lateral movement. | Network architecture diagrams; segmentation/VLAN configs; firewall zone policy. |
| Perimeter and internal controls (firewalls, IDS/IPS) are deployed and rule-sets are reviewed. | Firewall/IPS configurations; rule-review records; DMZ design. |
| Wireless networks are secured and remote access is controlled. | Wireless security config; VPN policy; NAC evidence. |
| Network traffic is monitored for threats. | Monitoring/telemetry evidence; anomaly alerts. |
2-6 Mobile Devices Security
| What to verify | Typical evidence |
|---|
| Mobile and BYOD devices accessing organisational resources are managed and secured. | MDM/UEM enrolment reports; mobile security policy. |
| Data separation, encryption and remote wipe are enforced on mobile devices. | MDM policy config; encryption status; remote-wipe capability evidence. |
| Lost/stolen device handling is defined. | Incident procedure for lost devices; wipe logs. |
2-7 Data and Information Protection
| What to verify | Typical evidence |
|---|
| Data is classified and protected according to its classification throughout its lifecycle. | Data classification policy; DLP policy; handling procedures. |
| Data leakage prevention controls are implemented for sensitive data. | DLP tool configuration and reports; endpoint/network/email DLP evidence. |
| Data retention and secure disposal are defined and enforced. | Retention schedule; secure disposal/destruction certificates. |
2-8 Cryptography
| What to verify | Typical evidence |
|---|
| Approved cryptographic standards and algorithms are used; deprecated ciphers are prohibited. | Cryptography policy/standard; approved-algorithm list; TLS configuration scans. |
| Sensitive data is encrypted in transit and at rest per policy. | Encryption inventory; at-rest/in-transit configuration evidence. |
| Cryptographic keys are securely generated, stored, rotated and destroyed. | Key-management procedure; HSM/KMS records; key-rotation logs. |
2-9 Backup and Recovery Management
| What to verify | Typical evidence |
|---|
| Backups of critical data and systems are performed per a defined schedule. | Backup policy; backup job logs; scope/coverage list. |
| Backups are protected (encrypted, access-controlled) and stored securely, including offline/off-site copies. | Backup encryption config; storage location evidence; immutable/air-gapped copy evidence. |
| Restoration is tested periodically to confirm recoverability. | Restore-test records; RTO/RPO validation results. |
2-10 Vulnerability Management
| What to verify | Typical evidence |
|---|
| Vulnerability scanning is performed regularly across in-scope assets. | Scan schedule; scan reports; asset coverage. |
| Vulnerabilities are risk-rated and remediated within defined SLAs. | Remediation SLAs; ticketing evidence; re-scan/closure records. |
| Threat intelligence informs prioritisation. | Threat-intel feeds; prioritisation notes. |
2-11 Penetration Testing
| What to verify | Typical evidence |
|---|
| Penetration tests are conducted periodically and after major changes on internet-facing and critical systems. | Pen-test scope and schedule; pen-test reports. |
| Findings are remediated and retested. | Remediation tracker; retest confirmation. |
| Testers are competent/qualified and testing is authorised. | Tester credentials; rules of engagement; authorisation records. |
2-12 Cybersecurity Event Logs and Monitoring Management
| What to verify | Typical evidence |
|---|
| Security event logs are collected from critical systems and retained for a defined period. | Logging policy; log sources list; retention configuration. |
| Logs are centralised (e.g., SIEM) and monitored for security events. | SIEM configuration; use-cases/correlation rules; monitoring evidence. |
| Log integrity and access are protected. | Log-protection controls; access restrictions; tamper-evidence. |
| Time synchronisation is enforced across systems. | NTP configuration. |
2-13 Cybersecurity Incident and Threat Management
| What to verify | Typical evidence |
|---|
| An incident response plan defines detection, classification, escalation, containment, eradication and recovery. | IR plan/playbooks; classification matrix; contact/escalation list. |
| Incidents are reported to the NCA (and relevant parties) within required timeframes. | NCA notification procedure; incident notification records. |
| Incidents are logged, investigated and closed with lessons learned. | Incident register; investigation reports; post-incident reviews. |
| Threat intelligence is used to detect and pre-empt threats. | Threat-intel integration; proactive detection evidence. |
2-14 Physical Security
| What to verify | Typical evidence |
|---|
| Physical access to facilities, data centres and equipment is controlled and monitored. | Physical access control system; access logs; visitor management. |
| Environmental controls protect equipment (power, cooling, fire suppression). | Data centre environmental control records; UPS/generator; fire-suppression maintenance. |
| Secure disposal of physical media is enforced. | Media destruction records/certificates. |
2-15 Web Application Security
| What to verify | Typical evidence |
|---|
| External-facing web applications are protected (e.g., WAF) and follow secure development practices. | WAF configuration; secure SDLC evidence; OWASP-aligned testing. |
| Multi-tier architecture and secure session/authentication management are used. | Architecture diagrams; session-management configuration. |
| Web applications are tested for vulnerabilities before and after release. | Application security test reports; remediation evidence. |
3-1 Cybersecurity Resilience Aspects of Business Continuity Management (BCM)
| What to verify | Typical evidence |
|---|
| Cybersecurity requirements are integrated into the organisation's business continuity management. | BCM policy referencing cybersecurity; BIA including cyber scenarios. |
| Continuity plans address cybersecurity incidents and ensure the resilience of cybersecurity systems themselves. | Continuity/DR plans; resilience arrangements for security tooling. |
| Continuity and disaster-recovery arrangements are tested. | DR/BCM test plans and results; RTO/RPO validation. |
4-1 Third-Party Cybersecurity
| What to verify | Typical evidence |
|---|
| Cybersecurity requirements are defined in contracts/agreements with third parties before engagement. | Contract clauses; third-party security requirements; NDAs. |
| Third-party risk is assessed prior to and during engagement. | Vendor risk assessments; due-diligence records; risk ratings. |
| Third-party compliance is monitored and access is controlled and revoked at end of engagement. | Monitoring reports; audit rights evidence; offboarding/access-revocation records. |
| Requirements cover outsourcing and managed services, including data handling. | Outsourcing agreements; data-processing terms. |
4-2 Cloud Computing and Hosting Cybersecurity
| What to verify | Typical evidence |
|---|
| Cloud and hosting services meet ECC (and, where applicable, NCA Cloud Cybersecurity Controls) requirements. | Cloud security policy; CSP compliance attestations; CCC applicability mapping. |
| Data residency/hosting-location and sovereignty requirements are met (e.g., in-Kingdom hosting where mandated). | Hosting-location evidence; data-residency contractual terms. |
| Responsibilities are clearly split between provider and tenant (shared-responsibility model). | Shared-responsibility matrix; configuration ownership documentation. |
| Cloud configurations are hardened and monitored. | CSPM reports; secure configuration baselines; access controls. |
5-1 Industrial Control Systems (ICS) Protection
| What to verify | Typical evidence |
|---|
| ICS/OT environments are inventoried, segmented and isolated from corporate IT networks. | OT asset inventory; network segmentation (e.g., zones/conduits); firewall/DMZ between IT and OT. |
| Access to ICS is strictly controlled, with MFA for remote access and least privilege. | OT access policy; remote-access controls; privileged-access records. |
| ICS-appropriate patching, hardening and change control are applied (with vendor/safety considerations). | OT patch/change procedures; hardening records; maintenance windows. |
| ICS monitoring, logging and incident response are in place and tailored to OT. | OT monitoring tooling; OT-specific IR playbooks; log evidence. |
| Physical and environmental protection of ICS is enforced. | Physical security for OT sites; environmental controls. |
Applicability note for Domain 5
The Industrial Control Systems domain applies only to organisations that own or operate ICS/OT (for example, utilities, energy, manufacturing and critical infrastructure). Organisations without OT environments will scope this domain out with documented justification. Where ICS is present and critical, the NCA's Operational Technology Cybersecurity Controls (OTCC) and Critical Systems Cybersecurity Controls (CSCC) typically apply in addition to the ECC.
Scoping
Scoping the ECC correctly is essential to avoid both under-compliance (leaving mandatory controls unimplemented) and wasted effort (assessing controls that genuinely do not apply). Because the ECC define a mandatory baseline, the default position is that all controls apply; any exclusion must be justified and documented, and the NCA expects a defensible rationale.
- Confirm applicability: establish whether the organisation is in scope by category (government, affiliated, CNI, service-provider to public sector) and record the basis.
- Inventory assets, systems and data: identify information assets, systems, networks, cloud services and any OT/ICS environments.
- Classify systems: determine whether any systems meet the NCA's critical-system criteria, which would trigger the CSCC in addition to the ECC.
- Determine domain applicability: all governance, defence and resilience domains apply; Domain 5 (ICS) applies only where OT exists; cloud subdomain applies where cloud/hosting is used.
- Document justified exclusions: for any control marked Not Applicable, record a clear, evidence-backed justification (e.g., no wireless networks, no mobile devices, no ICS).
- Map layered frameworks: identify where CSCC, CCC, DCC, OTCC or telework controls layer on top of the ECC baseline.
- Define boundaries: agree the assessment boundary (entities, locations, systems, third parties) and capture it in a scope statement approved by management.
Not Applicable is not a free pass
Marking a control Not Applicable requires evidence that the underlying technology or process genuinely does not exist in the environment. If a capability could exist but simply has not been implemented, the correct status is Not Implemented (a gap), not Not Applicable. Auditors and the NCA will challenge weak NA justifications.
Implementation approach
A structured, phased programme is the most reliable route to ECC compliance. The following phases take an organisation from initiation to sustained compliance and continuous improvement. Each phase lists key activities and the deliverables an assessor would expect to see.
Phase 1: Initiation and governance
- Activities: secure executive sponsorship; establish/confirm the cybersecurity function and CISO; define programme governance; confirm ECC applicability and layered controls.
- Deliverables: programme charter; sponsor mandate; governance/steering structure; applicability determination.
Phase 2: Gap assessment (as-is baseline)
- Activities: assess current implementation status against every applicable control; collect initial evidence; rate maturity; identify gaps and risks.
- Deliverables: ECC gap assessment report; control-by-control status; prioritised gap register; heat map.
Phase 3: Planning and design
- Activities: prioritise remediation by risk and effort; design policies, processes and technical controls; assign owners; build the remediation roadmap and budget.
- Deliverables: remediation roadmap; policy/architecture designs; RACI; resourced project plan.
Phase 4: Implementation and remediation
- Activities: publish and socialise policies and procedures; deploy and configure technical controls (IAM/MFA, EDR, SIEM, backup, DLP, segmentation, etc.); embed security in projects and HR processes.
- Deliverables: approved policy set; implemented controls; configuration baselines; awareness programme live.
Phase 5: Assessment, evidence and NCA reporting
- Activities: conduct internal review/audit; assemble the evidence pack per control; complete the NCA self-assessment/compliance submission; remediate residual findings.
- Deliverables: evidence repository; internal audit report; NCA compliance report/self-assessment; corrective action plans.
Phase 6: Operate, monitor and continuously improve
- Activities: operate controls day-to-day; monitor KPIs; run periodic reviews, audits, vulnerability scans and pen tests; update controls after changes and incidents; prepare for re-assessment.
- Deliverables: KPI dashboards; review/audit cadence records; updated risk register; continuous-improvement log.
Compliance scoring and maturity model
The NCA assesses ECC compliance using an implementation-status scoring approach: each applicable control is rated on how completely and consistently it is implemented, and these ratings roll up into an overall compliance score/level. Organisations should express control status using a consistent scale. The table below sets out a representative maturity/implementation scale aligned to the way NCA compliance is evaluated; organisations should adopt the specific scale mandated in current NCA guidance.
| Level | Label | Description | Typical score band |
|---|
| 1 | Not Implemented | The control is not in place; no meaningful activity or evidence exists. | 0% |
| 2 | Partially Implemented | The control is partially in place or applied inconsistently/informally; documentation or coverage is incomplete. | 1-49% |
| 3 | Implemented | The control is fully documented and operating across the defined scope, with evidence. | 50-84% |
| 4 | Implemented and Reviewed | The control is fully implemented and subject to periodic review/monitoring for effectiveness. | 85-99% |
| 5 | Implemented, Reviewed and Improved | The control is fully implemented, reviewed, measured and continuously improved (optimised). | 100% |
Scoring caveat
The NCA's official compliance tooling and periodic directives define the authoritative scoring scale, weighting and reporting format for a given assessment cycle. The scale above is an illustrative maturity model to structure internal self-assessment; always align final scoring and terminology to the current NCA compliance methodology and any sector-specific instructions.
Assessment and audit approach
A repeatable methodology ensures the assessment is defensible, evidence-based and consistent year on year. The following steps describe an auditor-grade approach to an ECC assessment.
- Plan and scope: confirm applicability, boundaries, layered controls and exclusions; agree the assessment plan and timeline with stakeholders.
- Document review: examine policies, procedures, standards, risk register, prior audit reports and the NCA applicability determination.
- Control walkthroughs: interview control owners for each domain/subdomain to understand design and operation.
- Evidence collection: gather evidence per control (configurations, logs, reports, records) and map each to the relevant control identifier.
- Technical validation: independently verify key technical controls (e.g., MFA enforcement, patch levels, hardening, backup restores, log monitoring) through sampling and tooling.
- Testing of operating effectiveness: sample records over the review period to confirm controls operate consistently, not just on paper.
- Rate implementation status: score each control on the adopted maturity/implementation scale with supporting rationale.
- Identify and rate gaps: document deficiencies, their risk, and root cause; distinguish design gaps from operating gaps.
- Report: produce a control-by-control assessment report with an overall compliance position and prioritised recommendations.
- Remediate and re-test: agree corrective action plans with owners and dates; retest to confirm closure.
- Report to NCA: complete the required self-assessment/compliance submission and maintain the evidence repository for NCA review or audit.
Evidence request list
The following categorised list captures the evidence typically requested during an ECC assessment. Assembling this pack in advance dramatically accelerates the review and the NCA submission.
- Governance: cybersecurity strategy; approved policy set and procedures; org chart and CISO appointment; RACI/SoD matrix; steering committee minutes.
- Risk and compliance: risk-management methodology; risk register; risk-acceptance sign-offs; legal/regulatory register; compliance reports; prior audit reports and CAPs.
- HR and awareness: HR security policy; employment/NDA clauses; screening records; awareness plan and completion records; phishing-simulation results; specialised training records.
- Asset and data: asset inventory/CMDB; classification policy and labelled assets; acceptable-use acknowledgements; retention schedule; disposal/destruction certificates.
- Identity and access: access-request/approval workflow; least-privilege/RBAC model; MFA configuration and reports; PAM records; access recertification reports.
- System protection: hardening standards and compliance scans; EPP/EDR reports; patch policy and compliance reports; change records.
- Network and email: network diagrams and segmentation; firewall/IPS configs and rule reviews; SPF/DKIM/DMARC records; secure email gateway reports.
- Cryptography and backup: cryptography standard and TLS scans; key-management records; backup policy, logs and successful restore-test records.
- Detection and response: logging policy and log sources; SIEM configuration and use-cases; incident register; IR plan/playbooks; NCA incident notification records.
- Testing: vulnerability scan reports; penetration test reports; remediation and retest evidence.
- Physical and resilience: physical access logs; environmental controls and maintenance; BCM/DR plans and test results.
- Third-party and cloud: contract security clauses; vendor risk assessments; cloud security policy; CSP attestations; shared-responsibility matrix; data-residency evidence.
- ICS/OT (if applicable): OT asset inventory; IT/OT segmentation evidence; OT access and patch procedures; OT monitoring and IR playbooks.
Roles and responsibilities
| Role | Key responsibilities under ECC |
|---|
| Head of Organisation (Authorising Official) | Ultimate accountability; approves the strategy and policies; ensures resourcing; owns the NCA compliance relationship. |
| CISO / Head of Cybersecurity | Owns and runs the cybersecurity programme; ensures ECC implementation; reports compliance status; leads incident response. |
| Cybersecurity / GRC Team | Maintains policies, risk register and evidence; performs assessments; coordinates NCA reporting and remediation tracking. |
| IT / Infrastructure Team | Implements and operates technical controls (IAM, hardening, patching, backups, network, cloud) in line with security requirements. |
| Security Operations (SOC) | Monitors logs/SIEM; detects, triages and responds to incidents; feeds threat intelligence. |
| Internal Audit | Provides independent assurance over cybersecurity controls; reports findings to management/board. |
| Risk Owners / Business Units | Own risks and residual-risk acceptance in their areas; support control implementation and evidence provision. |
| Human Resources | Executes screening, security clauses, onboarding/offboarding and awareness participation. |
| Third-Party / Procurement | Embeds security requirements in contracts; supports vendor risk assessment and monitoring. |
| ICS/OT Engineering (if applicable) | Implements and maintains OT-specific security controls with safety and availability considerations. |
KPIs to track
- Overall ECC compliance score and trend by domain and subdomain.
- Number of controls by status (Not Implemented / Partial / Implemented / Reviewed / Improved).
- Percentage of open gaps versus target remediation dates (on-time closure rate).
- Patch compliance rate and mean time to patch critical vulnerabilities.
- Vulnerability remediation SLA adherence and open critical/high vulnerability count.
- MFA coverage for remote and privileged access.
- Mean time to detect (MTTD) and mean time to respond/recover (MTTR) for incidents.
- Percentage of incidents reported to the NCA within the required timeframe.
- Awareness training completion rate and phishing-simulation failure/click rate.
- Backup success rate and successful restore-test pass rate against RTO/RPO.
- Access recertification completion rate and number of orphan/stale accounts removed.
- Third-party risk-assessment coverage of active vendors.
- Percentage of assets in the inventory with an assigned owner and classification.
Readiness checklist
- Executive sponsorship secured and an independent cybersecurity function with a CISO is established.
- ECC applicability, scope boundaries and layered controls (CSCC/CCC/OTCC as relevant) are documented and approved.
- A complete, approved cybersecurity policy and procedure set is published and communicated.
- A cybersecurity risk-management methodology and a maintained risk register are in place.
- A full, classified asset inventory with assigned owners exists.
- IAM with least privilege, MFA for remote/privileged access, and periodic access reviews is operating.
- Systems are hardened to baselines; patching, endpoint protection and change management are effective.
- Network segmentation, perimeter controls and email authentication (SPF/DKIM/DMARC) are implemented.
- Data protection, DLP, cryptography and key management meet policy.
- Backups run to schedule and successful restore tests are evidenced against RTO/RPO.
- Centralised logging/SIEM, monitoring and an NCA-aligned incident response capability are operational.
- Vulnerability scanning and penetration testing are performed with tracked remediation.
- Cybersecurity is embedded in BCM/DR, HR processes, projects and third-party/cloud arrangements.
- An awareness programme is running with measured completion and phishing results.
- An evidence repository is assembled and the internal audit plus NCA self-assessment are complete.
- A remediation roadmap addresses all identified gaps with owners and dates.
Common gaps
- Cybersecurity function not independent of IT operations or internal audit, undermining the required segregation.
- Policies exist but are not approved, communicated, or reviewed on schedule (paper compliance without adoption).
- Incomplete or outdated asset inventory, so controls cannot be applied comprehensively.
- MFA not enforced consistently for all remote and privileged access.
- Weak or missing access recertification, leaving orphan and over-privileged accounts.
- Patching and vulnerability remediation exceeding defined SLAs, with a growing exception backlog.
- Backups taken but restore tests never performed, so recoverability is unproven.
- Logging enabled but no centralised monitoring, correlation or use-cases (logs collected, not watched).
- Incident response plan not tested and NCA notification timeframes not operationalised.
- Email authentication (SPF/DKIM/DMARC) partially configured, leaving spoofing exposure.
- Third-party and cloud security requirements absent from contracts or not monitored after onboarding.
- Data residency/in-Kingdom hosting obligations not verified for cloud services.
- Not Applicable statuses used to mask Not Implemented controls, with weak justifications.
- Evidence not retained in an organised, control-mapped repository, causing delays and audit findings.
NCA ECC mapped to other frameworks
The ECC deliberately harmonise with leading international standards, which helps organisations reuse existing controls and evidence. The mapping below is indicative and thematic; it is intended to aid cross-framework rationalisation, not to assert one-to-one control equivalence. Always validate specific mappings against the authoritative control text.
| NCA ECC domain / theme | ISO/IEC 27001:2022 | NIST CSF | NIST SP 800-53 | PCI DSS / CIS |
|---|
| 1 Cybersecurity Governance | Clauses 4-10; A.5 (Organisational) | Govern; Identify | PM, PL, RA families | PCI Req. 12; CIS 14, 17 |
| 2 Cybersecurity Defence (IAM, hardening, network, crypto, monitoring) | A.5-A.8 (Org/People/Physical/Technological) | Protect; Detect | AC, IA, SC, SI, CM, AU | PCI Req. 1-8, 10; CIS 1-13, 16 |
| 2 Backup & Recovery / Vulnerability & Pen Test | A.8.13; A.8.8; A.8.29 | Protect; Detect; Recover | CP, RA, SI, CA | PCI Req. 11; CIS 7, 11 |
| 3 Cybersecurity Resilience (BCM) | A.5.29-A.5.30; Annex resilience | Recover | CP | CIS 11 (Data recovery) |
| 4 Third-Party & Cloud | A.5.19-A.5.23 | Identify; Protect | SA, SR | PCI Req. 12.8; CIS 15 |
| 5 Industrial Control Systems (ICS) | ISO 27001 + IEC 62443 alignment | Protect; Detect | 800-53 + 800-82 (ICS) | CIS controls adapted for OT |
How CyberSigma helps
CyberSigma partners with organisations across the Kingdom and the wider region to achieve, evidence and sustain NCA ECC compliance. Our CERT-In empanelled and QSA-qualified assessors run structured ECC gap assessments across all five domains, build prioritised remediation roadmaps, and stand up the governance, technical controls and evidence repositories the NCA expects. We help you scope correctly (including layered CSCC, CCC and OTCC obligations), implement IAM/MFA, SIEM, backup, DLP and network segmentation, operationalise NCA-aligned incident reporting, and prepare a defensible self-assessment submission. Beyond the first attestation, CyberSigma provides continuous compliance monitoring, KPI dashboards, periodic audits and penetration testing so your ECC posture stays audit-ready year on year. Talk to CyberSigma to turn NCA ECC from a compliance obligation into measurable cyber resilience.
