TOGAF

Introduction: TOGAF as an Enterprise Architecture Discipline

The Open Group Architecture Framework (TOGAF) is the world's most widely adopted enterprise architecture (EA) framework, used by more than 80 per cent of the Global 50 and a large majority of the Forbes Global 200. Unlike a security or privacy standard, TOGAF is not a control catalogue that dictates 'thou shalt encrypt'; it is a method and a common language for planning, designing, governing and realising the target architecture of an enterprise across its business, data, application and technology dimensions. It answers the recurring executive question: 'How do we make sure our technology investments actually deliver the business outcomes we intend, in a repeatable and governed way?'

For CyberSigma clients, TOGAF matters because architecture is where security, privacy and resilience are either designed-in or bolted-on. A firm that treats PCI DSS, DPDP, ISO 27001 or CERT-In obligations as afterthoughts to an ungoverned architecture pays for it repeatedly in rework, audit findings and breach exposure. TOGAF provides the governance spine onto which security and compliance requirements can be hung as architecture principles, constraints and building blocks. This guide is written from the perspective of an auditor assessing whether an organisation's enterprise architecture capability is real, mature and delivering value, rather than a shelf-ware certificate. It maps every part of the framework so that an assessment team can verify conformance point by point and gather defensible evidence.

The current baseline of the standard is TOGAF 10 (the TOGAF Standard, 10th Edition), released by The Open Group in April 2022. TOGAF 10 restructured the material into a compact set of Fundamental Content documents plus a modular library of Series Guides, replacing the older single-volume TOGAF 9.2 structure. Where this guide references chapters or phases it uses TOGAF 10 terminology, and notes 9.2 equivalents where organisations are mid-migration.

What is TOGAF

TOGAF is a framework for developing and governing enterprise architecture. Its beating heart is the Architecture Development Method (ADM), a step-by-step, iterative cycle for producing architectures. Around the ADM sit a set of supporting components: the ADM Techniques, Applying the ADM guidance, Architecture Content (the metamodel and deliverables), Enterprise Architecture Capability and Governance, and the Architecture Development Method itself as the core process. In TOGAF 10 these are the 'Fundamental Content' pieces, supplemented by the TOGAF Library — a body of Series Guides covering agile, security, digital, business architecture and reference models such as the TOGAF Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM).

An enterprise architecture in TOGAF is expressed across four architecture domains: Business Architecture, Data Architecture, Application Architecture and Technology Architecture (the latter three collectively termed Information Systems Architectures, with Data and Application often grouped). The ADM drives a project through phases that develop each domain in turn, manage the transition from a Baseline (as-is) to a Target (to-be) architecture, and govern implementation and change. Cross-cutting these are the Enterprise Continuum (a way of classifying and reusing architecture and solution assets from generic Foundation Architectures through to Organisation-Specific Architectures) and the Architecture Repository that physically stores them.

TOGAF is deliberately method-agnostic about tools and technology choices. It does not prescribe a particular modelling notation (though it is frequently used alongside ArchiMate, also from The Open Group), a particular vendor stack, or a particular delivery methodology (it is compatible with waterfall, agile and product-oriented delivery). Its value is in the discipline it imposes: every architecture change should trace to a business driver, be governed by principles, pass through an Architecture Board, be captured in an Architecture Definition Document and Architecture Requirements Specification, and be controlled by an Architecture Contract with the implementers.

Key TOGAF concepts an assessor must recognise

• Architecture Development Method (ADM): the eight phases (A to H) plus the Preliminary Phase and a central Requirements Management activity.
• Architecture Vision, Architecture Definition Document (ADD) and Architecture Requirements Specification (ARS): the principal work products.
• Building Blocks: Architecture Building Blocks (ABBs) describe required capability; Solution Building Blocks (SBBs) are the implementable components.
• Enterprise Continuum and Architecture Repository: classification and storage of reusable assets.
• Architecture Governance and the Architecture Board: the decision and control mechanism.
• Architecture Contract, Architecture Compliance review and Change Management: the mechanisms that keep delivery aligned to the architecture.
• Stakeholder Management, Architecture Views and Viewpoints: ensuring the architecture communicates to each audience.
• Gap Analysis, Migration Planning and Transition Architectures: how an enterprise moves from baseline to target.

Who Must Comply (and Who Should Adopt)

TOGAF is a voluntary framework — there is no legal mandate to 'comply' as there is with DPDP or PCI DSS. Compliance in a TOGAF context means (a) an organisation choosing to align its EA practice with the framework, and (b) individual projects being assessed against the organisation's architecture through the TOGAF Architecture Compliance process. However, many organisations effectively require TOGAF alignment through procurement, governance mandates or sector expectations. The following table clarifies who is in scope.

Levels of conformance

The Open Group defines two conformance postures for products and services: 'TOGAF Conformant' and 'TOGAF Certified'. For internal practice, an organisation typically self-assesses whether its EA capability follows the ADM and produces the mandated deliverables. Individuals are certified at TOGAF Foundation (knowledge) and TOGAF Practitioner (applied) levels under the current certification programme, with Enterprise Architecture Practitioner and Team credentials in the modular certification portfolio.

Structure of TOGAF

TOGAF 10 is organised as Fundamental Content plus the TOGAF Library (Series Guides). The Fundamental Content is the enduring core; the Library is the extensible, guidance layer. The table below sets out the principal structural components an assessor will encounter, mapped to their role in an EA capability.

The four architecture domains

Master Assessment Checklist

This is the core of the guide. It enumerates every phase of the ADM, every supporting technique, every governance function and every mandated deliverable, with 'What to verify' and 'Typical evidence' columns so that an assessment team can walk the entire framework without gaps. An organisation claiming TOGAF alignment must be able to satisfy each row for the architectures it produces. Where a row is 'not applicable', that decision must itself be documented as an architecture governance record.

Preliminary Phase — Establishing the Architecture Capability

Phase A — Architecture Vision

Phase B — Business Architecture

Phase C — Information Systems Architectures (Data)

Phase C — Information Systems Architectures (Application)

Phase D — Technology Architecture

Phase E — Opportunities and Solutions

Phase F — Migration Planning

Phase G — Implementation Governance

Phase H — Architecture Change Management

Requirements Management (central to all phases)

ADM Techniques

Architecture Content and Metamodel

Enterprise Continuum and Architecture Repository

Architecture Governance and the Architecture Board

Security and risk integration (TOGAF Security Series Guide)

Scoping

Scoping an architecture engagement is a first-class TOGAF activity, addressed principally in the Applying the ADM guidance. A frequent cause of failed EA programmes is boiling the ocean — attempting to model the entire enterprise at full depth. TOGAF instead advises scoping along four dimensions so that each iteration is achievable and delivers value.

An assessor should confirm that scope is explicitly declared in the Statement of Architecture Work, that it aligns with the sponsor's mandate, and that out-of-scope areas are recorded so downstream teams understand the boundaries. Iteration is expected: TOGAF supports architecture at Strategy, Portfolio, Project and Solution Delivery levels, each with its own appropriate depth.

Implementation Approach

Adopting TOGAF is itself an enterprise change and should be run as a phased programme. The phases below give a pragmatic, auditor-friendly rollout. Each phase lists the key activities and the deliverables that evidence completion.

Phase 1 — Establish the Architecture Capability

Activities: secure executive sponsorship; define the EA operating model and organisation; tailor TOGAF to the enterprise (which phases, techniques and deliverables apply); select an EA tool and stand up the Architecture Repository; ratify an initial set of Architecture Principles.

Deliverables: EA charter and operating model; tailored ADM/method; Architecture Principles catalogue; Architecture Board terms of reference; configured repository and metamodel.

Phase 2 — Pilot on a Bounded Engagement

Activities: choose a high-value, contained business problem; run a full ADM cycle (Phases A-F) at appropriate depth; produce real artefacts; capture lessons learned; refine templates.

Deliverables: Architecture Vision and Statement of Architecture Work; populated ADD and ARS; gap analyses; Architecture Roadmap and Implementation and Migration Plan for the pilot.

Phase 3 — Institutionalise Governance

Activities: operationalise the Architecture Board cadence; embed Architecture Compliance reviews into the delivery lifecycle and portfolio gates; introduce Architecture Contracts; establish the waiver/dispensation process; connect EA governance to corporate, IT and business governance.

Deliverables: governance framework and RACI; compliance review checklist; contract templates; governance log; integration points with PMO and change advisory boards.

Phase 4 — Scale Across the Enterprise

Activities: extend architecture coverage to further segments and capabilities; build reusable building blocks and reference architectures; populate the Standards Information Base; introduce iteration across strategy, portfolio and project levels.

Deliverables: enterprise capability map; reference architectures and building block library; Standards Information Base; multi-level Architecture Roadmap.

Phase 5 — Measure, Optimise and Mature

Activities: measure EA value delivery and stakeholder satisfaction; run architecture maturity assessments; feed change management (Phase H) with monitoring; continuously improve principles, metamodel and governance.

Deliverables: EA KPI dashboard; maturity assessment reports; continuous improvement backlog; refreshed principles and repository.

Maturity / Capability Model

TOGAF references architecture maturity through capability-based models; The Open Group's Architecture Capability guidance and the widely used Architecture Capability Maturity Model (ACMM, originating from the US Department of Commerce and referenced in TOGAF) provide a five/six-level scale. The table below expresses the practical levels an assessor uses to grade an EA function.

Assessment and Audit Approach

A TOGAF assessment combines an Architecture Compliance review (of specific architectures/projects) with a capability review (of the EA function itself). The following ordered steps describe a defensible audit.

1. Confirm scope and objectives with the sponsor: is this a capability maturity review, an architecture compliance review of a project, or both?
2. Request and study the tailored TOGAF method and Architecture Principles to establish the organisation's own baseline of expectations.
3. Review the Architecture Repository structure and sample its contents (ADD, ARS, roadmaps, governance log).
4. Walk the ADM per engagement: verify each phase's inputs, steps and outputs against the master checklist above.
5. Assess Requirements Management: test traceability from a business driver through requirements to building blocks and delivered solution.
6. Evaluate governance: review Architecture Board minutes, compliance reviews, waivers and Architecture Contracts for a sample of projects.
7. Assess security and risk integration across the domains and confirm alignment with the organisation's control frameworks.
8. Grade capability maturity against the level model, with evidence for each level claimed.
9. Interview stakeholders (sponsors, architects, delivery leads) to corroborate documentary evidence and test whether the practice is real, not shelf-ware.
10. Produce findings graded (Irrelevant / Consistent / Compliant / Conformant / Fully Conformant or Non-Conformant), with prioritised recommendations and a remediation roadmap.

Evidence Request List

The following categorised list is what an assessor should request in advance. It doubles as a self-preparation checklist for the assessed organisation.

Capability and governance

• EA charter, operating model and organisation chart.
• Tailored TOGAF ADM / method documentation.
• Architecture Principles catalogue with rationale and implications.
• Architecture Board terms of reference, membership and recent minutes.
• Architecture governance framework and RACI.
• Architecture Capability maturity self-assessment (if any).

Method and deliverables

• Sample Request for Architecture Work and Statement of Architecture Work.
• Architecture Vision documents for representative engagements.
• Architecture Definition Documents (ADD) covering business, data, application, technology.
• Architecture Requirements Specifications (ARS) with requirement IDs.
• Gap analysis matrices per domain.
• Architecture Roadmaps and Implementation and Migration Plans.
• Transition Architecture definitions.

Governance and delivery control

• Architecture Contracts for in-flight projects.
• Architecture Compliance review reports.
• Waiver / dispensation / deviation register.
• Architecture Governance Log and change log (Phase H).
• Requirements traceability matrices.

Repository, standards and reuse

• Architecture Repository structure and inventory.
• Standards Information Base (SIB).
• Building block register (ABBs and SBBs) and reference architectures.
• Enterprise Continuum classification of assets.
• Security and risk views, control mappings and risk registers.

Roles and Responsibilities

KPIs to Track

• Percentage of change initiatives passing through an Architecture Compliance review before funding.
• Architecture compliance conformance rate (share of projects graded Conformant or better).
• Number and ageing of open waivers/dispensations (lower and younger is better).
• Requirements traceability coverage (share of delivered features traceable to a governed requirement).
• Reuse rate of Architecture and Solution Building Blocks across projects.
• Reduction in application/technology portfolio redundancy (duplicate capabilities retired).
• Time-to-decision at the Architecture Board (governance responsiveness).
• EA maturity level trend over successive assessments.
• Stakeholder satisfaction with architecture services.
• Realised business value / benefits attributable to architecture-led change.
• Percentage of security requirements integrated from Phase A rather than retrofitted.
• Standards Information Base coverage and currency (share of technology governed by an approved standard).

Readiness Checklist

• Executive sponsorship for enterprise architecture is secured and documented.
• TOGAF has been tailored to the enterprise and the method is published.
• Architecture Principles are ratified and actively applied to decisions.
• An Architecture Board is operating with clear terms of reference.
• An Architecture Repository is stood up and structured (landscape, SIB, reference library, governance log, requirements).
• Templates for the ADD, ARS, roadmap and Architecture Contract exist and are in use.
• Requirements Management provides end-to-end traceability.
• Architecture Compliance reviews are embedded in the delivery lifecycle.
• A waiver / dispensation process exists and is time-bound.
• Security and risk are integrated from Phase A across all four domains.
• Building blocks and reference assets are being reused via the Enterprise Continuum.
• EA KPIs are defined, collected and reported to leadership.
• An architecture maturity assessment has been performed and a baseline established.
• Phase H change management monitors business and technology change into the architecture.

Common Gaps

• Shelf-ware architecture: impressive documents that no delivery team actually follows because governance has no teeth.
• Big-bang scoping: attempting to model the whole enterprise at full depth, producing nothing usable before momentum is lost.
• Missing Requirements Management: no traceability from business drivers to building blocks, so architecture cannot be defended or reused.
• Weak or absent Architecture Board: decisions made outside governance, waivers granted informally and never expiring.
• Security bolted on late: security architecture retrofitted in Phase G rather than integrated from Phase A, causing rework and gaps.
• No Enterprise Continuum discipline: assets not classified or reused, so every project reinvents the same building blocks.
• Principles that are slogans: Architecture Principles lacking rationale and implications, so they cannot be applied to real decisions.
• Repository neglect: baselines not updated after change (Phase H skipped), so the 'as-is' drifts from reality.
• Confusing ADM with a waterfall project plan: treating phases as one-off gates instead of iterating across strategy, portfolio and project levels.
• No maturity measurement: the EA function cannot demonstrate improvement or value, undermining continued sponsorship.
• Over-tooling before capability: buying an expensive EA tool before establishing method, principles and governance.

TOGAF Mapped to Other Frameworks

Frequently asked questions

Need help with TOGAF?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.