What is a security architecture framework?

Ask for a list of security architecture frameworks and you get SABSA beside ISO 27001, TOGAF beside the Essential Eight, and the NIST Cybersecurity Framework beside NIST's zero trust architecture. Those are different kinds of document doing different jobs, and most of the work of choosing a framework is telling them apart.

The Open Group's TOGAF Standard gives the definition to start from. An architecture framework is "a foundational structure, or set of structures, which can be used for developing a broad range of different architectures", and it should include a method for describing a baseline state, a target state, and "planning the evolution from baseline to target states". A framework exists to answer three questions: what runs today, what the organisation has decided it will have, and how it gets from one to the other.

Four kinds of document answer them, each in part. Methods say how to decide: SABSA, NIST SP 800-160 and The Open Group's O-ESA. An enterprise architecture method gives security a place to work inside: TOGAF 10, with its security guide G152. A schema classifies what you already hold: Zachman. Reference architectures give a tested shape for one recurring problem: NIST SP 800-207, the Australian Signals Directorate's Foundations for modern defensible architecture, and Open Security Architecture's patterns. Control catalogues such as ISO/IEC 27001:2022 Annex A, NIST SP 800-53 and the Essential Eight sit under all four. They state what must be true and ask for an architecture without saying how to design one.

Why a security architecture framework matters

A framework gives a security architecture team three things it cannot easily make for itself.

The first is one vocabulary. TOGAF says tailoring a framework "should establish a set of tools and a common vocabulary", and teams underrate that part. Without it, one architect's domain is another's zone, a principle means a policy statement to the GRC team and a design rule to the engineers, and no two design documents can be compared.

The second is a layered structure with a trace running through it, from what the business needs down to the control that delivers it. Four publishers draw the same shape. SABSA opens with a Contextual layer and works down through Conceptual, Logical and Physical, and TOGAF 10's Architecture Abstraction uses the same four names. ASD's modern defensible architecture puts principles and strategic guidance at the top, its ten Foundations in the middle, and controls, including the ISM and the Essential Eight, underneath. NIST SP 800-53 ties a system's security architecture (control PL-8) to the organisation-wide enterprise architecture (control PM-7). ASD gives the reason for the layering: traceability means each security control "can be justified by clearly traced origins in business objectives and threat context".

The names line up by scope. Only the names are shared; each publisher fills the levels its own way. All four run in the same direction, from intent down to controls, with a line a reader can follow back up.

The third is a tested method for moving from the current state to a target. TOGAF's Architecture Development Method (the ADM) runs "Develop Baseline", "Develop Target" and "Perform Gap Analysis" in its business, information systems and technology phases, then consolidates the gaps into an Architecture Roadmap in Phase E. A team that writes its own method has to invent all of that.

Five readers ask for a framework, usually without using the word. An enterprise architecture function running TOGAF asks where security sits in its method. An ISO/IEC 27001 auditor reads Annex A 8.27, which asks for secure system architecture and engineering principles to be established and applied. ASD's Foundations ask Australian organisations for layered architecture and traceability. A system under NIST SP 800-53 answers control PL-8, which wants to know "how the architectures are integrated into and support the enterprise architecture". And a newly appointed head of security architecture has to pick a framework and defend the pick to the other four.

Without a framework, each architect invents layers and nothing records why a control exists. With the wrong one the outcome is often worse: the framework the team trained in, adopted whole and abandoned by the third project.

How security architecture frameworks work, step by step

What every architecture framework contains

TOGAF's definition names the parts. Building blocks and a common vocabulary to describe things in. A way to describe the baseline, meaning what runs today, and a way to describe the target, meaning what the organisation has decided it will have. A plan for the evolution between them: the gap, the roadmap and the transition. And tailoring, because a framework is "typically tailored to meet the specific needs of the organization", so nobody is expected to adopt one whole.

The international standard for architecture descriptions draws a line that matters for choosing. ISO/IEC/IEEE 42010:2022 sets requirements for how an architecture description is structured, and its published scope says it does not specify the processes or methods by which one is created. A framework for describing and a method for deciding are different tools, and several frameworks below are only one of the two.

The security architecture frameworks in use today

SABSA is, in The SABSA Institute's words, "a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives". It has evolved since 1995, its distinguishing claim is two-way traceability between business objectives and security decisions, and it is vendor-neutral and "free-use in perpetuity". The SABSA framework page explains its layers, matrix and attribute profiling; this guide only compares it.

TOGAF 10 is The Open Group's enterprise architecture standard, launched on 25 April 2022 and free for non-commercial use. Security sits inside it as domain guidance, carried by the Series Guide G152, Integrating Risk and Security within a TOGAF Enterprise Architecture, which The Open Group Security Forum wrote with The SABSA Institute (first published January 2016, current edition April 2022). TOGAF says it is "feasible to select particular documents for adoption while excluding others", so a security team can take the ADM without the rest.

SABSA against TOGAF comes down to this: SABSA is a security method that traces each control back to business attributes, and TOGAF is an enterprise architecture method whose security guidance sits in G152. A team that runs TOGAF uses SABSA's attributes inside the ADM rather than choosing. Their 2011 integration paper, W117, placed SABSA's Business Attribute Profile at the Goal level of TOGAF's content metamodel, according to InfoQ's summary.

The Zachman Framework is a schema, and its author says so in capitals: "The Zachman Framework IS NOT a methodology". It crosses six questions (What, How, When, Who, Where, Why) with six transformations, from Identification to Instantiation, and gives every artefact a cell. Version 3.0 dates from 2011. A security team uses it to find which questions its artefacts answer and which are empty; it never says what to do next.

NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems (November 2022), is the method for one system. Its System Architecture Definition process generates alternatives, selects one, expresses it in consistent views and models, and expects the security aspects to trace back to stakeholder and system requirements. Appendix E holds 30 principles for trustworthy secure design.

O-ESA, The Open Group's Open Enterprise Security Architecture (September 2011), updated the Network Applications Consortium's 2004 template. It splits the work into governance, technology architecture and operations, and defines policy-driven security architecture as a policy framework, a technical framework that makes and enforces policy decisions at runtime, and an operations framework that checks the deployed technology conforms. Its policy template came from ISO/IEC 27002:2005, so it is the cleanest staffing model on this list and an older catalogue.

NIST SP 800-207, Zero Trust Architecture (August 2020), is a reference architecture. It calls zero trust "a set of guiding principles for workflow, system design and operations", lists seven tenets, and names three core logical components: the policy engine, "responsible for the ultimate decision to grant access to a resource for a given subject", the policy administrator and the policy enforcement point. NIST SP 1800-35 (June 2025) documents 19 example implementations built with 24 industry partners.

ASD's Foundations for modern defensible architecture (MDA), final in October 2025 and co-sealed by eight international partners, is "written for technical security architects and enterprise architects". It joins layered architecture and traceability, zero trust principles and secure-by-design practice in ten Foundations, from centrally managed enterprise identities to continuous and actionable monitoring. They "are not in prioritised order": ASD asks each organisation to build an implementation roadmap that puts first the Foundations protecting its critical business capabilities and data.

Open Security Architecture (OSA) publishes security patterns and control mappings under CC BY-SA 4.0. It has run since 2008, was rebuilt in February 2026, and bases its controls catalogue on NIST SP 800-53 Rev. 5. It is a place to start a pattern library rather than a method.

The Open Group also publishes two principle sets, G192 Axioms for the Practice of Security Architecture (July 2019) and the standard C246 Security Principles for Architecture (July 2024). Vendor references such as the AWS Well-Architected Security Pillar and Microsoft's Cybersecurity Reference Architectures describe one vendor's platform; AWS says its pillar "doesn't provide implementation details or architectural patterns".

What each framework supplies, and what it leaves to another

Set the frameworks against the parts TOGAF says a framework needs, and the gaps line up. Zachman supplies a vocabulary and, by its own text, no method. TOGAF supplies the method, the baseline-to-target planning and the governance machinery, and carries security through a guide. SABSA supplies a method, layers and a governance framework of its own. The reference architectures supply principles, designs and a migration path, and MDA leaves governance outside on purpose: ASD renamed its ninth Foundation from "Comprehensive assurance and governance" to "Comprehensive validation and assurance" so that governance practices could "sit outside the MDA Foundations".

That is why the publishers point at each other. TOGAF's Preliminary Phase includes a step to "Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)", and its Architecture Repository holds "reference architectures, models, and patterns that have been accepted for use within the enterprise". The SABSA Institute lists TOGAF and Zachman among the frameworks SABSA integrates with. A stack of two or three frameworks, each doing the job it was written for, is the normal case.

Choose by the question you need answered

Each framework answers one question better than the rest, so start from the question. If nobody in the organisation is asking it yet, you do not need that framework yet.

Two questions come first in most organisations: how to engineer the system being built now, and what shape access should take. NIST SP 800-160 answers the first. One reference architecture answers the second: SP 800-207, or MDA Foundations 1 to 3 (centrally managed enterprise identities, high confidence authentication, contextual authorisation). SABSA earns its place the day someone asks why a control exists and nobody can answer.

Seven steps from a list of frameworks to a working practice

Choosing frameworks is the architect's own job applied to the practice: capture what runs, decide the target, count the gap, and run it as a roadmap through the people who decide.

Step 1: capture the practice as it runs

Mark every framework anyone names as used (it shapes real decisions), named only (it changes nothing) or audited (someone outside tests it). Count what the practice produces: current design records, published patterns, security seats in the forums that approve designs. This is TOGAF's baseline, taken of the practice itself.

Step 2: write the questions down, with an asker for each

One line per question, and who asks it: the auditor, the architecture board, a regulator, a project team. This list is what you defend the choice with later.

Step 3: pick a host process and a method

Where an enterprise architecture function already runs TOGAF, the ADM is the host and security works inside it, with G152 for the join. Then pick the method that answers "why does this control exist?", usually SABSA's business attributes, and the one that engineers each system, usually NIST SP 800-160.

Step 4: adopt reference architectures, and version them

Turn the shapes you need from SP 800-207, the MDA Foundations or OSA into patterns of your own, each with a version number a design can cite. TOGAF's Architecture Repository exists to hold them.

Step 5: map the patterns to the catalogues auditors read

Each pattern names the controls it implements in ISO/IEC 27001:2022 Annex A, the Essential Eight or NIST SP 800-53. This is the bottom layer of ASD's MDA figure, and it is how an auditor reading control 8.27 finds the architecture.

Step 6: record the stack as the target, and count the gap

Write the chosen frameworks down as one decision with an owner per layer, in the forum that already governs architecture. Then count the distance from the step 1 capture, the way TOGAF's Phases B to D and the Current and Target Profiles of NIST CSF 2.0 both do.

Step 7: run the gap as a roadmap and move the decision rights

Sequence the gap with an owner, dates and funding on each line, as TOGAF's Phases E and F do. Then change who approves a design, publishes a pattern and accepts an exception: TOGAF puts those decisions in the Architecture Board and the compliance review, and CSF 2.0's GV.RR-02 asks for roles, responsibilities and authorities to be established and enforced. Review the stack yearly.

A worked example: an Australian university chooses and combines its frameworks

An Australian university has 3,400 staff and 31,000 students. Its enterprise architecture team, led by Sofia Lindqvist, runs TOGAF 10 and keeps an ArchiMate repository of 140 applications. The 2024 security strategy names SABSA and zero trust, but the one SABSA attribute profile was drafted for one project and abandoned, and zero trust is a single slide.

Two things arrive together. In May 2026 internal audit raises finding IA-2026-07 against ISO/IEC 27001:2022 Annex A 8.27: secure architecture principles are not established or applied to new systems. And the student records system is moving to a cloud-hosted platform, due live in February 2028. Leila Haddad, appointed head of security architecture in March 2026, has to answer both with one decision.

The current state, captured on 14 August 2026

Leila captures the practice as it runs, not as the strategy describes it. One framework is used: TOGAF 10. Two are named only: SABSA and zero trust. Two are audited: ISO/IEC 27001:2022, tested by the internal audit of the information security management system, and the Essential Eight, assessed each year. Of the 140 applications, 31 hold student, staff or research data, and 9 of those 31 have a current security design record. No security patterns are published. The Architecture Board meets monthly with no security seat, and security reviews a design after the board has approved it.

She then runs the one check Zachman is good for. Sorting the repository's 111 security artefacts by the question each answers gives What 31, How 57, Where 12, Who 8, When 3 and Why 0. Plenty of documents say what is deployed and how it is configured. None says why a control exists, which is the audit finding in another form.

The target state the Architecture Board recorded

On 24 September 2026 the Architecture Board records the stack in minute AB-2026-09, one job and one owner per layer. TOGAF 10's ADM stays the host, owned by Sofia, with security as a viewpoint in Phases A to D and a reviewer in Phase G, and G152 for the join. SABSA supplies the traceability through six business attributes, each with a measure and an owner. NIST SP 800-160 governs every new data-holding system, owned by the solution architects. For access, the university adopts MDA Foundations 1 to 3 and SP 800-207's policy engine and enforcement point, starts from OSA, and commits to four patterns: PAT-01 staff and student identity, PAT-02 access to student records, PAT-03 research data enclave and PAT-04 partner data exchange. Annex A and the Essential Eight stay the audit face, owned by the GRC lead, Kieran Walsh. Zachman becomes a yearly check of the Why column.

Most of the attribute owners sit outside IT.

One trace shows the layers working together. Student record integrity is measured as "every change to a student's results is attributable to a named person and approved by a second". It produces the principle "decide access centrally, enforce it at every request". PAT-02 implements the principle, built from MDA Foundation 3, contextual authorisation, and SP 800-207's policy engine and enforcement point. PAT-02 names its controls: the Essential Eight's multi-factor authentication and restrict administrative privileges, Annex A 8.27 for the principle record, and 5.15 and 8.3 for the access rule. The student records platform's design record cites PAT-02, and that citation is the evidence.

The gap, counted in four lines

Leila states the gap in the practice's own units, so the board can watch it close. Security seats on the Architecture Board go from 0 to 1. Attributes with a measure and an owner go from 0 to 6. Published patterns go from 0 to 4. Data-holding applications with a current design record go from 9 to 31, which is 22 records to write.

The roadmap, with an owner and funding on every line

Four lines cover six quarters. R1, the board charter and the Phase G review gate, needs no new funding. R2, the attribute profile, runs on team time. R3 builds the four patterns inside the student records program's budget, PAT-02 first because the student records design needs it: published by the end of Q2 2027, the design through Phase G in Q3 2027, go-live in February 2028. That chain is the critical path. R4 writes the 22 missing design records, most exposed first, and needs a contract architect whose funding is decided at the November 2026 budget round.

Who decides what now

The adoption adds no committee. Graham Petrie, the CIO, gives Leila a vote on the existing monthly Architecture Board, which now decides which patterns are published and the order of R1 to R4. Each data-holding design is signed by its solution architect and the security architect together, in the Phase G compliance review TOGAF already describes. An exception against an attribute is accepted by that attribute's owner, with an expiry date. Before, the board approved designs with no security voice, nobody published patterns, and a project manager accepted exceptions.

The board reads three measures each quarter: the share of new data-holding designs that cite a pattern, exceptions past their expiry date, and design records written against the 22.

The audit walk in June 2027

Internal audit re-tests IA-2026-07 at the end of June 2027, days after PAT-02 is published, and walks Annex A 8.27 in three moves. Principles established: the attribute profile with its six named owners, and PAT-02, which carries the access principle. Principles applied: the student records design record, which cites PAT-02 on its way to the Phase G review. Governed: minute AB-2026-09 and the Phase G review records since. Annex A 5.2, information security roles and responsibilities, is answered by the board seat and the six attribute owners. Every answer is a record that already existed for its own reason.

Common mistakes

The eight mistakes below share one root: a framework adopted whole, like a product, instead of chosen as the answer to a question. Here is the university's practice drawn both ways.

1. Calling a control catalogue an architecture framework. ISO/IEC 27001 Annex A, NIST SP 800-53, NIST CSF 2.0 and the Essential Eight say what must be true, and ASD's MDA draws controls as the layer under the architecture. Several pages ranking for this term still list a catalogue as a framework, and one links the 2018 edition of the NIST Cybersecurity Framework. Keep the catalogues as the audit face and choose a method for design.
2. Adopting a framework whole. The symptom is a SABSA matrix filled in cell by cell for every project. TOGAF's own Preliminary Phase asks you to tailor it and any other framework you select. Take the parts that answer your questions, and write down what you left out.
3. Running security architecture beside the enterprise architecture method, with its own repository, vocabulary and review. Designs then get reviewed twice or not at all. Use one repository and one board, with G152 for the join.
4. Using Zachman as a method. Its author says it is not one. Run it once a year to find the empty columns, and use a method to fill them.
5. Adopting a reference architecture with no current state, gap or roadmap. SP 800-207 says the move to zero trust "cannot simply be accomplished with a wholesale replacement of technology", and ASD asks for roadmaps that put the Foundations in your own order. Run steps 1, 6 and 7 for zero trust as for anything else.
6. Choosing the framework the architect trained in instead of the one the organisation's questions call for. Attribute profiles nobody asked for get written while the auditor's question about 8.27 waits. Write the question list first.
7. Keeping a stack nobody owns. The choice lives in one person's head and leaves with them. Record it as a decision with an owner per layer and a yearly review, in the forum that already governs architecture.
8. Citing superseded editions. TOGAF 10, NIST SP 800-160 Vol. 1 Rev. 1, ISO/IEC 27001:2022, NIST CSF 2.0 and the October 2025 final of the MDA Foundations are current.

Security architecture frameworks compared with their neighbours

The word framework covers at least six kinds of document in this field. Two questions separate them: does the document say what must be true, or how to design and describe; and does it work on one system or the whole organisation?

ArchiMate 3.2 (October 2022) calls itself "an open and independent modeling language for Enterprise Architecture", and The SABSA Institute publishes a paper on modelling SABSA in it. For the practice the frameworks structure, read What is security architecture?; for that practice across a whole organisation, read What is enterprise security architecture?.

Standards and references

NIST, ASD, Open Security Architecture and The SABSA Institute's summary are free, and TOGAF 10 is free for non-commercial use. G152, C246 and the online TOGAF text sit behind an Open Group sign-in, and ISO sells its standards. This guide quotes TOGAF from the publisher's preview of the printed edition, makes no claim about G152's contents beyond its published record, and summarises ISO controls from their titles.

The TOGAF Standard, 10th Edition (The Open Group, April 2022). Introduction and Core Concepts, page 5, for the definition of an architecture framework, and section 3.7 for Architecture Abstraction. The Architecture Development Method volume for the baseline, target, gap and roadmap steps in Phases B to F and the tailoring step 2.3.5. Content, Capability, and Governance for the Architecture Board and compliance reviews.

G152 (The Open Group with The SABSA Institute, current edition April 2022). The join between the two methods, 44 pages, behind a sign-in.

The SABSA Institute, SABSA Executive Summary, and Zachman International, About the Zachman Framework. Each method's own statement of what it is, and in Zachman's case what it is not.

NIST SP 800-160 Vol. 1 Rev. 1 (November 2022), SP 800-207 (August 2020) and SP 1800-35 (June 2025). System Architecture Definition and Appendix E; the zero trust tenets, logical components and section 7 on migrating; worked implementations.

ASD, Foundations for modern defensible architecture (October 2025). The key concepts for traceability and Figure 1's layers, and the Foundations list. Its companion, Investing in modern defensible architecture, covers the investment road map.

NIST SP 800-53 Rev. 5 controls PL-8 and PM-7, ISO/IEC 27001:2022 Annex A 8.27, and NIST CSF 2.0 (February 2024). The documents that ask for an architecture, read for what they require of one.

The UK's National Cyber Security Centre offers a shorter alternative to a full framework: five categories of secure design principles (May 2019) and six security architecture anti-patterns, last updated in April 2026.

How Alvor helps

With Alvor, an organisation can keep its framework stack, the patterns it adopts and the review of every design in one system.

The stack itself is written down as a blueprint in Secure by Design: a program design whose sections hold the capabilities with current and target maturity, the operating model with roles, forums and decision rights, the controls and compliance mapping, the metrics, and the roadmap from current state to target state. The reference architectures the organisation adopts become patterns, each with its context, a solution diagram, its trust boundaries, the security controls and threat library entries it addresses, and the standards it was built from, such as NIST SP 800-207 or the MDA Foundations. Every publish takes an immutable version with a change note, and a deprecated pattern can name the pattern that supersedes it. The Pattern Studio's assistant drafts patterns and blueprints for architects, and nothing saves until a person clicks Save.

Each design runs the same governed path: classification and a business impact analysis, the architecture on a canvas, threat modeling on that diagram, control mapping, testing and evidence, and four named sign-offs, each with a written decision. A sign-off approved with conditions raises a linked risk, and every architecture change after baseline is recorded with its reason.

The catalogue layer lives in Compliance. ISO/IEC 27001:2022 and the Essential Eight install with their official text, and you can add any framework in Alvor in its publisher's own structure. Evidence is uploaded or linked once, carries a valid-until date, and is reused across the controls it supports. Patterns and design projects draw on Secure by Design's own security control catalogue (such as NIST SSDF and OWASP ASVS), and the controls auditors test stay in Compliance.

Security Management runs the practice as a program. An organisation can build a maturity framework for its own architecture practice, for example one weighted category per MDA Foundation it adopted, and track current and target maturity over time with the gap between them. Roadmap lines run as programs, projects and tasks with owners, and the board's quarterly measures as KPIs against thresholds you set.

The AI Assistant is bring-your-own-model, including self-hosted models through vLLM or Ollama, and every write it proposes waits on an approval card. Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped. Security Architecture in Alvor shows how the modules fit together.