Architecture Compliance Assessment: [Project or solution name]
Architecture Compliance Assessment for one project, work package or
solution, the review record used in Phase G (Implementation Governance)
of the Architecture Development Method in The TOGAF Standard, 10th
Edition (2025 release with Technical Corrigendum 1). It states which approved architecture the project
was measured against, checks the design and the build domain by domain,
traces every contracted requirement to evidence, records findings,
requested dispensations and conditions, and closes with one rating and
the Architecture Board decision. Replace every [bracketed] value and
every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [ACA-YYYY-NNN] |
| Project or work package | [Project name, WP-nn] |
| Architecture Contract | [AC-nn, version] |
| Review point | [Concept / Design / Pre-production / Post-implementation] |
| Review tier | [Tier 1 / Tier 2 / Tier 3, per the board charter] |
| Board outcome record | [ARB-YYYY-NNN] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead assessor) | [@lead-assessor] |
| Approvers / reviewers | [Architecture Board chair, domain architects, security architect] |
| Assessed party | [Delivery team or supplier name, @delivery-lead] |
| Assessment period | YYYY-MM-DD to YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Conditions | Date |
|---|
| Lead assessor | [@lead-assessor] | [Submitted to board] | [None] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Compliant / Compliant with conditions / Dispensation / Non-compliant] | [Condition IDs] | YYYY-MM-DD |
| Security architect | [@security] | [Agreed / Not agreed] | [Conditions] | YYYY-MM-DD |
| Delivery lead (acknowledgement) | [@delivery-lead] | [Acknowledged] | [Comments] | YYYY-MM-DD |
| Business owner (risk acceptance) | [@business-owner] | [Accepts residual risk / Does not accept] | [Conditions] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, baseline and evidence request issued to the delivery party |
| 0.5 | YYYY-MM-DD | [@name] | Example: Checklist completed, eight findings drafted and discussed with the delivery lead |
| 1.0 | YYYY-MM-DD | [@name] | Example: Board decision ARB-2027-007 recorded: compliant with conditions C1 and C2 |
Contents
1. Assessment summary
| Item | Result |
|---|
| Overall rating | Example: Conformant with conditions |
| Recommended board outcome | Example: Compliant with conditions |
| Checks assessed | Example: 33 checks: 20 conformant, 7 conformant with conditions, 4 partially conformant, 2 non-conformant, 0 not applicable |
| Findings | Example: 8 findings: 1 high, 7 medium, 0 low |
| Dispensations requested | Example: 1 (DSP-2027-02, batch export to the legacy CRM for 9 months) |
| Conditions proposed | Example: 2 (C1 matching accuracy report, C2 retention rules configured) |
| Decision requested | [Approve the outcome, the conditions and the dispensation] |
Example narrative: The customer data hub design conforms to the target
data and application architecture and to all mandatory technology
standards. Of the two non-conformant checks, CHK-DAT-04 (retention rules
not yet designed for two entities) is resolved by condition C2 before
go-live. CHK-INT-03 is the interim nightly batch export to the legacy
CRM, which departs from principle AP-01 and needs dispensation
DSP-2027-02 until the CRM is retired. The matching accuracy target in
ARS-DAT-03 is designed for but not yet evidenced at full volume, which is
condition C1.
2. Scope, trigger and timing
2.1 Subject of the assessment
| Field | Value |
|---|
| Solution or work package | Example: WP-02 Customer data hub: golden customer record, matching service, customer API, event publication |
| Design version assessed | Example: Solution design v1.2 dated YYYY-MM-DD; data model release 0.9 |
| Environments in scope | Example: Design documents only; no running environment at this review point |
| Out of scope | Example: Claims platform changes (WP-03), handler workspace (WP-04), vendor internal code quality |
| Related assessments | Example: Concept review ARB-2027-004 (compliant) |
2.2 Trigger and review point
| Review point | Typical timing | What is assessed | Used here |
|---|
| Concept | Before funding of detailed design | Fit with target architecture and roadmap; options considered | No |
| Design | Before build starts | Design against principles, standards and contracted requirements | Example: Yes |
| Pre-production | Before go-live | Built system and configuration against the approved design; conditions closed | No |
| Post-implementation | [3 to 12] months after go-live | Realised architecture, drift, debt incurred | No |
Example: this assessment is triggered by review point R2 in contract
AC-02 (section 8 of the contract), tier 1 under the board charter because
the hub holds personal data of more than [100,000] customers.
2.3 Assessment team and independence
| Role | Name | Independence from the project |
|---|
| Lead assessor | [@lead-assessor] | Example: Enterprise data architect, not on the project |
| Domain assessor, application and integration | [@name] | Example: Independent |
| Domain assessor, technology | [@name] | Example: Platform team member; declared interest in hosting choice |
| Security assessor | [@security] | Example: Independent |
| Project contact | [@delivery-lead] | Assessed party |
Record any declared interest. An assessor with an interest in a check
does not rate that check; another assessor does.
3. Architecture baseline used
| Ref | Baseline item | Version / date | Source | Precedence |
|---|
| BL-01 (Example) | Architecture Contract AC-02 | 1.0, YYYY-MM-DD | architecture/architecture-contract | 1 |
| BL-02 (Example) | Architecture Requirements Specification, the IDs contracted in AC-02 section 5.1 | 1.0 (baseline B1) | architecture/architecture-requirements-specification | 2 |
| BL-03 (Example) | Architecture Definition Document, data and application parts | 1.0 | architecture/architecture-definition-document | 3 |
| BL-04 (Example) | Architecture Principles Catalogue | 2.3 | architecture/architecture-principles | 4 |
| BL-05 (Example) | Technology standards list and radar (adopt ring) | Snapshot YYYY-MM-DD | architecture/tech-radar | 4 |
| BL-06 (Example) | Security architecture and zero trust patterns | 2.0 | security/security-architecture | 4 |
| BL-07 (Example) | Integration reference architecture | 1.4 | architecture/reference-architecture | 5 |
| [BL-nn] | [Item] | [Version] | [Location] | [Rank] |
Precedence rule: Example: the contract wins over the requirements
specification, which wins over the definition document; principles and
standards apply where the higher documents are silent. Standards changes
published after the contract date apply only if the contract was varied
to include them (record the variation ID).
4. Method and rating scale
4.1 Steps
- Agree the scope and the frozen design version with the delivery lead.
- Send the evidence request (section 5) at least [5] working days before
the assessment sessions.
- Rate every check in section 6 using the scale in 4.2, citing evidence.
- Trace every contracted requirement in section 7.
- Walk through draft findings with the delivery lead to correct factual
errors; ratings remain the assessor's decision.
- Roll up to an overall rating with the rules in 4.3 and submit to the
board.
4.2 Per-check rating scale
This scale is original to this template. It is not the graded compliance scale described in the TOGAF Standard. Organisations that use another
graded scale can map it here, as long as the mapping is published.
| Code | Rating | Meaning | Evidence needed |
|---|
| C | Conformant | The design or build meets the requirement fully | Named evidence that shows it |
| CC | Conformant with conditions | Meets the intent; a specific, small gap will be closed by a date | Evidence plus a dated condition |
| PC | Partially conformant | Part of the requirement is met; material gap remains | Evidence of what exists; finding raised |
| NC | Non-conformant | The requirement is not met or is contradicted | Finding raised; condition, dispensation or rework |
| NE | Not evidenced | Claimed but no evidence provided by the deadline | Treated as NC for roll-up until evidence arrives |
| NA | Not applicable | The requirement does not apply to this scope | Reason recorded |
4.3 Roll-up rules
| Rule | Condition | Effect on overall rating |
|---|
| R1 | Any NC or NE on a check marked critical, with neither a dated condition nor a dispensation proposed | Overall rating is non-conformant |
| R2 | Any NC on a non-critical check, or any PC on a critical check | Overall rating is at best conformant with conditions |
| R3 | More than [20%] of applicable checks rated PC or worse | Overall rating is at best partially conformant |
| R4 | All applicable checks C or CC | Overall rating is conformant with conditions if any CC exists, otherwise conformant |
4.4 Mapping to board outcomes
| Overall rating | Usual board outcome (charter section 7) |
|---|
| Conformant | Compliant |
| Conformant with conditions | Compliant with conditions |
| Partially conformant | Compliant with conditions if every gap has a dated condition; otherwise non-compliant |
| Non-conformant, deviation justified | Dispensation (time-limited, with exit plan) |
| Non-conformant, deviation not justified | Non-compliant: rework and resubmit |
5. Evidence register
| Evidence ID | Artefact | Version / date | Provided by | Type |
|---|
| EV-01 (Example) | Solution design document, customer data hub | 1.2, YYYY-MM-DD | Delivery lead | Document |
| EV-02 (Example) | Logical data model and data dictionary extract | Release 0.9 | Data architect | Model |
| EV-03 (Example) | Interface catalogue and API specification (OpenAPI) | 0.8 | Integration lead | Specification |
| EV-04 (Example) | Threat model and security controls matrix | 1.0 | Security champion | Document |
| EV-05 (Example) | Infrastructure as code repository, main branch | Commit [hash] | Platform engineer | Configuration |
| EV-06 (Example) | Matching algorithm test results on a 50,000 record sample | YYYY-MM-DD | Data team | Test result |
| EV-07 (Example) | Architecture decision records ADR-014 to ADR-019 | Current | Lead developer | Decision record |
| EV-08 (Example) | Interview with operations lead on monitoring design | YYYY-MM-DD | Assessor notes | Interview |
| [EV-nn] | [Artefact] | [Version] | [Who] | [Document / Model / Configuration / Test result / Interview] |
Evidence requested but not provided by the deadline: Example: data
retention design for entities Household and Contact Preference. CHK-DAT-04
is rated NC rather than NE because the data model (EV-02) shows that no
rules exist for these entities.
6. Compliance checklist by domain
Columns: Crit marks a critical check (Y or N). Rating uses the
scale in 4.2.
6.1 Business and process
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-BUS-01 | Does the solution support the business capabilities assigned to this work package and no others? | BL-03 | N | EV-01 | C (Example) | Customer information management only |
| CHK-BUS-02 | Are the process changes for business users documented and owned by a named business role? | BL-01 | N | EV-01 | CC (Example) | Data steward process drafted; owner to be confirmed before go-live |
| CHK-BUS-03 | Do the benefits this work package contributes to have a measure and an owner? | BL-01 | N | EV-01 | C (Example) | KPI-02 golden ID coverage |
| [CHK-BUS-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [C / CC / PC / NC / NE / NA] | [Note] |
6.2 Information and data
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-DAT-01 | Is every data entity in scope mastered in exactly one system, as the target data architecture states? | BL-03, DP-01 | Y | EV-02 | C (Example) | Customer and Party mastered in the hub |
| CHK-DAT-02 | Does the design meet the matching accuracy target in ARS-DAT-03, with a test method? | BL-02, ARS-DAT-03 | Y | EV-06 | CC (Example) | Method sound; full-volume result pending (C1) |
| CHK-DAT-03 | Are data owners and stewards named for every mastered entity? | BL-04 | N | EV-02 | C (Example) | Named in the data dictionary |
| CHK-DAT-04 | Are retention and deletion rules designed for every entity holding personal data? | BL-02, ARS-DAT-05 | Y | EV-02 | NC (Example) | Two entities missing (FND-01, C2) |
| CHK-DAT-05 | Is personal data classified and are the classification labels carried into storage and APIs? | BL-06 | Y | EV-02, EV-03 | C (Example) | |
| CHK-DAT-06 | Is consent, with its history, recorded for each customer and purpose, including records migrated from each source? | BL-02, ARS-DAT-04 | Y | EV-02 | PC (Example) | Policy system C consent has no capture channel (FND-04) |
| [CHK-DAT-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.3 Application
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-APP-01 | Are the application components the ones named in the target application architecture, with no unplanned additions? | BL-03 | N | EV-01 | C (Example) | |
| CHK-APP-02 | Does the solution reuse the approved building blocks where they exist (identity, notification, document store)? | BL-04, TP-01 | N | EV-01 | C (Example) | Reuses group identity service |
| CHK-APP-03 | Are applications to be retired by this work package identified with a retirement date? | BL-01 | N | EV-01 | PC (Example) | Legacy CRM retirement date missing (FND-05) |
| [CHK-APP-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.4 Integration
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-INT-01 | Are all interfaces exposed through the approved API gateway with published specifications? | BL-02, ARS-APP-01 | Y | EV-03 | C (Example) | |
| CHK-INT-02 | Are change events published to the enterprise event platform using the agreed envelope, with the golden customer ID and a schema version? | BL-07, ARS-INT-01 | N | EV-03 | C (Example) | CloudEvents envelope |
| CHK-INT-03 | Are there no new point-to-point file transfers? | BL-04, AP-01 | N | EV-01 | NC (Example) | Interim CRM batch export (FND-02, DSP-2027-02) |
| CHK-INT-04 | Are idempotency, retry and dead-letter handling designed for each asynchronous flow? | BL-07 | N | EV-03 | CC (Example) | Dead-letter replay runbook pending |
| [CHK-INT-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.5 Technology and hosting
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-TEC-01 | Are all products and services on the adopt ring of the technology radar, or approved for trial? | BL-05 | Y | EV-05 | C (Example) | |
| CHK-TEC-02 | Is the workload deployed in the approved landing zone and region, meeting data residency? | BL-02, ARS-DAT-02 | Y | EV-05 | C (Example) | EU region only |
| CHK-TEC-03 | Is all infrastructure defined as code and deployed by pipeline? | BL-05 | N | EV-05 | C (Example) | |
| CHK-TEC-04 | Are product versions supported by the vendor for at least the planned life of this release? | BL-05 | N | EV-05 | CC (Example) | Database minor version reaches end of support in 30 months; upgrade to be planned |
| [CHK-TEC-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.6 Security and privacy
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-SEC-01 | Is there a current threat model covering every external interface and trust boundary? | BL-06 | Y | EV-04 | C (Example) | |
| CHK-SEC-02 | Do all human and machine identities authenticate through the approved identity provider with least privilege? | BL-06 | Y | EV-04, EV-05 | C (Example) | |
| CHK-SEC-03 | Is personal data encrypted in transit and at rest with keys managed in the approved key service? | BL-06 | Y | EV-05 | C (Example) | |
| CHK-SEC-04 | Has a data protection impact assessment been completed or screened out? | BL-02 | Y | EV-04 | CC (Example) | DPIA draft; DPO sign-off pending (FND-03) |
| CHK-SEC-05 | Are security events forwarded to the central monitoring service? | BL-06 | N | EV-05 | C (Example) | |
| [CHK-SEC-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.7 Operations and resilience
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-OPS-01 | Are availability and recovery targets stated and does the design meet the tier assigned to the service? | BL-02 | Y | EV-01 | C (Example) | Tier 2: RTO 4 hours, RPO 15 minutes |
| CHK-OPS-02 | Are service level objectives defined with the telemetry needed to measure them? | BL-02 | N | EV-08 | PC (Example) | Matching latency SLO lacks a metric (FND-06) |
| CHK-OPS-03 | Is a support model agreed with the operations team that will run the service? | BL-01 | N | EV-08 | CC (Example) | Handover plan drafted |
| CHK-OPS-04 | Is backup and restore designed and scheduled for testing before go-live? | BL-02 | Y | EV-01 | C (Example) | |
| [CHK-OPS-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.8 Delivery and documentation
| Check ID | Check | Baseline | Crit | Evidence | Rating | Note |
|---|
| CHK-DOC-01 | Are significant design decisions recorded as decision records with options and reasons? | BL-01 | N | EV-07 | C (Example) | |
| CHK-DOC-02 | Have the deliverables due at this review point under the contract been provided? | BL-01 | N | EV-01 to EV-07 | CC (Example) | Retention design late |
| CHK-DOC-03 | Is the architecture repository updated with the solution models? | BL-01 | N | EV-02 | PC (Example) | Models held only in the project space (FND-07) |
| CHK-DOC-04 | Are deviations from the baseline already known to the project disclosed in the submission? | BL-01 | N | EV-01 | C (Example) | CRM export disclosed |
| [CHK-DOC-nn] | [Check] | [BL-nn] | [Y / N] | [EV-nn] | [Rating] | [Note] |
6.9 Domain summary
| Domain | Applicable | C | CC | PC | NC | NE | NA | Domain rating |
|---|
| Business and process (Example) | 3 | 2 | 1 | 0 | 0 | 0 | 0 | Conformant with conditions |
| Information and data (Example) | 6 | 3 | 1 | 1 | 1 | 0 | 0 | Conformant with conditions (NC covered by C2) |
| Application (Example) | 3 | 2 | 0 | 1 | 0 | 0 | 0 | Conformant with conditions |
| Integration (Example) | 4 | 2 | 1 | 0 | 1 | 0 | 0 | Dispensation requested |
| Technology and hosting (Example) | 4 | 3 | 1 | 0 | 0 | 0 | 0 | Conformant with conditions |
| Security and privacy (Example) | 5 | 4 | 1 | 0 | 0 | 0 | 0 | Conformant with conditions |
| Operations and resilience (Example) | 4 | 2 | 1 | 1 | 0 | 0 | 0 | Conformant with conditions |
| Delivery and documentation (Example) | 4 | 2 | 1 | 1 | 0 | 0 | 0 | Conformant with conditions |
| [Domain] | [n] | [n] | [n] | [n] | [n] | [n] | [n] | [Rating] |
Example: the rows above total the 33 example checks printed in this
template and match the counts in section 1. Recount after you add or
delete checks.
7. Requirements traceability
| Requirement ID | Requirement (short) | Design element | Evidence | Check | Rating |
|---|
| ARS-DAT-03 (Example) | Matching precision of at least 95% on a reviewed sample | Matching service, rules v3 | EV-06 | CHK-DAT-02 | CC |
| ARS-DAT-01 (Example) | One golden customer ID; no writable local copies | Golden record store | EV-02 | CHK-DAT-01 | C |
| ARS-DAT-04 (Example) | Consent and its history per customer and purpose | Consent store | EV-02 | CHK-DAT-06 | PC |
| ARS-DAT-05 (Example) | Owner, retention period and deletion rules for every entity | Retention policy store | EV-02 | CHK-DAT-04 | NC |
| ARS-APP-01 (Example) | Functions exposed only through published APIs on the gateway | Customer API v1 | EV-03 | CHK-INT-01 | C |
| ARS-INT-01 (Example) | Events carry the golden customer ID and a schema version | Customer-changed event | EV-03 | CHK-INT-02 | C |
| ARS-DAT-02 (Example) | Customer data only in EU regions of the approved landing zone | Platform subscription [ID] | EV-05 | CHK-TEC-02 | C |
| ARS-SEC-01 (Example) | Identities through the enterprise identity provider, MFA for users | Identity integration | EV-04 | CHK-SEC-02 | C |
| ARS-SEC-03 (Example) | Exit plan and recovery against tier 2 targets | Multi-zone deployment, backup design, exit plan | EV-01 | CHK-OPS-01 | C |
| ARS-TEC-03 (Example) | Logs, metrics and traces to central observability, enough to measure SLOs | Monitoring design | EV-08 | CHK-OPS-02 | PC |
| [ARS-xxx-nn] | [Requirement] | [Element] | [EV-nn] | [CHK-nn] | [Rating] |
Coverage: Example: 10 of 10 contracted requirements traced; 6 rated C,
1 CC, 2 PC, 1 NC. Keep the full matrix in the requirements traceability
record (requirements/traceability-matrix) if the project maintains one.
8. Findings
8.1 Severity scale
| Severity | Meaning |
|---|
| High | Breaks a critical check or creates a risk the business owner must accept explicitly |
| Medium | Breaks or partly meets a non-critical check, or weakens a critical one; must be resolved by a date |
| Low | Improvement on a check already rated C or CC that brings the solution closer to the baseline; tracked, not blocking |
8.2 Findings register
| Finding ID | Check | Severity | Finding | Impact | Recommended resolution | Proposed treatment |
|---|
| FND-01 (Example) | CHK-DAT-04 | High | Retention and deletion rules missing for Household and Contact Preference | Personal data kept beyond its lawful period; audit exposure | Design and configure rules before go-live | Condition C2 |
| FND-02 (Example) | CHK-INT-03 | Medium | Nightly batch file to legacy CRM until CRM retirement | Departs from AP-01; stale data in CRM up to 24 hours | Accept for a limited time; retire CRM | Dispensation DSP-2027-02 |
| FND-03 (Example) | CHK-SEC-04 | Medium | DPIA not yet signed off by the DPO | Go-live without privacy sign-off | Complete DPIA review | Action A-01 |
| FND-04 (Example) | CHK-DAT-06 | Medium | Consent records from policy system C carry no capture channel | Consent for those customers cannot be fully evidenced; weakens a critical check | Map the channel, or record "migrated" with the source system, before the system C load | Action A-02 |
| FND-05 (Example) | CHK-APP-03 | Medium | No retirement date for the legacy CRM | Dispensation has no end; double running cost | Agree date with CRM owner | Action A-03, linked to DSP-2027-02 |
| FND-06 (Example) | CHK-OPS-02 | Medium | Matching latency SLO has no metric | SLO cannot be reported | Add latency histogram metric | Action A-04 |
| FND-07 (Example) | CHK-DOC-03 | Medium | Models not in the architecture repository | Later projects cannot reuse them | Publish models | Action A-05 |
| FND-08 (Example) | CHK-DAT-02 | Medium | Matching accuracy shown on sample, not full volume | Target may not hold at scale | Run full-volume test | Condition C1 |
| [FND-nn] | [CHK-nn] | [High / Medium / Low] | [Finding] | [Impact] | [Resolution] | [Condition / Dispensation / Action / Rework] |
9. Dispensations requested
| Dispensation ID | Finding | Principle or standard departed from | Reason | Risk and mitigation | Risk owner | Requested term | Exit plan |
|---|
| DSP-2027-02 (Example) | FND-02 | AP-01 Integrate through published interfaces | Legacy CRM has no API; retirement planned | Stale CRM data up to 24 hours; checksum and row-count alerts; CRM read-only for customer fields | [@data-owner] | 9 months (decided by the full board: term over 6 months and personal data affected; security member agrees, data protection officer consulted) | CRM retired in WP-07; batch job deleted |
| [DSP-YYYY-NN] | [FND-nn] | [Principle or standard] | [Reason] | [Risk and mitigation] | [@owner] | [Months] | [Plan] |
Once granted, copy the entry to the dispensation register in the board
charter (architecture/architecture-governance-charter) and record
accepted architecture debt in the tech debt register
(architecture/tech-debt-register).
10. Conditions and actions
10.1 Conditions
| Condition ID | Finding | Condition | Owner | Due | Closure evidence | Verified by |
|---|
| C1 (Example) | FND-08 | Full-volume matching test meets the ARS-DAT-03 target | [@data-lead] | YYYY-MM-DD (before pre-production review) | Test report on full volume, signed by data owner | [@lead-assessor] |
| C2 (Example) | FND-01 | Retention and deletion rules designed, configured and tested for all personal data entities | [@solution-architect] | YYYY-MM-DD | Configuration export and deletion test log | [@security] |
| [Cn] | [FND-nn] | [Condition] | [@owner] | YYYY-MM-DD | [Evidence] | [@verifier] |
10.2 Actions
| Action ID | Finding | Action | Owner | Due | Status |
|---|
| A-01 (Example) | FND-03 | Obtain DPO sign-off of the DPIA | [@privacy-lead] | YYYY-MM-DD | Open |
| A-02 (Example) | FND-04 | Map consent capture channel for policy system C records | [@data-lead] | YYYY-MM-DD | Open |
| A-03 (Example) | FND-05 | Agree and publish the legacy CRM retirement date | [@crm-owner] | YYYY-MM-DD | Open |
| A-04 (Example) | FND-06 | Add matching latency metric and dashboard | [@sre-lead] | YYYY-MM-DD | Open |
| A-05 (Example) | FND-07 | Publish solution models to the repository | [@solution-architect] | YYYY-MM-DD | Open |
| [A-nn] | [FND-nn] | [Action] | [@owner] | YYYY-MM-DD | [Open / Done] |
11. Overall rating and board decision
11.1 Roll-up
| Rule | Applies? | Reason |
|---|
| R1 | Example: No | The only NC on a critical check (CHK-DAT-04) has a condition, and the NC on CHK-INT-03 has a dispensation request |
| R2 | Example: Yes | NC on CHK-INT-03 (non-critical) and PC on CHK-DAT-06 (critical) |
| R3 | Example: No | 6 of 33 applicable checks are PC or worse (18%) |
| R4 | Example: Not reached | R2 already caps the rating |
Overall rating: Example: Conformant with conditions, subject to
DSP-2027-02.
11.2 Board decision
| Field | Value |
|---|
| Outcome record | [ARB-YYYY-NNN] (Example: ARB-2027-007) |
| Forum and date | [Board meeting YYYY-MM-DD] (Example: 2027-04-19) |
| Outcome | Example: Compliant with conditions |
| Conditions | Example: C1, C2 as in section 10.1 |
| Dispensations granted | Example: DSP-2027-02 for 9 months, renewal not pre-approved |
| Changes from the recommendation | Example: None |
| Reasons | [Short reasoned statement citing baseline items] |
| Votes or consensus | [Consensus / For n, against n, abstain n] |
| Declared interests | [Member, item, effect] |
| Signed | [@chair], YYYY-MM-DD |
11.3 What the outcome allows
Example: The delivery party may start build of WP-02. Go-live is not
permitted until C1 and C2 are verified at the pre-production review
(review point R3 in AC-02). Disputes about any rating follow the
escalation route in the board charter, section 10.
12. Follow-up and re-assessment
| Item | Rule |
|---|
| Condition tracking | Lead assessor reviews open conditions [every two weeks] and reports overdue items to the board secretary |
| Next review point | Example: Pre-production review R3, planned YYYY-MM-DD; reuse this checklist and add build evidence |
| Re-assessment triggers | Material design change, new external interface, change of hosting, new category of personal data, failed condition |
| Dispensation review | At each board meeting until expiry; renewal requires a new risk assessment |
| Post-implementation | Realised architecture and drift checked in the post-implementation review (project/post-implementation-review) |
| Periodic health | After go-live, the solution enters the periodic health check cycle (architecture/architecture-health-check) |
Lessons about the assessment process itself (late evidence, unclear
checks, missing baseline items) go to the board secretary for the
annual review of the charter.
13. Glossary and references
13.1 Glossary
| Term | Meaning in this document |
|---|
| Compliance assessment | A recorded review of whether a project's design or build conforms to the approved architecture it is bound by |
| Baseline (for assessment) | The set of approved documents and versions the project is measured against |
| Architecture Contract | The agreement between the architecture function and a delivery party on what is built and how conformance is checked |
| Check | A closed question, tied to a baseline item, answered from evidence |
| Critical check | A check whose failure prevents a positive outcome unless a dispensation is granted |
| Condition | A dated requirement the project must meet for the outcome to stand |
| Dispensation | A time-limited, risk-accepted permission to depart from a principle or standard |
| Roll-up | The published rules that turn many check ratings into one overall rating |
| Review point | A planned moment in delivery when an assessment takes place |
| [Term] | [Meaning] |
13.2 References
| ID | Reference | Version / date |
|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group, catalogue C220), incorporating Technical Corrigendum 1 (U254, 15 May 2025) | 19 May 2025 |
| REF-02 | Architecture Board Charter (architecture/architecture-governance-charter) | [x.y] |
| REF-03 | Architecture Contract (architecture/architecture-contract) | [x.y] |
| REF-04 | Architecture Requirements Specification (architecture/architecture-requirements-specification) | [x.y] |
| REF-05 | Architecture Definition Document (architecture/architecture-definition-document) | [x.y] |
| REF-06 | Architecture Review Request (architecture/architecture-review-request) | [x.y] |
| REF-07 | Architecture Change Request, for changes the assessment exposes (architecture/architecture-change-request) | [x.y] |
| REF-08 | Technology radar (architecture/tech-radar) | [Date] |
| REF-09 | Tech debt register (architecture/tech-debt-register) | [Date] |
Standard and licence note
Structure aligned with The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1),
published by The Open Group: Architecture Compliance and the Compliance
Assessment used during Phase G (Implementation Governance) of the
Architecture Development Method, under an Architecture Contract and the
Architecture Board. TOGAF and ArchiMate are registered trademarks of The
Open Group. This template uses only the names of phases and deliverables;
all text is original, including the check questions, the six-point rating
scale, the roll-up rules and the severity scale, and no definitions,
tables, checklists or other text from the standard are reproduced. Check
the current edition at opengroup.org and obtain the standard for its full
guidance. Template licence: MIT.