Compliance, waivers, and architecture contracts

50 min 6 outcomes 4 standards cited

Architecture governance keeps delivery faithful to design through the TOGAF Architecture Compliance review process, covered here in full with its six levels of conformance and structured review steps. The difference between rule compliance and intent compliance follows, alongside what makes a healthy waiver and how from C220 make agreements between architecture and delivery explicit rather than assumed.

By the end of this module you will be able to:

  • Explain the TOGAF Architecture Compliance review process, including its six levels of conformance and the structured review steps
  • Differentiate rule compliance from intent compliance with practical examples and explain why both layers are needed
  • Describe the six elements that make a waiver healthy rather than dangerous, and identify the element most commonly missing
  • Define architecture contracts from the C220 EA Capability and Governance volume, place them at the start of Phase G and their reuse in Phase H, and describe their contents and when they add value
  • Explain how compliance evidence flows from delivery through to the Architecture Board across the full governance cycle
  • Apply compliance, waiver, and contract logic to London's publication, resilience, and interoperability obligations

Every project marked compliant. Fourteen had deviated materially.

A financial services regulator conducted a review of a large bank's technology modernisation in 2022. The bank had a well-documented architecture governance process. Every project had been marked as "compliant" in the governance register.

When the regulator examined the actual implementations, it found that fourteen projects had deviated materially from the . Three had introduced non-standard data-persistence patterns that would make future significantly harder. Two had bypassed the approved authentication framework. One had created a shadow copy of the customer master record.

The deviations were not malicious. They were pragmatic responses to delivery constraints: tight timelines, vendor limitations, and local team skill profiles. But they had never been recorded as exceptions. The compliance register said "compliant" because each project had completed the formal compliance checklist. The checklist asked whether the right documents existed, not whether the architecture's deeper intent was preserved.

The bank had rule compliance. It did not have intent compliance. The distinction matters because the former checks the letter while the latter protects the spirit.

If a governance process checks formal adherence to standards but not whether the architecture's deeper purpose is preserved, is the enterprise really compliant?

The Architecture Compliance Review lifecycle, from request to a recorded decision

A project never surprises the Architecture Board: it raises a request, the lead architect prepares an evidence pack, the Board reaches a decision of pass, conditional or fail, and that decision is recorded in the Repository where everyone can see it.

The Architecture Compliance Review lifecycle, from request to a recorded decision Five flat panels over two rows in a left-to-right lifecycle joined by accent flow arrows. The top row runs Step 1, Review request raised by the project, to Step 2, Evidence pack prepared by the lead architect, to Step 3, Compliance review held by the Architecture Board. A wrapping arrow labelled then drops to the second row, indented so Steps 4 and 5 sit under the gaps above: Step 4, Decision reached by the Board, to Step 5, Recorded in the Repository by the architecture capability. Three chips hang from the Decision reached card, a green Pass, a neutral Conditional and an amber Fail, and a matching three-state legend names those same decisions, following TOGAF Architecture Compliance. Five steps, in the order the work moves Step 1Step 2Step 3Step 4Step 5Review request raisedProject or programme Evidence pack preparedLead architect Compliance review heldArchitecture Board Decision reachedArchitecture Board Recorded in RepositoryArchitecture capability then PassConditionalFail Pass, the project may proceedConditional, remedy required firstFail, dispensation or rework

Dispensation, the time-bound exception instrument that TOGAF also calls a waiver

TOGAF treats dispensation and waiver as one time-bound exception instrument. A wrong standard is revised through change management; both routes are logged so non-compliance never stays silent.

Dispensation, the time-bound exception instrument that TOGAF also calls a waiver A branching governance flow. Non-compliance identified flows down to the Architecture Board, which assesses impact, duration and standard fit, then branches into two accent-tinted routes. Left, along an arrow labelled temporary breach, is Dispensation (waiver), tagged time-bound, granted when the deviation is justified, a time period is agreed and expiry forces re-assessment, and never granted indefinitely. Right, along an arrow labelled standard is wrong, is a Change request, raised when the standard itself is wrong here, so change management revises the standard. Both converge on the Governance Log in the Repository, following TOGAF Architecture Governance. One breach, one time-bound instrument, one log Non-compliance identifiedWe cannot meet standard X as writtenArchitecture Board assessesImpact, duration and standard fitDispensation (waiver)Time-boundChange requestPhase HGranted when- The deviation is justified- A time period is agreed- Expiry forces re-assessmentNever granted indefinitelyRaised when- The standard itself is wrong here- Compliance will never make sense- Everyone gains from a revisionChange management revises the standardGovernance Log in the RepositoryBoth routes leave a visible record temporary breachstandard is wrong

That story illustrates the gap between rule compliance and intent compliance. This module explains why both are needed, how the TOGAF Architecture Compliance review process works in full, how waivers can be healthy governance instruments rather than governance failures, and when architecture contracts add value.

If you are already confident with compliance review, use the knowledge checks to confirm your understanding and move to Module 55: Skills, roles, and maturity models.

54.1 The TOGAF Architecture Compliance review process

Architecture Compliance is a chapter of the TOGAF Standard's EA Capability and Governance volume, part of the C220 set. It exists to catch deviations early in the project lifecycle, when they are still cheap to correct, rather than after delivery when the cost and risk of changing course has grown. A compliance review also surfaces where an enterprise standard itself has become the problem, which is what routes a finding to change management rather than to a waiver. Understanding it is essential because ad hoc compliance checking produces exactly the false confidence described in the opening story.

The six levels of conformance

The standard defines six levels of architecture conformance, each describing a different degree of overlap between the features in the architecture specification and the features in the implementation. These levels prevent compliance from collapsing into a binary yes/no assessment.

  1. Irrelevant. The implementation has no features in common with the architecture specification, so the question of conformance does not arise. This level is important because it prevents the governance process from claiming jurisdiction over areas the architecture has not addressed.
  2. Consistent. The implementation shares some features with the architecture specification, and those common features are implemented in accordance with it. But some specified features are missing from the implementation, and the implementation has other features the specification does not cover. Each side has features the other lacks.
  3. Compliant. Some features in the architecture specification are not implemented, but every feature that has been implemented is covered by the specification and built in accordance with it. The implementation is a faithful subset of the specification.
  4. Conformant. All the features in the architecture specification are implemented in accordance with it, but the implementation also carries extra features that the specification does not cover.
  5. Fully conformant. There is full correspondence between the architecture specification and the implementation. Everything specified is implemented in accordance with the specification, and nothing has been implemented that the specification does not cover.
  6. Non-conformant. Any of the above in which some features of the architecture specification are implemented, but not in accordance with it. This level triggers the exception and waiver process. Non-conformance is not automatically a governance failure. It becomes a governance failure only when it is invisible or unmanaged.

The governance response should be different at each level. An implementation that is consistent or compliant needs a plan for the it has not yet implemented. One that is conformant carries extra features the architecture should either absorb or challenge. One found non-conformant needs correction, rejection, or a governed waiver. Treating all levels the same defeats the purpose of the graduated model.

The structured review steps

The Architecture Compliance chapter sets out a full review process with named roles and detailed steps, not a single generic checkpoint. This course condenses it into five practical moves that keep the named roles intact.

  1. Raise the request and confirm scope.The project or programme requests the review under the enterprise's governance policy, and a lead architect confirms which architecture requirements apply. Not every requirement applies to every project, so the scope determination prevents the review from becoming an open-ended audit.
  2. Prepare the evidence pack. The lead architect assembles the implementation evidence a tailored checklist calls for: design documents, test results, configuration records, and any deviation documentation.
  3. Hold the review. The or its delegated reviewers interview the project against the checklist and compare the evidence to the applicable requirements, assigning a conformance level for each requirement area.
  4. Record findings. Document the conformance assessment, including the level assigned, the evidence examined, and any conditions or follow-on actions required.
  5. Decide and sign off. The Board reaches a formal decision to accept, require correction, or grant a waiver, and that decision is recorded in the Repository so it is visible to future reviewers.

Compliance, waiver and contract as one flow ending in audit evidence

These are four stages of one flow, not three separate processes: a compliance check surfaces a gap, a waiver request justifies it, the Architecture Board sets contract terms, and the whole trail is filed, so each stage feeds the next and the record must hold from the first check.

Compliance, waiver and contract as one flow ending in audit evidence Four flat stage panels wrap over two rows, joined by labelled flow arrows, each panel naming its stage, the role that owns it and the artefact it hands on. Top row: Stage 1, Compliance check, owned by the architect, tests a requirement and outputs a named gap. An arrow labelled raises leads to Stage 2, Waiver request, owned by the requester, which outputs a decision request. An arrow labelled decides wraps down to the second row: Stage 3, Contract, owned by the board and tinted to mark the governed decision, setting the agreed terms. An arrow labelled files leads to Stage 4, Audit evidence, owned by the auditor, filing the whole trail as the audit record the auditor reads. Stage 1Compliance checkRequirement testedOwned byArchitectOutput: a named gap Stage 2Waiver requestGap justified, owner setOwned byRequesterOutput: decision request Stage 3ContractScope, expiry, conditionsOwned byBoardOutput: agreed terms Stage 4Audit evidenceWhole trail filedOwned byAuditorOutput: the audit record raises files decides

54.2 Rule compliance and intent compliance

The distinction between rule compliance and intent compliance is not explicit in TOGAF but emerges from practical governance experience and from the standard's insistence that a compliance review examines architectural criteria, spirit, and business objectives rather than mere documentation completeness. Understanding both layers is essential because the opening story shows what happens when an enterprise checks only one.

Rule compliance

Rule compliance asks: has the design met the formal standards, controls, and obligations that apply at this stage? This includes technical standards (approved integration patterns, data formats, security controls), regulatory requirements (Ofgem data publication standards, NCSC cyber controls), and (published and ratified by the Architecture Board). Rule compliance is necessary but not sufficient. An implementation that ticks every formal box can still undermine the architecture's purpose.

Intent compliance

Intent compliance asks: does the design still preserve the architecture's deeper purpose even after local compromises? Intent compliance checks whether the implementation preserves customer clarity, evidence quality, , resilience, and future coherence. The bank in the opening story passed rule compliance (every checklist completed) but failed intent compliance (fourteen projects had undermined the architecture's purpose by creating non-standard patterns, bypassing authentication, and duplicating master data).

Intent compliance is harder to assess than rule compliance because it requires judgement rather than checklist verification. The reviewer must understand what the architecture was trying to achieve, not just what it formally specified, and then assess whether the implementation preserves that achievement.

Conditional alignment

Conditional alignment asks: can the change move forward temporarily because compensating controls, follow-on work, and review conditions are explicit and bounded? This is the governed middle ground between full compliance and rejection. It is where waivers live. Conditional alignment is a mature governance response that acknowledges reality while preserving visibility and control.

The three-layer model (rule, intent, conditional) gives the governance process the vocabulary to handle real-world situations. Pure binary compliance (pass or fail) forces the enterprise into either pretending everything is fine or rejecting everything that deviates. The three-layer model allows honest assessment with proportionate response.

Common misconception

“Passing all formal compliance checks means the architecture is protected.”

Rule compliance is necessary but not sufficient. A design can tick every formal box and still undermine the architecture's purpose. Intent compliance asks whether the deeper objectives (interoperability, resilience, future coherence) are preserved. Both layers are needed. The bank in the opening story had perfect rule compliance and fourteen material deviations.

54.3 What makes a healthy waiver

When a compliance review identifies non-conformance, the enterprise has three options: fix the deviation, reject the implementation, or grant an exception. TOGAF's own term for this exception is a dispensation, which the standard also calls a waiver; this module uses "waiver" as the plain-English label for the same instrument. Waivers are not a sign of governance failure. They are a sign that the enterprise is mature enough to acknowledge reality while preserving visibility and control. A wrong or outdated standard is not waived; it is routed to change management for revision. However, an unhealthy waiver is worse than no waiver because it creates the illusion of governance while accumulating unmanaged architecture debt.

A healthy waiver contains six elements. The absence of any element weakens the waiver's governance value.

  1. Deviation description. A clear, specific statement of what the implementation does differently from the and why. Vague descriptions like "minor deviation from standard" are not acceptable because they prevent future reviewers from understanding the actual deviation.
  2. Enterprise consequence. An honest assessment of the impact the deviation creates for the wider enterprise. This includes technical debt, future integration cost, resilience impact, and regulatory risk. The consequence assessment should be specific enough that the Architecture Board can weigh the trade-off rationally.
  3. Business justification.A clear explanation of why the deviation is the right trade-off given current constraints. The justification must be specific enough that a future reviewer can understand the reasoning. "We ran out of time" is an explanation; it is not a justification unless it also explains why the timeline constraint outweighed the architecture consequence.
  4. Compensating controls. Any measures put in place to reduce the impact of the deviation while it persists. For example, additional monitoring, manual reconciliation, restricted access, or enhanced audit logging. Compensating controls acknowledge that the deviation creates risk and describe how that risk is managed.
  5. Expiry condition. A date or trigger by which the deviation must be resolved, reviewed, or formally extended. This is the element most commonly missing from waivers. Open-ended waivers accumulate into unmanaged architecture debt because nobody is accountable for resolving them. The expiry condition should be realistic but non-negotiable: the waiver expires, and if the deviation has not been resolved, it must be re-submitted for fresh approval.
  6. Governance approval. Formal approval from the appropriate governance forum. Material deviations should be approved by the . Bounded deviations within a single domain may be approved by the domain architect with notification to the board. The approval should be recorded in the exception register with a reference to the board meeting or delegated authority that granted it.

The waiver expiry control as a closed governance cycle

The secretariat monitors the register, alerts the owner thirty days before expiry, forces a decision to extend or close, then closes and archives, and the closing arrow loops back into the next round, so a waiver cannot expire unseen and harden into permanent policy drift.

The waiver expiry control as a closed governance cycle Four step panels form a clockwise ring around a central label reading The waiver control cycle. Step 1 Monitor, owned by the secretariat, sits at the top. An accent arrow labelled flags expiry curves to Step 2 Alert on the right, where the owner is notified thirty days before expiry. An accent arrow labelled prompts curves to Step 3 Decide at the bottom, where the owner extends with new justification or accepts closure. An accent arrow labelled resolves to curves to Step 4 Close on the left, where the waiver leaves the register. A closing arrow labelled returns to monitoring completes the ring from Close back to Monitor, so every expiry is forced to a decision. 1MonitorSecretariat watches the registerOwner: governance secretariat 2AlertThirty days before expiryWaiver owner is notified 3DecideExtend with new justificationOr accept the closure 4CloseRemoved from active registerDecision log archived The waiver control cycle Every exception is forced to a decision before it can quietly become policy flags expiry prompts resolves to returns to monitoring

54.4 Architecture contracts from C220

The EA Capability and Governance volume of C220 defines an as a joint agreement between development partners and sponsors on the , quality, and fitness-for-purpose of an architecture. The contract makes the agreement between architecture and delivery explicit rather than assumed. In the ADM cycle this is not a free-floating governance idea: the contract is what Phase G, Implementation Governance, is built around. It is established at the start of Phase G, and the Architecture Compliance reviews this module has already covered are how Phase G checks delivery against it. Phase H, Architecture Change Management, then reuses the same contract as the reference point for judging whether a later change is a routine deviation or something that should trigger a fresh pass through the ADM.

What an architecture contract contains

In practical terms, an architecture contract defines what the delivery team has agreed to build, what conformance criteria will be used to verify the result, what happens if the implementation deviates from the agreed architecture, and what review points exist during delivery. It is not a legal document. It is a governance instrument that prevents the common situation where architecture produces a target and delivery builds something different without anyone formally acknowledging the gap.

The contract typically includes the following elements:

  • Scope and boundary. What the delivery team is building and what falls outside the contract. This prevents scope creep in both directions.
  • Conformance criteria. The specific architecture requirements that the implementation must satisfy, drawn from the and the architecture principles.
  • Review points. When and how conformance will be assessed during delivery. Typically aligned with project stage gates or sprint boundaries.
  • Exception escalation. What happens when the delivery team discovers it cannot conform. The contract should define the escalation path (waiver request to the Architecture Board) rather than leaving teams to improvise.
  • Signatories. The named individuals who commit to the contract on behalf of architecture and delivery. The mutuality is important: an architecture contract is not imposed by the architecture team on delivery. It is a mutual commitment.

When architecture contracts add most value

Architecture contracts are most valuable in three situations:

  • Cross-team handoffs. When architecture work is handed to a delivery team that did not participate in the architecture design, the contract ensures the delivery team understands and accepts the conformance expectations before work begins.
  • External delivery partners. When third parties or outsourced teams are responsible for implementation, the contract provides a formal conformance benchmark that survives personnel changes and vendor transitions.
  • Regulated milestones. When a has regulatory consequence, the contract ensures that architecture conformance criteria are agreed before delivery begins rather than improvised during assurance review.

54.5 How compliance evidence flows through the governance cycle

Compliance is not a single event. It is a cycle that connects delivery behaviour to governance decisions through a chain of evidence. Understanding the full flow prevents the enterprise from treating compliance as a one-off checklist.

  1. Architecture contract agreed. The delivery team and the architecture function agree the conformance criteria before delivery begins.
  2. Delivery produces evidence. During delivery, the team produces design documents, test results, configuration records, and deviation documentation. This evidence accumulates as the that the compliance review will examine.
  3. Compliance review at milestone. At each agreed review point, an Architecture Compliance review assesses the evidence against the conformance criteria and assigns a conformance level.
  4. Findings reported to board. The compliance findings are presented to the Architecture Board with recommendations. Non-conformances are accompanied by waiver requests or correction plans.
  5. Board decides. The board reviews the findings and decides: accept, require correction, or grant a waiver with the six required elements.
  6. updated. The compliance record, decision log, and exception register are updated within 24 hours. The compliance evidence is now part of the governance memory.
  7. Waiver expiry tracked. Active waivers are monitored against their expiry conditions. Before expiry, the waiver is either resolved (deviation fixed), extended (with fresh approval), or escalated (if neither resolution nor extension is possible).

This cycle ensures that compliance evidence flows continuously from delivery through to governance, and that governance decisions flow back to delivery as accepted constraints, waiver conditions, or correction requirements.

54.6 London Grid Distribution: compliance in a regulated utility

London operates under Ofgem regulation with specific obligations around data publication, cyber resilience, customer service standards, and network reliability. That regulatory context makes compliance particularly important because architecture deviations can create regulatory risk, not just technical debt.

Rule compliance in London

  • Data publication components must conform to the approved information authority model and the LTDS (Long Term Development Statement) requirements.
  • Cyber-relevant components must meet the baseline controls defined in alignment with the NCSC Cyber Assessment Framework.
  • Customer-facing systems must meet the connection offer timescale standards required by Ofgem.
  • Network operational technology must conform to the approved OT/IT boundary architecture.

Intent compliance in London

  • Does the data publication pipeline preserve the information authority rules that prevent conflicting sources of truth?
  • Does the cyber architecture maintain the separation and monitoring principles that protect operational resilience?
  • Does the customer connections process preserve the end-to-end visibility that prevents customers from falling into process gaps?
  • Does the network technology architecture maintain the interoperability that future regional energy planning will require?

Example London waiver

A delivery team implementing a new connection-offer calculation engine discovers that the approved integration pattern cannot meet the required response time under peak load. They request a waiver to use a direct database query instead of the approved API gateway for a six-month period.

  • Deviation: Direct database access bypassing the API gateway for the connection-offer calculation under peak load.
  • Enterprise consequence: Reduced auditability and monitoring for connection-offer calculations during peak periods. The API gateway provides audit logging and rate limiting that the direct query bypasses.
  • Justification: The connection offer timescale standard required by Ofgem cannot be met under peak load using the current API gateway configuration. The response-time requirement outweighs the audit gap for a bounded period.
  • Compensating controls: Additional database logging and a manual reconciliation process for connection offers calculated during peak periods.
  • Expiry: Six months from approval date, conditional on the API gateway performance issue being resolved within the waiver period.
  • Governance approval: Architecture Board, with a condition that the API gateway team reports progress at each monthly board meeting.
Check your understanding

A project passes all formal architecture compliance checks but uses a data-publication pattern that makes future interoperability significantly harder. What type of compliance failure does this represent?

A delivery team requests a waiver to use a non-standard authentication mechanism for six months while the standard mechanism is being upgraded. Which of the six waiver elements is most likely to be missing if the waiver is poorly constructed?

TOGAF defines six levels of architecture conformance. An implementation delivers every feature in the architecture specification in accordance with it, but also includes extra features the specification does not cover. Which level applies?

An architecture contract between the architecture function and a delivery team specifies conformance criteria but does not include an exception escalation path. What governance risk does this create?

Core distinctions

  • The TOGAF Architecture Compliance chapter defines six levels of conformance (irrelevant, consistent, compliant, conformant, fully conformant, non-conformant), graded by how the implementation's features overlap with the architecture specification, so compliance never collapses into binary pass/fail.
  • Rule compliance checks formal adherence to standards and controls. Intent compliance checks whether the architecture's deeper purpose is preserved. Both layers are needed.
  • A healthy waiver contains six elements: deviation description, enterprise consequence, business justification, compensating controls, expiry condition, and governance approval. The expiry condition is the element most commonly missing.
  • Architecture contracts from C220's EA Capability and Governance volume make agreements between architecture and delivery explicit. The contract is established at the start of Phase G, Implementation Governance, and Phase H, Architecture Change Management, reuses it to judge later deviations. Contracts are most valuable for cross-team handoffs, external delivery partners, and regulated milestones.
  • Compliance evidence flows through a continuous cycle: contract, delivery evidence, review, board decision, repository update, waiver tracking.
  • In regulated enterprises like London, compliance has regulatory consequence, not just technical debt. The three-layer model (rule, intent, conditional) gives governance the vocabulary for honest assessment.

Standards and sources cited in this module

  1. The TOGAF Standard, 10th Edition (C220)

    EA Capability and Governance: Architecture Contracts

    The core standard covering compliance, waivers, and architecture contracts.

  2. The TOGAF Standard: EA Capability and Governance, Architecture Compliance

    Architecture Compliance chapter

    Primary chapter defining the compliance review process, the six levels of conformance, and the structured review steps.

  3. G184, Leader's Guide to Establishing and Evolving an EA Capability

    Full guide

    Governance and compliance guidance as part of architecture capability development.

  4. NCSC Cyber Assessment Framework

    Full framework

    Cyber compliance framework relevant to London's regulated utility context and OT/IT boundary controls.

You now understand compliance as both rule and intent checking, with waivers as a mature governance mechanism and architecture contracts as the tool that makes agreements explicit. The next question is how the G198 Architecture Skills Framework supports capability growth. That is Module 55.

Previous: Architecture Board and decision rightsNext: Skills, roles, and maturity models

Module 54 of 72 · EA Capability and Governance

Try it in the workspace

One tool reinforces this module.

Architecture Decision Record

Document an architecture decision in the Nygard format with context, decision, status and consequences so the reasoning survives the meeting.

Nygard ADRQuick · 15 minutes per ADR
Open tool