What NCA ECC-2 actually requires from your cloud — and what it doesn't

When a Saudi enterprise reads NCA’s Essential Cybersecurity Controls (ECC-2) for the first time, the response usually splits two ways. Some teams treat it as a paperwork exercise — write the policy, get the sign-off, file it. Others over-engineer it — buy a compliance suite, add an audit team, treat every control as a multi-quarter project. Both responses miss what the framework actually asks of cloud infrastructure, which sits squarely between the two.

This post is what we tell the engineering teams we work with about ECC-2 and the cloud, before the auditor shows up.

What ECC-2 actually asserts

ECC-2 is a controls framework. It does not prescribe a stack. It asserts what has to be true about your environment — for example, that access to information assets is logged and reviewed, that data is classified and handled per its classification, that change to production goes through a controlled process, that the environment is monitored continuously, that incidents have a defined response process. The framework leaves open how you implement those assertions, as long as the implementation is verifiable and auditable.

For cloud infrastructure, this matters more than it sounds. ECC-2 does not say “use a cloud-native SIEM” or “log to a specific platform.” It says the environment must be continuously monitored, that logs must be retained, that alerts must reach a human. A team that spends six months evaluating SIEM vendors before reading the framework has wasted six months. A team that treats this as box-ticking — “we have logs, here’s a screenshot” — will fail the first real audit.

What the framework actually requires from cloud — concretely

Translated into engineering, ECC-2 in a cloud environment requires (at minimum):

• Asset visibility. You need to know what is running, where, with whose credentials, since when. In a cloud environment this means a maintained inventory of compute, storage, identity, network, secrets, and SaaS — not a one-off spreadsheet.
• Identity and access controls. Privileged-access management, multi-factor authentication, role-based access at minimum, with periodic review. The framework cares less about your IAM tool than about whether you can prove who had what access on a date you have to report.
• Continuous monitoring. Logs from compute, identity, network, application; alerts that route to a human; retention long enough to support incident investigation and audit. The retention number is determined by your sector regulator, not by ECC-2 directly — read the framework that applies to your industry alongside.
• Change control. Production change has to go through a defined, evidenced process. Infrastructure-as-code with reviewed pull requests is the cleanest path; a manual approval workflow with attached evidence is acceptable.
• Incident response. A documented process, named responders, and the operational muscle to actually run it. The framework will ask whether you have tested the process — not just whether you have written it.
• Data classification and handling. Data has to be classified, handled per its classification, and disposed of properly. In a cloud environment this typically translates to encryption-at-rest with rotational key management, encryption-in-transit, and disposal procedures that are defensible.

What ECC-2 does not require:

• A specific cloud provider, a specific SIEM, a specific compliance suite.
• That every control be solved by automation. Manual controls with documented evidence are valid.
• That you ship in a single cycle. Mature implementations are phased; the auditor is interested in your direction of travel as much as your current state.

Where we see implementations go wrong

The recurring patterns we see when we are brought in to fix ECC-2 implementations:

• Logging without alerting. The team has audit-logging configured, retention is fine — but no alerts route to a human, and the logs are queried only when an incident has already escalated.
• Identity drift. Initial implementation is clean; six months later there are dormant service accounts with elevated privilege, MFA exemptions that nobody owns, and IAM policies that drifted past their review.
• Evidence at the wrong layer. Screenshots in a shared folder rather than evidence emitted by the system. The first is a maintenance burden; the second is the design.
• One-cloud bias. Implementations that work on one hyperscaler and break the moment a workload moves to another, or to a regional Saudi provider — which most ECC-2 buyers will eventually need to use.

What we engineer for ECC-2 environments

Our approach is the opposite of paperwork-led compliance. We engineer compliance evidence as a deterministic output of the infrastructure — agentless ingestion of cloud telemetry, deterministic rule evaluation against the relevant ECC-2 controls and its sister frameworks (NCA CCC-2 and DCC-1, PDPL, ISO 27001, NIST CSF 2.0), and cryptographic attestation attached to every check. The artifact the auditor receives is not a screenshot or a quarterly report; it is a continuously verifiable claim. The engine runs self-hosted, air-gap-capable, with the client controlling encryption keys and data paths — because for the buyers ECC-2 is written for, sending evidence to a third-party SaaS is not on the table.

Read the Cloud-Compliance Automation capability brief for the engineering depth, or start a project if you have an ECC-2 program that needs the engineering layer behind it.