NCA Essential Cybersecurity Controls: Practical Compliance Guide

The nca essential cybersecurity controls are often mistaken for a policy checklist. They are not. ECC 2-2024 expects in-scope entities to maintain ongoing compliance across governance, defence, resilience, and third-party or cloud cybersecurity, with evidence that controls actually operate. For security and compliance teams, the practical challenge is therefore not only mapping requirements, but proving ownership, implementation, review, remediation, and applicability across the systems and services the organisation depends on.

Who the NCA Essential Cybersecurity Controls Apply To

The current nca essential cybersecurity controls define a mandatory baseline for specific Saudi entities while encouraging wider adoption across the Kingdom. Scope determines whether an organisation falls under the ECC, while applicability determines which controls are relevant to its business activities and technology environment.

Three questions clarify where an organisation stands:

1. Which Entities Fall Within the Mandatory Scope?

ECC 2-2024 identifies government organisations and entities connected with Critical National Infrastructure as its primary mandatory scope.

Government Agencies: Ministries, authorities, establishments and other Saudi government bodies fall within the stated scope.
Affiliated Entities: Companies and entities affiliated with government organisations can also fall within scope, including relevant operations outside the Kingdom.
Critical National Infrastructure: Private-sector organisations that own, operate or host Critical National Infrastructure are included.
Other Saudi Entities: Organisations outside mandatory scope are strongly encouraged by NCA to use the controls as a cybersecurity baseline.

For public-sector organisations, ECC obligations often interact with procurement, architecture, service continuity and wider transformation programmes. That broader operating environment is covered under government and public sector technology.

Digital transformation can also introduce new systems, suppliers and data flows faster than existing controls are updated. Teams dealing with that wider change can review government digital transformation saudi arabia.

2. How Does the Statement of Applicability Work?

Being within ECC scope does not mean every control applies in exactly the same way to every organisation.

Business Context: Applicability reflects the entity's operations, information assets and technology landscape.
Technology Use: Certain requirements become relevant because the organisation uses a particular technology or service model.
Cloud Example: ECC specifically states that cloud and hosting controls apply to entities already using or planning to use those services.
Documented Rationale: A practical compliance programme records why each control is applicable, partially applicable or outside the organisation's current environment.

A defensible Statement of Applicability is therefore more useful than treating an nca compliance checklist as a universal yes-or-no list.

3. What Changed From ECC-1:2018?

Teams working from older ecc-1:2018 requirements need to check their mappings against ECC 2-2024 rather than carrying the old structure forward.

Current Version: ECC 2-2024 is the current published version of the Essential Cybersecurity Controls.
Current Structure: It contains four main domains, 28 subdomains, 108 main controls and 92 subcontrols.
Legacy Structure: ECC-1:2018 used a different structure that included Industrial Control Systems Cybersecurity as a fifth domain.
OT Treatment: Operational Technology now has dedicated NCA controls rather than remaining a main ECC domain.

This distinction matters because an old workbook can appear complete while still being mapped to superseded control references.

The Four ECC Domains Explained

ECC 2-2024 is organised around four connected cybersecurity domains. Governance defines how cybersecurity is directed, defence protects technology and information, resilience prepares the organisation for disruption, and third-party or cloud requirements extend protection beyond the internal boundary.

The four domains work as follows:

1. Cybersecurity Governance

Governance establishes the structure through which cybersecurity decisions are made, approved, reviewed and held accountable.

Cybersecurity Strategy: The organisation has an approved strategy supported by an implementation plan and periodic review.
Roles and Responsibilities: Cybersecurity ownership, reporting relationships and responsibilities are formally defined.
Risk Management: Cybersecurity risks are identified, assessed, treated and monitored through an approved methodology.
Policies and Procedures: Requirements are documented, approved and reviewed rather than existing as informal operating knowledge.
Compliance and Review: Periodic reviews and independent assessments provide evidence that governance continues to operate.

Cybersecurity governance is closely connected with enterprise decision rights and accountability. Where those responsibilities are unclear, IT governance advisory helps place cybersecurity controls within the wider governance structure.

2. Cybersecurity Defence

Cybersecurity defence contains the operational safeguards used to protect information and technology assets.

Asset Management: Inventories identify systems, devices, applications and other technology assets together with ownership and classification.
Identity and Access: Account creation, privileged access, authentication, access review and termination follow controlled processes.
Infrastructure Protection: Networks, endpoints, email, web systems, mobile devices and cryptographic services receive appropriate safeguards.
Vulnerability Management: Weaknesses are identified, prioritised, remediated and retested rather than simply reported.
Security Monitoring: Logging and monitoring provide visibility into events requiring investigation.
Incident Management: Defined procedures support identification, escalation, containment, recovery and lessons learned.

The practical question is not whether these capabilities exist somewhere in the environment. It is whether the organisation can connect each applicable control to consistent operational evidence.

3. Cybersecurity Resilience

Cybersecurity resilience connects cybersecurity incidents with the organisation's wider ability to continue essential services.

Business Dependency: Critical business processes are linked to the technology and information they depend on.
Cyber Scenarios: Continuity planning considers cyber incidents rather than focusing only on physical disruption.
Recovery Planning: Recovery procedures define how affected technology and information services can be restored.
Testing: Exercises and recovery tests provide evidence that plans work beyond the document itself.
Lessons Learned: Test and incident findings feed back into future resilience improvements.

A continuity plan that has never been exercised provides weaker assurance than a tested recovery process with documented remediation.

4. Third-Party and Cloud Computing Cybersecurity

The fourth domain extends cybersecurity responsibilities to services and technologies operated outside the entity's direct boundary.

Supplier Requirements: Relevant contracts include cybersecurity obligations appropriate to the service and risk.
Outsourcing Risk: Cybersecurity risk is considered before entering material outsourcing or managed-service arrangements.
Incident Communication: Third-party relationships define how security incidents are reported and escalated.
Cloud Controls: Entities using cloud or hosting services apply the relevant requirements to data protection and service architecture.
Periodic Review: Third-party controls remain subject to review as contracts, technologies and risks change.

Understanding the domains is only the first layer of nca ecc compliance. The next challenge is proving that the controls actually operate. Organisations that need an independent control-to-evidence review can explore IT security consulting in Saudi Arabia.

5. Where ICS and OT Security Fit Today

Industrial systems have not disappeared from Saudi cybersecurity obligations simply because ICS is no longer a fifth ECC domain.

Separate Control Set: NCA maintains Operational Technology Cybersecurity Controls for OT environments.
ECC Foundation: OT-specific controls complement rather than erase the wider governance and cybersecurity requirements.
Environment Separation: Organisations need a clear view of which IT, OT and shared services fall under which control sets.
Integrated Risk: Dependencies between business systems and industrial environments still need coordinated risk management.

This is one reason current regulatory mapping matters more than reusing a legacy ECC-1:2018 worksheet.

Evidence Auditors Ask for, Control by Control

ECC compliance is demonstrated through more than policies. NCA's current implementation guidance pairs controls with implementation guidance and expected deliverables, showing that evidence can include approved documents, operational records, technical outputs and proof of periodic activity.

A useful evidence model looks at four categories:

1. Governance Evidence

Governance controls are supported by records showing who approved decisions and whether required reviews actually occurred.

Strategy Records: Approved cybersecurity strategy, implementation plan, initiative status and review records.
Governance Structure: Organisation charts, committee terms, reporting lines and documented responsibilities.
Risk Evidence: Risk methodology, assessments, risk registers, treatment plans and monitoring records.
Policy Evidence: Approved policies, revision history and evidence of scheduled reviews.
Audit Evidence: Independent review reports, findings, remediation plans and closure records.

The practical audit question is often: can the organisation show the decision trail, not just the final document?

2. Technical and Operational Evidence

Cybersecurity defence requires evidence from the systems and processes that operate the controls.

Asset Records: Current inventories, asset owners and classification information.
Access Records: Joiner, mover and leaver records, privileged-access reviews and authentication settings.
Vulnerability Records: Scan results, remediation tickets, risk acceptance and retest evidence.
Monitoring Records: Logs, alerts, investigation tickets and monitoring procedures.
Incident Records: Incident reports, escalation evidence, response actions and post-incident reviews.
Testing Records: Penetration-testing plans, results and remediation follow-up.

Asset evidence becomes more useful when it reflects information sensitivity as well as technical ownership. A structured approach to that relationship is covered in data classification saudi arabia.

3. Resilience Evidence

Resilience controls need proof that recovery assumptions have been tested.

Continuity Plans: Cybersecurity scenarios are integrated into relevant continuity arrangements.
Recovery Procedures: Technical teams have documented steps for restoring affected systems and information.
Exercise Results: Tests record what was exercised, what failed and what needs improvement.
Recovery Timing: Results demonstrate whether recovery assumptions match real capability.
Remediation: Weaknesses identified during tests are assigned to owners and tracked.

This evidence separates a theoretical recovery capability from one the organisation has actually exercised.

4. Third-Party and Cloud Evidence

Supplier assurance requires more than a signed contract.

Due Diligence: Supplier security assessments show what was reviewed before onboarding.
Contract Clauses: Agreements document relevant cybersecurity and incident obligations.
Cloud Assessments: Cloud services are evaluated against applicable security and data requirements.
Review Records: Periodic supplier reviews show whether obligations remain satisfied.
Exit Evidence: Data return, access termination and secure transition arrangements are defined.

An effective evidence register therefore connects every applicable control with an owner, evidence source, review date, gap status and remediation action.

Cloud and Third-Party Control Obligations

Cloud and supplier arrangements change where technology is operated, but they do not remove the entity's cybersecurity responsibility. ECC 2-2024 therefore treats third-party and cloud risks as part of the organisation's own control environment.

Four areas deserve particular attention:

1. Cybersecurity Starts Before Contract Signature

Supplier risk is more difficult to correct after a contract is already signed.

Pre-Contract Assessment: Material providers are assessed before the organisation commits to the service.
Service Scope: The assessment considers systems, data, access and operational dependency.
Risk Ownership: Identified supplier risks have internal owners rather than being left entirely with procurement.
Security Requirements: Required controls are translated into contractual or service requirements.

This makes cybersecurity part of supplier selection rather than an approval step at the end.

2. Contracts Need Security Obligations

Commercial terms alone do not establish how a provider handles cybersecurity events or sensitive information.

Confidentiality: Agreements address protection of information shared with the supplier.
Incident Reporting: Responsibilities and communication routes are defined before an incident occurs.
Compliance Duties: Relevant security policies, controls and regulatory obligations are reflected in the relationship.
Access Control: Remote or privileged access receives appropriate restrictions and oversight.
Service Termination: Exit terms address access removal and handling of organisational data.

The stronger the dependency, the more important it becomes to make these obligations operational rather than generic legal wording.

3. Cloud Services Introduce Additional Applicability

ECC explicitly makes its cloud and hosting subdomain applicable to in-scope entities using or planning to use those services.

Data Classification: Cloud protection needs to reflect the sensitivity of the information being processed.
Tenant Separation: Shared environments require appropriate separation between customers and workloads.
Service Architecture: Responsibility between the entity and provider needs to be understood rather than assumed.
Data Return: Service termination includes arrangements for returning data in a usable form.
Additional Controls: NCA's Cloud Cybersecurity Controls extend the ECC with more detailed requirements for cloud providers and tenants.

The current cloud framework should therefore be checked alongside ECC instead of relying on assumptions carried over from earlier versions of the Saudi cybersecurity controls.

4. Supplier Assurance Continues After Onboarding

A provider that was acceptable two years ago may not represent the same risk today.

Periodic Reviews: Supplier security posture is reassessed at defined intervals.
Material Changes: Architecture, ownership, subcontracting or service changes can trigger further review.
Incident History: Security events can change the organisation's view of supplier risk.
Contract Renewal: Renewal provides another point to confirm whether requirements still reflect the service.
Exit Planning: Critical services need realistic transition arrangements before termination becomes urgent.

Third-party assurance works best as a lifecycle rather than a one-time questionnaire.

A Practical NCA ECC Gap Assessment Approach

A useful ECC gap assessment does more than mark controls compliant or non-compliant. It establishes scope, confirms applicability, tests evidence, identifies the reason behind each gap and turns findings into a prioritised remediation plan.

The assessment can be structured in four stages:

1. Establish the Current Regulatory Baseline

The assessment begins by confirming what framework and control sets apply today.

ECC Version: The baseline reflects ECC 2-2024 rather than outdated references.
Entity Scope: The organisation records why it falls within mandatory or voluntary scope.
Additional Controls: Cloud, OT, critical systems or sector-specific requirements are identified where relevant.
Technology Context: Systems, cloud platforms, suppliers and critical services are mapped before controls are assessed.

This prevents the team from measuring compliance against an incomplete regulatory picture.

2. Map Controls to Owners and Evidence

Every applicable requirement needs an accountable business or technical owner.

Control Owner: The person responsible for ensuring the requirement operates.
Evidence Owner: The team responsible for producing or retaining proof.
Evidence Source: Policies, configurations, logs, reports, approvals and operational records are identified.
Review Frequency: Periodic controls include the expected frequency of review.
Gap Status: Missing design, weak implementation and missing evidence are recorded separately.

A broader it governance framework can help organisations distinguish decision ownership from day-to-day technical operation.

3. Test Operation, Not Only Documentation

A control can exist on paper and still fail in practice.

Design Test: The requirement is correctly translated into policy, process or technical design.
Operating Test: Evidence shows that the control has actually been performed.
Period Test: Recurring activities are demonstrated over an appropriate period rather than through one recent example.
Exception Test: Deviations and risk acceptances are formally recorded and approved.
Closure Test: Remediation includes verification rather than stopping when a ticket is marked complete.

The result is a more useful picture than a binary compliance score.

4. Prioritise Remediation by Risk and Dependency

Not every finding should be treated with identical urgency.

Regulatory Impact: Gaps tied directly to mandatory requirements receive appropriate priority.
Cyber Risk: Exposure and potential business impact influence remediation order.
Dependency: Some foundational gaps affect several controls at once.
Remediation Effort: Quick fixes and structural changes need different planning.
Validation: Closure includes evidence that the improved control now operates.

A repeatable assessment method reduces the risk of treating every audit as a fresh document exercise. TrustAngle explains that type of staged decision and implementation process through our five-stage methodology.

Common NCA ECC Compliance Findings

Many ECC gaps are not caused by the absence of security technology. They appear where ownership, evidence, review cycles and regulatory mapping are incomplete.

Five findings are particularly common in practice:

1. The Organisation Is Still Using the Wrong Baseline

Legacy documentation can remain mapped to outdated control references long after a framework changes.

Old Numbering: Procedures still reference ECC-1:2018 controls.
Old Domain Structure: Teams continue reporting against five ECC domains.
Missing New Mapping: Updated controls have not been mapped to existing processes.
Evidence Misalignment: Evidence exists but is attached to superseded control references.

Version control is therefore a compliance issue, not an editorial detail.

2. Policies Exist Without Operating Evidence

A polished policy is only one form of evidence.

Access Reviews: Policy requires review, but no completed review records exist.
Risk Treatment: Risks are recorded without evidence of completed treatment.
Vulnerability Management: Findings are scanned but closure is not verified.
Continuity Testing: Recovery documentation exists without recent exercise results.
Supplier Review: Contract terms exist without recurring assurance.

The gap is often between "we require this" and "we can prove this happened."

3. Control Ownership Is Too Centralised in Cybersecurity

Cybersecurity functions often depend on other departments to operate controls.

Human Resources: Personnel lifecycle controls depend on HR processes.
Procurement: Third-party controls depend on supplier and contract management.
Infrastructure: Technical hardening and logging depend on system owners.
Business Continuity: Resilience requires operational involvement outside security.
Executive Management: Strategy and risk decisions require management authority.

A compliance programme becomes fragile when the security team is expected to own evidence for processes it does not control.

4. Cloud and Supplier Assurance Is Too Shallow

A questionnaire at onboarding rarely proves ongoing supplier compliance.

Generic Assessments: Reviews do not reflect the actual data or service risk.
Weak Contracts: Cybersecurity obligations are broad and difficult to enforce.
Remote Access: Third-party privileged access is not consistently monitored.
Cloud Responsibility: Teams assume the provider controls areas that remain the customer's responsibility.
Missing Exit Planning: Critical data and service transition are addressed only when termination begins.

These issues can span architecture, sourcing, governance and security at the same time.

5. Remediation Becomes an Audit Project

Some organisations collect evidence only when an assessment date approaches.

Evidence Gaps: Periodic records cannot always be recreated retrospectively.
Short-Term Fixes: Controls are adjusted for the audit without becoming routine practice.
Recurring Findings: The same weakness returns because the root cause remains.
Limited Ownership: Remediation deadlines exist without accountable decision-makers.

Where the organisation needs a neutral view across technology, governance and remediation options rather than a product-led answer, IT consulting services can support the decision stage before implementation begins.

What to Do Differently With the NCA Essential Cybersecurity Controls

The most effective way to manage the nca essential cybersecurity controls is as a continuous control and evidence system rather than a periodic documentation exercise. Compliance becomes easier to defend when every applicable requirement has a clear owner, operating process, evidence source and review cycle.

Three changes make the biggest practical difference:

1. Treat Evidence as Part of the Control

Evidence collection works better when it is created during normal operation.

Built-In Records: Access reviews, risk approvals and remediation actions generate records automatically or through defined workflows.
Evidence Ownership: Teams know who retains each type of evidence.
Review Dates: Periodic controls are monitored before evidence becomes stale.
Traceability: Findings can be followed from identification through remediation and validation.

This turns an NCA compliance checklist into an operating register rather than a document requested shortly before an audit.

2. Separate Cybersecurity Compliance From Adjacent Regulations

ECC overlaps with other Saudi regulatory obligations, but it does not replace them.

Cybersecurity Focus: ECC defines cybersecurity requirements for applicable entities.
Personal Data: PDPL addresses the lawful processing and protection of personal data through a separate regulatory framework.
Sector Requirements: Regulated sectors may face additional requirements beyond ECC.
Specialised Controls: Cloud, OT and other technology areas can bring additional NCA control sets.

Teams that need the wider data-protection context can review pdpl compliance saudi arabia.

Where the question moves from general understanding to how privacy obligations affect governance, architecture and operating processes, PDPL compliance advisory covers that adjacent obligation without treating PDPL and ECC as the same framework.

3. Prepare for Assessment Before the Assessment Starts

Audit readiness is easier when control validation is part of normal governance.

Current Mapping: Controls remain mapped to the latest regulatory baseline.
Evidence Reviews: Evidence quality is checked throughout the year.
Open Gaps: Remediation is visible before an external reviewer identifies the same issue.
Management Reporting: Decision-makers can see risk, compliance and overdue actions together.
Continuous Improvement: Findings improve the underlying process instead of creating temporary audit fixes.

The goal is not to produce more compliance documents. It is to make the organisation capable of showing, at any point, which controls apply, how they operate and what evidence supports that conclusion.

NCA Essential Cybersecurity Controls Compliance FAQs

What are the NCA Essential Cybersecurity Controls?

The NCA Essential Cybersecurity Controls are the National Cybersecurity Authority's baseline cybersecurity requirements for entities within their defined Saudi scope. ECC 2-2024 covers cybersecurity governance, defence, resilience, and third-party and cloud computing cybersecurity. It establishes minimum requirements while allowing individual control applicability to vary according to business activities and technologies.

Is ECC-1:2018 still the current version?

No. ECC-1:2018 is the previous version of the framework. ECC 2-2024 is the current version published by NCA. Organisations still using legacy assessment sheets or policies should remap their requirements and evidence to the current control structure rather than assuming the previous domain numbering and control references remain valid.

How many domains are in NCA ECC 2-2024?

ECC 2-2024 contains four main domains: Cybersecurity Governance, Cybersecurity Defence, Cybersecurity Resilience, and Third-Party and Cloud Computing Cybersecurity. The framework also contains 28 subdomains, 108 main controls and 92 subcontrols. Industrial Control Systems are no longer presented as a fifth ECC domain and are addressed through separate OT cybersecurity controls.

What evidence is needed for NCA ECC compliance?

The required evidence depends on the control. It can include approved policies, risk registers, asset inventories, access reviews, configuration records, vulnerability reports, incident records, audit findings, continuity tests and supplier agreements. The central question is whether the evidence proves that an applicable control is designed, operating and periodically reviewed.

Does every NCA ECC control apply to every organisation?

Not necessarily. Organisations within scope must comply with the controls applicable to their environment. Applicability can vary according to business activity and technology use. For example, ECC 2-2024 explicitly identifies cloud and hosting controls as applicable to entities currently using or planning to use those services.

How should an organisation perform an NCA ECC gap assessment?

A practical assessment starts by confirming scope and the current regulatory baseline, then maps applicable controls to accountable owners and evidence. Each control is tested for design and operation, gaps are classified by cause, and remediation is prioritised according to risk, regulatory significance and dependency before closure evidence is validated.

Is NCA ECC compliance the same as PDPL compliance?

No. ECC focuses on cybersecurity requirements, while Saudi PDPL governs personal-data processing and data-protection obligations. Some security measures may support both frameworks, but complying with ECC does not automatically demonstrate compliance with PDPL, and the two should be mapped and assessed as separate but related obligations.

NCA Essential Cybersecurity Controls: A Practical Compliance Guide