A cloud provider serving Saudi government clients, holding ISO/IEC 27001 certification and issuing SOC 2 reports to international customers runs three compliance programmes. Look closely, though, and most of the controls are the same: access reviews, vulnerability management, change control, backups, training, incident handling and supplier oversight. Continuous compliance is the practice of running those controls once, collecting dated evidence as they operate, and mapping that evidence to every framework it satisfies. Done well, it removes duplicated effort and gives a truer picture of control health. Done badly, it produces evidence that one auditor accepts and another rejects. This article explains the difference.
Why evidence collection costs so much
A March 2025 survey of 500 US and UK organisations with more than 1,000 staff, commissioned by an automation vendor, found that 92% used three or more tools to gather audit evidence, only 39% of the evidence process was automated on average, and 54% of respondents spent more than five hours a week on manual compliance tasks. Vendor surveys should be read with care, but the pattern matches what most compliance teams describe: the work is not the control, it is proving the control ran.
When each framework has its own evidence request list, the same screenshot, export or ticket gets produced several times, in slightly different forms, by different people, at different dates. That is where both cost and inconsistency come from.
How the three frameworks differ
| NCA ECC-2:2024 | ISO/IEC 27001:2022 | SOC 2 | |
|---|---|---|---|
| Structure | 4 main domains, 28 subdomains, 108 main controls and 92 subcontrols | Clauses 4 to 10 plus 93 Annex A controls in four themes | 2017 Trust Services Criteria with revised points of focus (2022) |
| Who it applies to | Government entities and their companies, and private operators of critical national infrastructure | Any organisation seeking certification | Service organisations reporting to customers |
| How compliance is checked | Self-assessment, periodic reports through the NCA's assessment and compliance tool, and field audits | Certification audit, then annual surveillance and recertification every three years | Independent CPA examination; Type II covers operating effectiveness over a period, commonly 12 months |
| What the assessor looks for | Ongoing, continuous compliance with each control | Controls tied to the risk treatment plan and Statement of Applicability, and working as designed | A dated population of evidence showing the control operated throughout the period |
The overlap is large, but it is not complete, and no official crosswalk from the NCA ECC to ISO/IEC 27001 has been published that we are aware of. Vendors often quote high overlap figures between SOC 2 and ISO/IEC 27001; the AICPA itself publishes mappings of the Trust Services Criteria to NIST SP 800-53 and the CSA Cloud Controls Matrix. Build your own mapping at the level of control objectives, and keep it under review. See the NCA ECC, ISO/IEC 27001 and SOC 2 framework pages.
What evidence captured once looks like
| Evidence artefact | NCA ECC area | ISO/IEC 27001 Annex A | SOC 2 criteria |
|---|---|---|---|
| Quarterly privileged access review, signed off | Identity and access management | 5.15, 5.18, 8.2 | CC6.1 to CC6.3 |
| Vulnerability scan results and remediation tickets | Vulnerabilities management | 8.8 | CC7.1 |
| Approved change tickets with testing records | Cybersecurity in change management | 8.32 | CC8.1 |
| Backup restore test report | Backup and recovery management | 8.13 | A1.2, A1.3 |
| Awareness training completion and phishing results | Cybersecurity awareness and training | 6.3 | CC1.4, CC2.2 |
| Incident records with root cause and lessons learned | Cybersecurity incident and threat management | 5.24 to 5.27 | CC7.3 to CC7.5 |
| Supplier security assessment | Third-party cybersecurity | 5.19 to 5.22 | CC9.2 |
The mapping column is the easy part. What makes the evidence reusable is the artefact itself: it must show who did what, to which population, on which date, and what happened to the exceptions.
Four traps that make auditors reject reused evidence
- Gaps in the population. A SOC 2 Type II auditor samples from every instance of a control during the period. A missing quarterly review, or a week with no vulnerability scan, is an exception, even if the evidence for the other three quarters is perfect.
- Retention shorter than the audit period. If logs or tickets are kept for 90 days and the report covers 12 months, the first nine months cannot be evidenced. Set retention to cover the longest audit period you face.
- Policy instead of operation. A documented procedure proves design, not operation. In ASIC's case against FIIG Securities, decided in February 2026, the firm admitted that following its own policies could have enabled earlier detection. Evidence must show the control running.
- Missing context. An ISO auditor expects the control to trace back to a risk and the Statement of Applicability; a Saudi assessor expects the ECC control reference; a SOC 2 auditor expects the criteria. The same artefact needs the right label for each reader.
Designing controls to be continuous
Continuous compliance is less about tooling than about control design. For each shared control, decide:
- frequency: how often it runs, set to the strictest framework that relies on it;
- owner: the person who performs it and the person who reviews it;
- artefact: exactly what is produced, in what format, and where it is stored;
- automation: which parts can be collected directly from source systems rather than by screenshot;
- exceptions: how failures are logged, remediated and evidenced, because auditors look hardest at those.
Controls designed this way produce evidence as a by-product of operation. That also makes them measurable, which is what boards increasingly ask for; our advisory colleagues set out the indicators in 12 cyber KRIs to report every quarter.
Running it in GRCLens
GRCLens runs NCA ECC-2:2024, ISO/IEC 27001:2022, SOC 2 and more than fifty other frameworks on one shared control model. Each control has dated evidence slots, so a restore test or access review is attached once and counts towards every framework mapped to it, with the period it covers visible to the auditor. Evidence is reviewed for relevance by an AI model hosted inside your own infrastructure, the Statement of Applicability is generated from the same records, and SOC 2 system descriptions and management assertions are maintained alongside the controls. Where the NCA or a regulator requires it, GRCLens runs fully on-premises in the Kingdom or in your own cloud.
Frequently asked questions
What is continuous compliance?
Running controls on a defined schedule, collecting dated evidence as they operate, and mapping that evidence to every framework that relies on the control, instead of gathering evidence separately before each audit.
Can the same evidence satisfy NCA ECC, ISO 27001 and SOC 2?
Often yes, if the artefact is dated, covers the full population and period, and is labelled with the right control reference for each framework. Some ECC requirements have no direct ISO or SOC 2 equivalent and need their own evidence.
How long is a SOC 2 Type II observation period?
The AICPA sets no fixed minimum. Around three months is a practical floor, and most reports cover twelve months.
Is there an official NCA ECC to ISO 27001 mapping?
We are not aware of one published by the NCA or ISO. Organisations build their own mapping at the level of control objectives.
How Security Solution Consultants can help
Security Solution Consultants designs shared control sets and evidence models for organisations that answer to the Saudi NCA, ISO certification bodies and SOC 2 customers at the same time, and prepares them for each assessment. See our SOC 2, NIST and security compliance advisory and ISO 27001 implementation services. GRCLens then keeps the evidence current between audits, so each assessment starts from records that already exist. Request a demonstration.
Keep reading
Autonomous Fleets Meet Critical Infrastructure Law: SOCI, New Zealand and the Gulf
Once an autonomous fleet moves freight or carries the public at scale, its operator starts to look like a critical infrastructure operator. What the SOCI Act, New Zealand's proposed regime and the Gulf rules ask for, and how to evidence it.
Running Post-Quantum Readiness as a GRC Programme: Inventory, KRIs and Regulator Dates
Post-quantum migration fails the same way most multi-year security programmes fail: an inventory nobody maintains, risks nobody scores, and dates nobody tracks. How to run it as a governed programme instead.
Governing AI Agents Under ISO/IEC 42001: Registers, Impact Assessments and Evidence
ISO/IEC 42001 was published before most organisations ran AI agents, but its structure fits them well. How to extend an AI management system to agents: the register, the impact assessment trigger, the life cycle controls and the evidence.