There is a failure mode common to every regulated entity that has run a compliance programme for more than two years: the evidence function becomes the bottleneck. Controls exist, policies are approved, tooling is deployed, but the second line spends most of its time chasing screenshots, reconciling spreadsheets, and reformatting artefacts to match the current supervisor's preferred template. The continuous control monitoring pattern solves part of this, but only the part that is about detecting drift. The larger problem — producing defensible, timestamped, reviewer-friendly evidence on demand — is not solved by monitoring alone.
Control-as-code is the pattern that regulated entities are converging on in 2026. The idea is straightforward: treat the definition of a control, its test, and its evidence artefact as version-controlled configuration, executed and asserted by automation. The effect is less straightforward. It changes what the second line does, what the auditor asks, and what the supervisor examines.
This post covers the architecture, the governance implications, and the traps that derail early implementations.
What Control-as-Code Actually Means
The easiest way to describe the pattern is by contrast with the alternative. In a traditional evidence model, a control — say, "all production access is reviewed quarterly" — is defined in a policy document. An operational team performs the review quarterly, exports a spreadsheet, signs it, and files it in a document repository. At audit time, the auditor requests the spreadsheet, inspects it, asks follow-up questions, and assembles a working paper.
In a control-as-code model, the same control is defined in a versioned configuration file that specifies: the control identifier, the regulatory mappings (NIS2 Art. 21(2)(i), ISO 27001 A.5.18, DORA Art. 9), the automated test (a query against the IAM system that returns the list of accounts, their last review date, and the reviewer), the expected result (every account reviewed within the last 90 days), the failure handling (open a finding, notify the owner), and the evidence artefact (a timestamped, cryptographically signed record of the test execution with the full query result attached).
The configuration file is in version control. Changes to the control are pull requests with review and approval. The test runs on a schedule or on trigger. The evidence is the execution record, retrievable on demand.
The meaningful shift is not the automation — plenty of GRC platforms have automated tests — but the versioning and the artefact discipline. The state of the control at any point in history is reconstructable from the repository. The evidence is the machine-generated record with integrity properties, not a human-curated spreadsheet with a signature.
Why the Pattern Has Momentum Now
Three regulatory developments have pushed this from "nice to have" into the minimum viable architecture for large regulated entities.
Supervisory cadence. NIS2 competent authorities and DORA supervisors have both moved toward ongoing information requests rather than annual audits. An entity that can satisfy these requests by running a query against its evidence store has a fundamentally different cost structure than an entity that reassembles evidence manually each time.
Volume. NIS2 Article 21 defines ten categories of security measures, each with multiple implementing controls. DORA's ICT risk management framework and its testing programme multiply this further. ISO 27001:2022 retains Annex A with 93 controls. The superset of controls a large EU-regulated entity must evidence is comfortably over 400. Manual evidence at this volume is not merely expensive; it is unreliable, because the tails of the distribution (the controls that rarely get tested) drift out of compliance invisibly.
Evidence integrity expectations. Supervisors are asking increasingly pointed questions about the integrity of evidence. A screenshot dated two years after the fact, produced by the same team that performed the control, sits at the bottom of the evidence credibility hierarchy. A signed, timestamped machine record from an independent execution environment sits near the top. The gap between these two is what control-as-code closes.
The Reference Architecture
The implementations that are working in 2026 share a common shape, though they use different tools.
Control definitions in a repository. Each control is defined as a structured document (YAML, JSON, or a domain-specific language) with the identifier, scope, regulatory mappings, test logic, evidence specification, and ownership metadata. The repository is typically organised by control family rather than by framework — a single control can map to NIS2, DORA, ISO 27001, and SOC 2 simultaneously, and duplicating the definition per framework defeats the point.
Execution engine. A service that reads the definitions, executes the tests on schedule or on trigger, and records the results. The engine is often a set of composable probes — IAM queries, database integrity checks, cloud posture scans, vendor attestation retrievals — behind a common execution and recording interface. The quality of the engine is measured by the breadth of evidence sources it can reach with low-code integration.
Evidence store. Results are written to an append-only store with cryptographic integrity. The store is the single source of truth for "what was the state of this control at time T". Immutability matters because audit and supervisory requests can cover periods months or years in the past; the evidence must be reconstructable without trust in the current state of the source systems.
Finding and remediation workflow. Test failures open findings, which are routed to owners, tracked to remediation, and re-tested on resolution. The remediation state is itself evidence — a well-handled failure with tracked remediation is often more credible than a perpetually green control, because it demonstrates that the control detection is real.
Reporting and query surface. The surface the second line, the audit function, and the supervisor interact with. For an internal reviewer, this is a dashboard and a query tool. For a supervisor, it is often an exported package — the controls in scope for the request, their current state, and the evidence artefacts — generated by a repeatable query.
What Changes for the Second Line
The common anxiety when this pattern is proposed is that the second line becomes redundant. In every implementation I have seen in practice, the opposite happens: the second line becomes substantially more strategic, because the time spent on evidence curation shifts to time spent on control design, exception analysis, and supervisory dialogue.
The job changes shape in three ways:
From evidence collection to evidence quality assurance. Rather than gathering screenshots, the second line reviews the control definitions, questions whether a given test actually exercises the control or only a proxy for it, and validates the evidence store's integrity properties. The valuable work is upstream of the evidence, in the specification.
From periodic review to continuous exception handling. In a control-as-code environment, the "green" controls need much less attention — the evidence is self-producing. The attention focuses on the controls that are yellow or red, the failures, the exceptions, and the controls that are green but suspicious (a control that has never failed in two years often indicates a weak test, not a strong control).
From audit preparation to supervisory relationship. The capacity freed up by automation goes into the supervisory engagement — preparing thematic responses, anticipating the next regulatory information request, participating in industry and ENISA consultation processes. This is genuine compliance value, which the screenshot-chasing mode does not permit.
The Traps
Five implementation traps derail a large proportion of early programmes.
Over-automation of immature controls. A control that has only recently been deployed, or whose operational process is still shifting, should not be the first candidate for automation. Automating a still-moving target embeds the current friction into code and makes future redesigns more expensive. Automate the controls that are stable and high-volume first.
Under-investment in the control definition discipline. The value of the pattern is in the specification being precise, reviewable, and linked to the regulatory mapping. Teams that treat the definition as a thin wrapper around a script lose the auditability benefit. The definition is the artefact; the script is an implementation detail.
Evidence store without integrity properties. An evidence store that accepts writes without cryptographic integrity, or that can be edited after the fact, does not satisfy the evidence credibility criterion that justifies the programme in the first place. The integrity properties — append-only, hash-chained, signed — are not optional nice-to-haves; they are the point.
Treating control-as-code as a tooling decision. The pattern is as much organisational as technical. If the definitions are written only by a small automation team, and the first line and the second line do not review them, the definitions drift away from the reality of the control. The sustainable pattern has the definitions co-authored by the control owner, the second line, and the automation team, with explicit review responsibility on changes.
Ignoring regulatory mapping maintenance. Regulatory frameworks update. NIS2 implementing acts land. DORA RTSs are published. ISO 27001 revises. The mappings in the control definitions need maintenance. An unmaintained mapping is worse than no mapping, because it gives false confidence. Dedicate specific ownership for keeping the regulatory mappings current, tied to the regulatory horizon monitoring the second line should be doing anyway.
What to Build First
For an entity that has not yet started, the highest-leverage first scope is the control set that dominates supervisory requests: access reviews, change management, vulnerability management, backup testing, and vendor attestation. These five control families typically account for more than half of the evidence requests in a regulated environment, and they are all amenable to machine-generated evidence. Automating them generates measurable capacity release in the second line within the first quarter of the programme, which funds the expansion into the rest of the control inventory.
Control-as-code is not a silver bullet — the controls still need to be designed, the failures still need to be fixed, and the supervisory relationship still needs to be managed. What it does is remove the evidence assembly from the critical path, so that the programme's attention can go to the parts of compliance that actually determine whether the entity is resilient. In a regulatory regime where supervisors are increasingly assessing resilience, not documentation quality, that is where attention needs to be.