Every finding in the previous piece has the same root cause: a system was built, and compliance was asked of it afterwards. The access review is painful because identities live in six places. The restore test is missing because nobody designed for restore. The log is empty because logging was a setting someone forgot. The cheapest time to fix all of that is before the first server exists. This closing piece is about the architectural decisions that make evidence a by-product of operation rather than a quarterly chore.
Part eight, and the last, of The Compliance Architect. It assumes the control matrix and the evidence architecture from earlier in the series, and turns them into design constraints.
Why Retrofitting Costs What It Costs
A control retrofitted onto a running system has three costs the same control at design time does not. It has to be bolted on without breaking what works, which means exceptions, and exceptions are what auditors and attackers both look for. It has to be evidenced by someone going and looking, because the system was not built to report on itself. And it has to be maintained against a design that keeps drifting away from it, because the people changing the system do not think of the control as part of the system.
The alternative is not to design "for compliance". Compliance is a bad design goal; it changes with the regulation and it tempts you to build for the document rather than the risk. The alternative is to design for a small set of properties that every framework in this series turns out to require, and to let the evidence fall out of the design. There are nine of them.
1. One Identity, Everywhere
Every human and every workload authenticates against a single identity provider, with MFA enforced at the provider and roles assigned there, not in each application. Applications trust the provider; they do not keep their own user tables. Service accounts are owned, expire, and are rotated.
What this buys: the access review (ISO 5.18, NIS2 21(2)(i), DORA 9(4)(c)) becomes one export from one system. MFA coverage (NIS2 21(2)(j)) is a single policy, provably applied. Leaver deprovisioning is one action. The alternative, an identity per application, produces the six-list access review that nobody completes.
2. Segmentation as the Default Topology
Production, staging, development, corporate and management networks are separate, and traffic between them is denied unless allowed. Administrative access to production goes through a bastion or a privileged access service with session recording, never from a workstation directly. Cloud accounts or subscriptions are split by environment and by sensitivity.
What this buys: the blast radius of an incident is bounded, which is the substance of NIS2's "security of network and information systems" and DORA Article 9. The evidence is the firewall policy and the flow logs, both machine-generated. And the auditor's "walk me to the system" ends at a recorded session rather than at a shared root password.
3. Logging Is Not Optional and Not Local
Every system emits logs to a central platform from the day it is built, with the platform's own access controlled and its storage immutable for the retention period. Authentication events, privilege use, configuration changes, and administrative actions are mandatory log sources; application logs are added per system. Retention is a decision made once, per log class, and written down.
What this buys: ISO 8.15 and 8.16, NIS2 21(2)(b) and (e), DORA Article 10, GDPR 32(1)(d), and, crucially, the ability to answer the 24-hour and 72-hour reporting questions. An incident report that says "we do not know when it started" is the direct result of logging as an afterthought.
4. Backups That Are Tested Because Restore Is a Feature
Backups follow the boring rule (three copies, two media, one off-site) with one modern addition: at least one copy is immutable or logically air-gapped, so that ransomware with administrative credentials cannot delete it. Restore is a scripted, scheduled operation, not a manual emergency; the script restores a sample to an isolated environment monthly and records the result.
What this buys: ISO 8.13, NIS2 21(2)(c), DORA Articles 11 and 12, GDPR 32(1)(c). The restore test the auditor asks for exists because the system runs it, and the recovery objective is a measured number rather than an aspiration.
5. Encryption Everywhere, Keys Somewhere Specific
TLS for every connection including internal ones; encryption at rest for every data store; and keys held in a key management service with rotation, access logging and separation between the people who administer systems and the people who can use keys. Certificates are issued and renewed automatically.
What this buys: ISO 8.24, NIS2 21(2)(h), DORA 9(4)(d), GDPR 32(1)(a) and, under Article 34(3)(a), a defensible argument that a breach of encrypted data does not require notifying data subjects. Certificate expiry stops being a source of incidents.
6. Infrastructure as Code, Changes as Reviews
Infrastructure is defined in code, in a repository, and deployed by a pipeline. A change is a merge request with a reviewer, automated tests and a deployment record. Nobody changes production by hand; where they must, the emergency path is logged and reconciled back into code within days. Drift between the code and the running state is detected and alerted.
What this buys: ISO 8.9, 8.32 and clause 6.3, NIS2 21(2)(e), DORA 9(4)(e). Configuration baselines are the code. Change records are the merge history. The auditor's "show me three changes" is a link. And the compliance evidence for configuration management, which is nearly impossible to produce for hand-managed systems, is produced continuously.
7. Least Privilege, Just in Time
Standing administrative privilege does not exist. Administrators are ordinary users who request elevation for a task, for a bounded time, with approval where the risk warrants it, and every elevation is logged. Workloads get the narrowest role that lets them function. Secrets are injected at runtime from a vault, never stored in code or configuration files.
What this buys: ISO 8.2 and 8.5, NIS2 21(2)(i), DORA 9(4)(c). The privileged access review becomes a list of elevations with reasons. Credential theft gives an attacker an ordinary user, not a domain. And the secret-in-repository finding, which is in the top three of every penetration test I have read, cannot occur.
8. Data Classified, Minimised, and Expiring
Every data store carries a classification and a retention period, set when it is created. Personal data is tagged as such. Deletion is scheduled and automatic, not a project someone does when the DPA asks. Test and development environments use masked or synthetic data, never production copies.
What this buys: ISO 5.12, 5.13, 8.10 and 8.11, GDPR Articles 5(1)(e), 25 and 30. The records of processing are a query over the tags. The deletion evidence the 2022 auditors are asking for exists because deletion is a job with a log. And a breach in the development environment is a breach of synthetic data.
9. Suppliers and Exits Designed In
Every external dependency, cloud provider included, is recorded when it is introduced, with its data, its location, its criticality and its owner. For critical dependencies the exit is designed with the entry: data export formats, an estimate of migration effort, and, where the risk justifies it, a second provider or a portable deployment (containers, standard interfaces, no proprietary lock at the data layer). Dependency manifests and software bills of materials are generated by the build.
What this buys: ISO 5.19 to 5.23, NIS2 21(2)(d), DORA Articles 28 to 30 and the exit strategies the DORA piece described, and the CRA's expectations on component transparency. The register of information is populated from the dependency record rather than reconstructed from invoices.
The Patterns Together
Put the nine together and the resulting system has a property that no amount of policy can give a retrofitted one: it reports on itself. The identity provider knows who has access. The pipeline knows what changed. The log platform knows what happened. The backup system knows what can be recovered. The vault knows who used which key. The evidence store from the automation piece is not a new system that goes and asks; it is a set of exports from systems that already know. The control register from the matrix piece maps those exports to four frameworks, and the auditor from the previous piece finds an organisation that matches its documents because the documents were generated from the organisation.
What It Costs
I will not pretend this is free. Compared with an unstructured build, the nine patterns add design time up front (weeks, for a typical system), a small ongoing tax on every change (the review, the pipeline), and some infrastructure (a log platform, a vault, a bastion, immutable storage). In exchange they remove the retrofit project that every regulated organisation otherwise runs, usually more than once, and they remove most of the audit preparation effort permanently. Over a three-year certification cycle, in every case I have been able to compare, the compliance-first build was cheaper. Over the life of a system, it is not close.
They also, and this is the part I care about more, make the system safer. Every one of the nine patterns is a security control first and a compliance control second. An organisation that adopts them because the regulator asked will find that the regulator was, for once, asking for the right thing.
For Systems That Already Exist
Most readers are not building from nothing. The honest guidance for a running estate is to adopt the patterns in the order of their evidence value and their blast-radius value together, which in practice means: central identity with MFA first, then central logging, then immutable backups with scripted restore, then infrastructure as code for whatever is rebuilt next, then the rest as systems are touched. Do not retrofit all nine at once; that is the retrofit project this series exists to avoid. Set the rule that anything new follows all nine, and that anything touched adopts at least one more. The estate converges in two to three years, which is one certification cycle, and the audit gets easier each year of it.
Closing the Series
Eight pieces ago this series opened with the observation that three regulatory clocks ran out within a year, and that organisations could treat them as three projects or as one. The argument since has been cumulative: one control set with four mappings, one regulator's expectations mapped onto it, one supplier package, one evidence store, one auditor's method to prepare for, and finally one architecture that produces the evidence by operating. None of it is novel and all of it is rare, because it requires deciding, early, that security is a property of the system rather than a document about it.
The frameworks will keep changing. The CRA's reporting obligations are live this month, the AI Act's high-risk regime is arriving, the NIS2 amendments are working through the legislature, and there will be others. An organisation built on the nine patterns will map each of them onto the same register in an afternoon. An organisation built the other way will hire another consultant. That is the whole difference, and it is decided at design time.