NCA ECC Gap Assessment in Saudi Arabia - Evidence and Remediation

Can we demonstrate that we meet the NCA Essential Cybersecurity Controls that apply to us?

The difficulty is often not the absence of security. It is the distance between deployed security measures and demonstrable control compliance.

A policy may require quarterly access reviews, but where are the completed reviews? A security information and event management (SIEM) platform may collect logs, but does its coverage match the systems that need monitoring? Backups may run every night, but can the organization demonstrate that recovery works? A cloud service may be technically well configured, but have the applicable cybersecurity requirements been documented, approved, implemented, and reviewed?

An NCA ECC gap assessment should answer these questions systematically. It should establish what applies, collect evidence of what is actually happening, validate technical implementation, identify gaps, and convert the findings into a remediation program that management can execute.

There is an important step before all of that: determine whether the organization is actually within the scope of ECC 2-2024.

The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC 2-2024) are minimum cybersecurity requirements designed to protect information and technology assets against internal and external cyber threats.

Applicability should not be inferred simply because an organization operates in Saudi Arabia.

The NCA strongly encourages other entities in Saudi Arabia to use the controls as cybersecurity best practices, but that should not be confused with mandatory ECC applicability.

That distinction matters for a private company approaching an NCA ECC gap assessment in Saudi Arabia. The project should not begin by assuming every ECC control is a mandatory requirement for every Saudi business.

Organizations should first document why ECC applies to them and then determine which controls are applicable to their particular environment.

Even after establishing that the organization falls within ECC scope, control-level applicability needs attention.

ECC 2-2024 states, for example, that the controls under subdomain 4-2, Cloud Computing and Hosting Cybersecurity, are applicable and binding on in-scope entities that currently use or plan to use cloud computing and hosting services.

Resolve both before assessing compliance. Otherwise, an organization can spend considerable time assessing an incorrect control set.

Saudi private-sector organizations that are not within ECC's CNI-related scope should also avoid automatically treating ECC as their mandatory framework. The NCA has published a separate framework, NCNICC-1:2025, for non-CNI private-sector entities. The Cyberactics NCNICC implementation guide explains that distinction in more detail.

Once applicability is established, the next question is deceptively simple: What exactly are we assessing?

The answer cannot be "IT."

An evidence-based ECC assessment needs a sufficiently detailed picture of the organization to determine where each control is implemented and who can prove it.

That may encompass business entities and functions, data centers and offices, cloud environments, networks, identity platforms, employee endpoints, servers, applications, email systems, backup infrastructure, security platforms, suppliers, hosting providers, and operational processes.

The assessment also needs named stakeholders. Cybersecurity might own monitoring, but HR may own elements of employee lifecycle processes. Procurement and legal teams may hold supplier agreements. Infrastructure teams may operate backups. Application owners may manage web application security. Business continuity responsibilities may sit outside IT altogether.

This is one reason an NCA cybersecurity gap assessment is more than a vulnerability scan or technical security review.

A vulnerability assessment can reveal exploitable weaknesses. An ECC assessment has to ask the broader question of whether required governance, technical, operational, resilience, and third-party controls have been implemented and can be demonstrated.

Organizations preparing for that wider review may also find the Saudi cybersecurity assessment checklist useful for initial evidence gathering and security readiness.

A weak assessment starts with dozens of meetings and asks stakeholders, "Do you comply with this control?"

A stronger assessment starts by examining evidence.

The NCA's current Guide to Essential Cybersecurity Controls Implementation (GECC-2:2026) is particularly useful here. It supplements ECC 2-2024 with implementation guidance and expected deliverables for individual requirements. The NCA also cautions entities not to rely solely on the implementation guide and states that an assessor or auditor may request additional evidence where necessary.

This reinforces an important assessment principle: evidence requirements should be connected to the underlying ECC requirement, not reduced to a generic checklist.

The initial evidence request will vary according to applicability, but it may include cybersecurity strategies and policies, organization and responsibility structures, risk registers, asset inventories, access-control records, architecture diagrams, vulnerability and penetration-test results, backup records, incident procedures, supplier agreements, awareness records, monitoring documentation, and configuration evidence.

The assessment team can then use interviews to explain and test the material rather than spending meeting time discovering where documentation might exist.

A useful ECC 2-2024 gap assessment brings three forms of investigation together: documentary review, stakeholder interviews, and technical validation. Each answers a different question.

Policies, procedures, standards, contracts, risk assessments, inventories, and governance records establish the organization's intended operating model.

Suppose a policy requires privileged access to be formally approved and periodically reviewed. That is relevant evidence, but it primarily demonstrates that the organization has defined a requirement.

It does not prove that every privileged account follows it.

The assessor can then speak to the people who administer identities and ask how privileged accounts are requested, approved, provisioned, reviewed, modified, and removed.

Interviews frequently expose differences between written procedures and operational reality.

That does not automatically mean the control has failed. It means the discrepancy needs to be understood and tested.

The final layer is implementation evidence.

For identity controls, that could include authentication settings, account samples, privileged-role assignments, access-review records, and configuration exports.

For vulnerability management, it could include scan coverage and results, remediation tickets, exception handling, and evidence that identified vulnerabilities have been addressed according to the organization's approved process.

For monitoring, it might include log sources, retention configurations, alert rules, actual alerts and incident records, and evidence that monitoring activities are operating as intended.

The exact tests depend on the relevant ECC requirement and the environment under review. The result is more reliable than assigning a compliance status based on a policy document or a verbal "yes."

This distinction is central to a useful NCA ECC compliance assessment.

Imagine that an organization's cybersecurity policy says multifactor authentication (MFA) is required for privileged accounts and remote access.

ECC 2-2024 addresses MFA for remote access and privileged accounts in subcontrol 2.2.3.2, with suitable authentication factors, their number, and authentication techniques determined based on the impact assessment of authentication failure and bypass.

A policy may support that requirement, but technical validation should ask whether the relevant systems enforce the intended configuration in practice.

In a Microsoft environment, for example, evidence might require examining Entra ID authentication and access configurations rather than simply accepting a statement that "Microsoft 365 has MFA."

Policies describe expected behavior. Operational and technical evidence demonstrate implementation. An ECC assessment needs both.

Eventually, hundreds of individual observations must become something management can use. This is where assessment quality becomes visible.

A report containing rows of "compliant," "partially compliant," and "non-compliant" controls may communicate assessment status, but it does not automatically create an implementation plan.

Evidence gaps should also be distinguished from implementation gaps.

For example, a team may say it performs periodic reviews but be unable to produce records. That is not necessarily identical to confirming that the reviews never occur. The gap register should state what was actually established: sufficient evidence was not available to demonstrate implementation.

That precision helps teams fix the actual problem rather than react to an overly broad finding.

The remediation plan should not simply start at ECC control 1-1-1 and work downward. Controls have dependencies.

Consider asset management. If an organization does not have reliable visibility of its technology assets, teams can struggle to demonstrate comprehensive vulnerability scanning, endpoint protection, patching, monitoring, backup coverage, or access governance.

Identity creates similar dependencies. Poor account lifecycle management can undermine privileged-access controls, remote access, application security, and incident investigation.

Logging is another example. Building sophisticated SIEM detection rules has limited value if critical identity, endpoint, network, server, cloud, and application sources are not providing the logs needed for those detections.

That approach prevents a common compliance failure: completing the easiest paperwork first while high-impact technical weaknesses remain open.

The gap register describes the problems. The roadmap coordinates their resolution.

Some gaps may take days to address. Others can become multi-month projects involving procurement, architecture changes, configuration, testing, training, contracts, or new operational processes.

A practical roadmap typically separates work into connected streams.

This stream can cover strategy, policies, roles and responsibilities, cybersecurity risk management, regulatory compliance, periodic reviews, human resources security, and awareness.

Its purpose is not to manufacture paperwork. It is to establish accountability and repeatable decision-making.

Technical remediation may involve identity and access management, endpoint security, network security, email protection, cryptography, data protection, mobile devices, application security, or hardening.

Remediation should be tied to verified findings. New tools should not be treated as the default answer when existing platforms can provide the required capability through better configuration or operational use.

Security operations often require more than deploying products.

The ECC includes requirements relating to vulnerability management, penetration testing, cybersecurity event logs and monitoring, and cybersecurity incident and threat management.

Closing gaps here may therefore involve improving scan coverage, remediation workflows, logging architecture, SIEM use cases, threat monitoring, escalation procedures, incident playbooks, or ongoing security operations.

ECC has a dedicated cybersecurity resilience component covering cybersecurity aspects of business continuity management, including continuity of cybersecurity systems and procedures, incident-response plans affecting business continuity, and disaster recovery plans.

Assessment findings should connect security incidents to the organization's ability to keep critical services operating and recover them when disruption occurs. Backups matter, but restoration capability, responsibilities, dependencies, and continuity arrangements are part of the larger resilience question.

Third parties deserve explicit ownership.

ECC 2-2024 includes requirements addressing third-party cybersecurity and cloud computing and hosting. The assessment may consequently need input from cybersecurity, IT, procurement, legal, vendor managers, and business owners.

The controls can also have direct operational implications for service-provider decisions. For example, ECC 2-2024 subcontrol 4.1.3.2 requires cybersecurity managed service centers for monitoring and operations that use remote access to be fully located in Saudi Arabia.

That is the kind of requirement that should be identified during architecture and supplier review, not discovered after a service contract has already been signed.

Evidence collection should not be postponed until the end of the implementation program. When a control is remediated, collect its evidence then.

If access reviews are introduced, retain approved review records. If new monitoring is deployed, document data sources and demonstrate the resulting operation. If backup processes change, preserve test results. If supplier requirements are updated, retain approved contracts and related assessment records.

This turns evidence into a by-product of normal security operations rather than an emergency documentation exercise before an assessment.

It is also consistent with the regulatory model. ECC 2-2024 requires in-scope entities to take necessary measures to maintain ongoing and continuous compliance. The NCA states that it may evaluate ECC compliance through methods including entity self-assessment, periodic compliance-tool reports, and field auditing visits.

The operating model therefore needs to survive after the initial remediation project.

Cybersecurity environments continually change. People join and leave. Privileges change. Cloud workloads appear. New suppliers receive access. Vulnerabilities emerge. Applications are replaced. Logging pipelines fail.

A compliant configuration today cannot simply be assumed to remain compliant next year.

Organizations performing an assessment in 2026 should be careful about document versions.

ECC itself remains ECC 2-2024, and the NCA has subsequently published the Guide to Essential Cybersecurity Controls Implementation (GECC-2:2026) to help entities implement its requirements.

That distinction matters.

The ECC is the control baseline against which the assessment is structured. The implementation guide helps teams understand ways to implement requirements and the kinds of deliverables that may support them. As the NCA itself notes, entities should not rely solely on the guide to implement ECC.

A sound assessment therefore works from the current authoritative NCA publications rather than relying on an old assessment spreadsheet or third-party interpretation.

ECC is a Saudi cybersecurity framework, not a GCC-wide compliance standard. However, its operational impact can cross borders.

A Saudi entity may share Microsoft 365, Entra ID, cloud platforms, networks, applications, suppliers, and security operations with a parent company or sister organizations in the UAE or Oman. A security control can therefore be technically operated at group level even though its regulatory relevance arises in Saudi Arabia.

This creates an important architecture and governance question for GCC groups: Which controls can use a common regional baseline, and which Saudi-specific requirements demand a different design or operating model?

The answer should be established requirement by requirement. For example, shared identity standards or vulnerability-management processes may provide useful foundations across several countries, while an explicit Saudi ECC requirement may require country-specific implementation decisions.

This distinction is particularly useful for MENA organizations with centralized technology or security functions. A regional operating model can reduce duplicated work, but the Saudi entity's ECC scope, evidence, and applicable requirements still need to be established and demonstrated on their own terms.

ISO/IEC 27001 can also provide useful governance foundations, but it is not a substitute for assessing ECC requirements. ISO/IEC 27001 is a risk-based information security management system standard, whereas ECC establishes Saudi national cybersecurity controls for organizations within its scope.

Organizations managing both can use Cyberactics' GCC ISO 27001 and compliance guide to understand the wider governance and gap-analysis approach while maintaining a separate mapping to applicable Saudi requirements.

Choosing an assessment provider should be based on the quality of its assessment method, not merely its ability to reproduce the ECC control list.

Ask prospective providers how they will establish ECC applicability before starting detailed testing. They should be able to explain how organizational scope, technology-dependent controls, and related NCA requirements will be handled.

Then examine their evidence method. Will they rely mainly on interviews and documentation, or will technical controls be validated against configurations and operational records where appropriate?

Ask how findings will be written and prioritized. A useful engagement should distinguish insufficient evidence from confirmed implementation failures and identify the remediation needed, dependencies, ownership, and retesting criteria.

It is also worth asking how the provider approaches control mapping. Organizations with ISO 27001, existing security standards, or other regulatory requirements may already have relevant controls and evidence. Reusing valid work can reduce duplication, provided that mapping is based on the actual ECC requirement rather than an assumption that one framework automatically satisfies another.

Finally, determine what happens after the report. An organization that receives 100 findings but no practical prioritization still has most of the difficult work ahead of it.

The goal of an NCA ECC gap assessment in Saudi Arabia should not be a larger collection of documents. It should give management a defensible picture of where the organization stands and a practical route forward.

Done well, this process supports more than assessment readiness. It can expose blind spots in identity, vulnerability management, security monitoring, recovery, cloud, and supplier governance that affect operational resilience whether or not an audit is approaching.

Cyberactics can support organizations with cybersecurity assessments and relevant remediation work across areas such as identity and access management, vulnerability management, Microsoft security, SIEM and monitoring, cloud security, incident response, and managed cybersecurity. The Cyberactics compliance and risk services provide a starting point for organizations that need to turn ECC findings into practical implementation work.

The most useful first question remains the simplest: Does ECC 2-2024 apply to us, and can we prove that the controls that apply are actually operating?