Automating NCA ECC compliance: what can and cannot be automated

Most of the effort in an ECC programme is not deciding what to do — it is collecting, organising and re-collecting evidence that controls operated. That is the part worth automating, and it is where a regional programme differs from a SOC 2 one in ways generic tooling handles badly.

What automates well

• Evidence collection from connected systems. Access reviews, MFA coverage, patch status, backup success and logging configuration can be pulled directly rather than screenshotted quarterly.
• Control-to-requirement mapping. One access review satisfying ECC, ISO 27001 and a customer questionnaire simultaneously — provided the mapping exists and the evidence is stored once.
• Recurring activity scheduling with owners and chasing, which is what prevents the year-two decay that kills programmes.
• Gap reassessment. Re-scoring after remediation is mechanical if evidence is already linked to controls.
• Reporting in the format the authority expects, generated rather than assembled.

What does not automate

• Scope and classification. Whether a system is in scope, and how data is classified, is a judgement with regulatory consequences.
• Risk acceptance. A named business owner accepts residual risk. No tool does that.
• Interpretation. Where a control's intent is ambiguous for your environment, someone has to decide and document the reasoning.
• Compensating controls where a requirement cannot be met as written.
• The relationship with the assessor.

A useful test when evaluating tooling: ask what it does on the day a control fails. Anything can display green. The value is in surfacing the failure, routing it to an owner, and evidencing the correction.

Where generic platforms struggle with the ECC

Tooling built primarily for SOC 2 and ISO 27001 tends to assume a few things that do not hold here:

• Implementation scoring only. The ECC asks whether a control is implemented; if you are also subject to SAMA, you need maturity scoring from the same evidence. Tools that model only one struggle to produce both.
• English-only evidence and reporting. Arabic documentation is frequently expected in dealings with government entities, and retrofitting translation is slow.
• No concept of data residency in the control model, despite it being a live constraint on architecture.
• Framework libraries that simply do not include the ECC, the cloud controls, NCNICC or SAMA — which means the mapping work falls back to you in a spreadsheet.

A sensible sequence

1. Establish scope and classification manually — this drives everything and cannot be delegated to software.
2. Build one control set mapped to the ECC and to whatever else binds you.
3. Connect the systems that produce evidence, starting with identity, because it feeds the most controls.
4. Schedule the recurring activities with named owners.
5. Automate reporting last, once the underlying data is trustworthy.

Automating reporting on top of incomplete evidence produces confident dashboards that are wrong, which is worse than a spreadsheet you distrust appropriately.

Key takeaways

• Evidence collection and mapping automate; scope, judgement and acceptance do not.
• Ask what a tool does when a control fails, not what its dashboard shows.
• Implementation and maturity scoring from one evidence base is a regional requirement.
• Automate reporting last, after the evidence is trustworthy.