Enterprise Architecture Compliance: Making Governance Provable, Not Just Documented

Enterprise architecture compliance is the practice of establishing that systems, projects and infrastructure conform to the architecture the organization committed to, and to the standards and regulations that apply to it. It is usually run as a review: a board, a checklist, a signature.

The interesting question is no longer how often that review should happen. Ongoing review is already part of established governance frameworks. What has not settled is what the review runs against, because a continuous check against a hand-maintained picture of the estate is only as good as the picture, and nobody audits the picture.

This piece covers where the review model came from, what current regulation requires, and the structural gap that makes architecture compliance harder than compliance in general.

What Enterprise Architecture Compliance Covers

Three things, usually in the same review. Conformance to internal standards, meaning the patterns, platforms and boundaries the organization has agreed to. Conformance to the intended architecture, meaning what was designed is what got built. And conformance to external obligation, meaning whatever regulation, certification or contractual commitment applies.

All three rest on the same substrate: a description of the estate. NIST’s glossary defines enterprise architecture as a strategic information asset base that defines the mission and the information and technologies necessary to perform it, which is exactly the artifact a compliance review reaches for and rarely questions.

The third kind of conformance is the one that has changed most. It is also worth separating from AI-specific compliance, which is a distinct problem with its own frameworks. If you are working through the EU AI Act, NIST AI RMF or ISO/IEC 42001, our guide to AI compliance for architecture governance covers that ground. This piece is about the whole estate, and about a problem that exists whether or not AI is anywhere in it.

The Review Model We Inherited

The architecture compliance review most organizations run has the same shape everywhere: a board, a project brought before it at a milestone, a checklist, and a decision recorded against agreed architectural criteria. That shape came out of the enterprise architecture frameworks that formalised the practice, and we would defend the reasoning behind it.

The Open Group’s TOGAF is the standard most teams mean by “the standard process,” and it carries more governance machinery than the modern critique credits. TOGAF and ArchiMate are built to work together, so a line can run from drivers and goals through capabilities and architecture to the work packages that implement them. TOGAF’s governance phase exists to hold implementation to the architecture that was agreed.

So the criticism worth making is not that the frameworks cannot express traceability. It is that the review as commonly operated is a manual, snapshot activity. A project is assessed against a description of the target state, and both the description and the assessment start ageing immediately, because nothing re-derives either one between milestones. That was a reasonable design when the estate changed at the pace of a project plan.

Why Point-in-Time Documentation Breaks Down in 2026

The mechanism is not mysterious, and it does not require a claim about industry trends to explain.

A point-in-time architecture description is accurate for as long as the estate stays still. Every deploy, every managed-service swap, every new queue between two services moves the estate and does not move the document. The document is only corrected when a person notices the divergence and does the work, which means the error is not detected by the process that created it. We have written about the general form of this failure as configuration drift: the gap opens quietly, and its size is unknown until somebody goes looking.

What has changed is the rate at which change gets produced relative to the rate at which humans document it. Infrastructure as code, managed services and now AI-assisted development all shorten the distance between deciding to change something and having changed it. None of them shortens the distance between changing something and updating the diagram, because that step is still a person remembering. So the same documentation practice now covers a smaller fraction of the change it describes. That is why we treat an architecture diagram as an output rather than a source of truth.

That is the part the frequency argument does not fix. Reviewing a stale picture more often produces stale conclusions more often.

Continuous Against What?

Continuous compliance requires something to be continuously compliant against, and that artifact is usually the only unaudited thing in the audit. We have argued before that a compliance program needs an accurate, current model of the architecture the requirements actually apply to. Current regulation makes the gap unusually visible.

For financial entities within its scope, the EU’s Digital Operational Resilience Act (DORA) distinguishes several duties. Article 8(2) requires continuous identification of ICT risk and risk-scenario reviews at least yearly. Article 9(1) requires continuous monitoring and control of ICT systems’ security and functioning.

Article 8(4) requires entities to identify information and ICT assets, map those considered critical, and map asset configurations and interdependencies. Those are essential inputs to an architecture model.

Article 8(6) requires relevant inventories for paragraphs 1, 4 and 5 to be updated periodically and after major changes covered by paragraph 3.

These duties have different scopes. Risk identification, asset mapping and inventory maintenance are related work, but they are not interchangeable.

In practice, the evidence beneath ongoing risk management must remain useful as systems change. An outdated map can hide a dependency even when individual controls are operating as designed.

Deriving inventory data from connected systems can reduce the manual maintenance burden, while teams remain responsible for coverage and validation.

Documented, Attested, or Provable

The obvious comparison here is point-in-time versus continuously provable, but that framing puts the weight on frequency, which the section above already conceded. The table below sorts by what kind of claim your evidence supports instead. Frequency then falls out of it, because only the third column can be checked on demand.

Plenty of organizations sit in the middle column and believe they are in the third. Attestation feels like proof because it carries accountability, but accountability for a claim is not evidence for it. The signer asserts that a document matched reality on a given day, usually without a mechanism to check.

The third column differs in one specific way, and it is worth being precise rather than grand about it. A derived model relocates the error rather than removing it. Instead of failing silently through decay, it fails through coverage, because whatever you have not connected is absent from the picture. That is a real limitation and a better one, since the boundary of a connected model can be enumerated and audited. The boundary of a hand-maintained model is much harder to state, because it depends on what each contributor happened to know.

Auditability Is Becoming a Procurement Question

This reaches beyond the audit itself. Enterprise buyers may run architecture and security reviews before signing. The questions are specific: what runs where, what depends on what, where does customer data sit, and how do you know?

The pattern that causes trouble is familiar. The security questionnaire gets answered from the architecture documentation; the documentation is a year old, and the answer is wrong in a way nobody has noticed. It surfaces in a follow-up call or, worse, in a later incident that contradicts what was submitted.

The practical consequence is that “we review architecture annually” reads as a weak answer to that question. The buyer wants to know what is true right now.

Where a Live Model Fits

We built our Architecture IDE to support decisions about what to change and why. For governance teams, that means architecture evidence they can review alongside policies, controls, and audit records. Compliance and GRC workflows remain separate: our contribution is understanding the system those requirements apply to.

That is the layer we built Stacks for. Stacks is not a diagramming tool. It is our live model of your architecture as it actually runs, derived from connected sources rather than drawn. A hand-drawn picture records what someone believed on the day they drew it, which is the whole difference. We wrote about what that means for cloud estates in our piece on modeling AWS infrastructure.

The compliance-relevant question is whether the available current-state evidence matches the intended architecture. Your team can use that comparison to investigate deviations and preserve the reasoning behind an approved change or exception. It does not establish control effectiveness or automatically correct a running system. Archie, our conversational entry point, helps you investigate questions such as which services depend on a database, grounded in the evidence available to the workspace.

Coverage belongs here rather than in small print. Our analysis is bounded by the connected sources and context you provide; infrastructure integrations are read-only, so coverage is bounded by what you have connected, and you should be able to state that boundary out loud. We work with architecture teams beyond AWS-only estates; we need to confirm available integrations and evidence coverage for your environment.

The most important limit here is scope. We provide current architecture evidence, not compliance itself. Controls, testing, and attestation remain separate work, and a live model is an input to them, not a replacement. If you want to see what that input looks like against your own estate, our platform is the place to start.

What to Prove First

Do not try to make the whole estate provable at once. Four things, in this order, because each makes the next one cheaper.

Prove what is running. Not what should be running. A derived inventory of components, their configuration and their connections, with a known coverage boundary you can state out loud.

Prove the dependencies. This is what Article 8(4) asks of financial entities under DORA, and it is what hand-maintained registers get wrong most often anywhere, because a new queue rarely triggers a documentation update.

Prove divergence from intent. Where the built estate has moved away from the design that was approved. This is the claim a review board was always supposed to be making, and the one it has the least evidence for.

Then connect the evidence to the controls you already have. Use it alongside the controls, testing, and attestations in your SOC 2 or ISO 27001 program, with its sources and coverage limits made explicit.

Conclusion

Compliance is a state, not a snapshot, and that part is no longer contested. What has not been worked through is that a continuous check is only as good as the model it checks against. That model has quietly stayed a document while everything around it became automated.

DORA makes the need for asset and dependency evidence concrete. A derived model can help keep that evidence current, while the organization remains responsible for its governance and compliance obligations.

Book a demo to discuss architecture evidence for your governance process.