What is enterprise security architecture?

One NIST glossary entry carries two definitions. At organisation scope, security architecture is "an embedded, integral part of the enterprise architecture that describes the structure and behavior for an enterprise's security processes, information security systems, personnel and organizational sub-units, showing their alignment with the enterprise's mission and strategic plans" (NIST CSRC glossary, carried from SP 800-39 into SP 800-37 Rev. 2). The second is at system scope, the security-relevant views of one system and the trust relationships between its domains, and the same entry says a security architecture "may be expressed at various levels of abstraction and with different scopes".

Enterprise security architecture is that second scope widened, not a second discipline. If the system-level practice is new, read what security architecture is first.

What the wider scope buys is inheritance. A project security architecture decides one system: its domains, its boundaries, the controls at each crossing, the sign-off. An enterprise security architecture decides what every project starts from. The fourth project does not re-derive the authentication design; it picks up the pattern and spends its review on what is new.

The test of the practice is traceability, and two publishers state it the same way. SABSA, the methodology most teams borrow from, develops architectures "at both enterprise and solutions level that traceably support business objectives", and its claim is that the traceability runs both ways. NIST states the same expectation in SP 800-160 Vol. 1 Rev. 1: the security aspects of architecture elements trace back to the requirements they serve. The term came out of corporate research, in a Gartner white paper titled "Incorporating Security into the Enterprise Architecture Process".

Why enterprise security architecture matters

Five events commission this function, and most organisations get more than one at once. Each one arrives with a question, and the five questions have one answer between them.

Per-project design work cannot answer any of the five, however well it is done: a design review protects one system, and it cannot set a pattern once and hold it. The second system to adopt a pattern costs a review, not a design.

The oldest complete open template for this work, the Network Applications Consortium's Enterprise Security Architecture: A Framework and Template for Policy-Driven Security (3 December 2004), splits the function three ways, and that split is still the cleanest way to staff it: deciding, building and running need different people and different rhythms.

Auditors arrive from another direction. In ISO/IEC 27001:2022 the organisational controls are where this function is examined, from Annex A 5.1 on policies to 5.19 to 5.23 on supplier relationships, and clauses 6.1.2 and 6.1.3 want named risk owners, a treatment plan and a Statement of Applicability. An architecture that cannot feed those clauses gets rebuilt by the audit into one that can.

How enterprise security architecture works, step by step

Start with the layer model, because it settles the question that stalls most new practices: the level of detail an artefact belongs at. SABSA organises the work in six layers, five stacked and one running vertically across them all, from why the organisation needs something down to what is actually installed. Different people own each level.

SABSA asks the same six questions at every layer, what, why, how, who, where and when, and six questions across six layers is what produces the SABSA matrix. The vertical layer stops a practice treating monitoring as the last step of a project instead of a standing capability.

The layers say where an artefact belongs; the sequence below says what to produce and in what order. ISACA published the shortest version in 2017: business objectives, then attributes, risks, controls and implementation programmes. The ten steps here keep that order and add the current state, the gap and the governance work.

A business attribute, the artefact step one turns out, is a short, named quality the business needs security to preserve, written so somebody can test whether it holds. One with no measure and no owner loses its first argument with a delivery date.

Capture the current state honestly

You cannot sequence a move you have not measured. Step three is a capture, not a map: one dated page per domain saying what runs there, what is written down about it, and what nobody can account for. CSF 2.0 states the same idea as outcomes in its Current Profile, which records what an organisation "is currently achieving (or attempting to achieve)".

Every figure from here on draws one organisation, the insurer the worked example follows: a 900-person group three weeks into the ninety days it has to say what its architecture will be after an acquisition. Its capture sorts every application by what is written down about it, counts the ones holding claims or policy data separately, and walks the paths between domains. Nobody had approved three of the five.

Date it and sign it, and the same counts taken again in December read as movement.

The target state is a set of decisions, written down and dated

A target state is not a picture of the finished estate. It is four decisions a project can read: the attributes security has to preserve, the domains and what each may assume about the others (a security domain being a part of the estate under one consistent security policy), the patterns a project copies, and the point where each pattern is enforced. CSF 2.0's Target Profile is the same idea stated as outcomes: the ones an organisation "has selected and prioritized", chosen with anticipated changes in mind.

What makes it an architecture is that the four tiers connect. Customer privacy is Ines Duarte's attribute; it picks the customer-facing domain; that domain's pattern is PAT-01; and PAT-01 is enforced at the group API gateway. Read back, that chain is what lets Marion Deis answer a question about one control with the business objective it serves.

Steps five, six and seven fill the tiers in. The 2004 open template publishes eight principles to start from, and builds its technology architecture around a policy decision point, where a decision about access is made, and a policy enforcement point, where it is applied to a request. That pair is the direct ancestor of policy-driven access and zero trust enforcement, and it is the same two boxes under every pattern.

Naming both points for each principle is what makes it checkable by somebody other than its author. PAT-01 puts the decision behind the group API gateway and applies it there, which is step seven of the worked example below.

Name the gap in the estate's own units

The gap is the difference between the two, counted. CSF 2.0 makes it step four of five: "analyze the gaps between the Current and Target Profiles, and create an action plan", and it expects that plan to be prioritised and to live somewhere real, a risk register or a plan of action and milestones.

Count in units the estate already uses: systems, domains, identity providers and paths, not percentages. Each target is arithmetic from the capture, and each line below carries the population its number is drawn from.

Three of the four become roadmap lines: R1 for the second identity provider, R2 for pattern adoption, R4 for the documents. The fourth closes inside the pattern work, because two of the three unapproved paths are shut already and the last becomes the named channel PAT-02 enforces. A gap nobody has counted cannot be funded: the first question in a funding round is how much of it is left.

How the transition is sequenced, funded and governed

The gap is where most of this work stops: the decisions get made, the patterns get published and nothing moves, because nobody sequenced the work, nobody paid for it and no seat could make a project adopt it.

The roadmap: sequence, owners and funding

Order the work by what removes the most exposure first, not by what is easiest to start, and give every line the same four things: what it delivers, who owns it, when it is due, and where the money comes from. The funding half has its own outcome in CSF 2.0: GV.RR-03 expects that "adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies". A line with no budget named against it is a request, not a plan.

Theo Baxter owns R1 and R2, the identity consolidation and the two acquired products; Callum Reid owns R4, the twelve design documents, and R3, the data centre exit. Three of the four come out of money that already exists: the integration budget agreed at the deal, each product's own release, and his team's time. R3 does not, which is why it is drawn differently: its funding waits on the FY28 capital plan set in November, so it carries a decision date as well as a delivery date.

The operating model that carries it

Sequence and funding still need someone holding the right to decide. CSF 2.0 states it in GV.RR-02: "roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced". Established and communicated is the easy half. Enforced means a project cannot proceed past a decision the model says is not its own to make.

Three seats are enough, and this group added no new committee to get them. The board meets quarterly, with Marion Deis reporting as group CISO, and holds the risk position. The architecture forum is the existing monthly technology forum with the patterns on its agenda, Marion Deis, Callum Reid and Theo Baxter in it, and the right to say which patterns are published and in what order R1 to R4 run. The design review meets per design in the delivery path, signed by Marion Deis or her delegate and the engineering lead for the system. One decision belongs to a person: Theo Baxter accepts EX-07 as its named risk owner, outside any forum.

What runs down from those seats is inheritance: a project starts with the risk position, the pattern version published on the day it started, the review it books and any exception it carries. What goes back up is narrow: an exception nobody can close, a pattern two projects could not build to, and the three numbers the board reads each quarter. CSF 2.0 draws both directions, with executives communicating expectations about "risk appetite, accountability, and resources" and progress coming back up.

A worked example: a 900-person insurer after an acquisition

The group above, in full. The acquisition arrived with its own identity provider, its own data centre and two customer-facing products, a quote-and-buy product and a claims tracking portal. Ninety days to say what the combined architecture will be; eighteen months to get there.

Steps 1 and 2, the attributes and the risk position. Four attributes, each with a measure and an owner: claims availability (Hannah Voss, claims operations), a customer can lodge and progress a claim during a regional outage; customer privacy (Ines Duarte, the privacy officer), a customer's file is reachable only by staff with a business reason recorded against it; evidential accuracy (Callum Reid, the claims technology lead), every change to a claim record can be attributed to a person and a time; and accountability to APRA, the Australian prudential regulator (Marion Deis, the group CISO, who owns the register). The risk position names one loss unacceptable, a customer of one brand seeing another brand's claim files, and accepts one with conditions, two identity providers side by side while the acquired one is retired. That second decision is why this example has an exception later.

Step 3, the current state. Three weeks of the ninety go to the capture drawn above, run by Callum Reid's team and signed by Marion Deis on 31 July: 84 applications in four domains, 23 holding claims or policy data, 19 with a current design document and twelve with one that predates the system it describes. Two identity providers. And three paths between the estates that nobody had approved, one a nightly file drop set up during due diligence. Two are closed that month; the third becomes the named channel at step four, because a path nobody approved is either shut or turned into a decision.

Step 4, the target domain model. Three domains before the acquisition, corporate, claims and customer-facing, and the acquired data centre makes four. The target model keeps all four, marks the acquired data centre for exit, and documents one interim trust relationship: the acquired claims system may send claims data into the group claims domain over a named channel, and the group side treats everything arriving on it as untrusted input. That sentence is the architecture, and the rest of the integration argues about how to honour it.

Steps 5 and 6, the principles and the patterns. Eight principles from the 2004 open template, each carrying the attribute it serves and where it is enforced. Enforced policy is the one that does work here: access decisions are made in one place and applied at the edge of each domain, never again inside each product. Then three patterns, PAT-01 customer-facing service, PAT-02 partner data exchange and PAT-03 workforce access, which cover every project on the integration plan. That is the test of whether the set is the right size.

Step 7, the enforcement points. PAT-01 puts the policy decision point behind the group API gateway: one service answers whether this identity may see this policy or this claim, and the gateway applies the answer. PAT-02 enforces at the claims ingestion service, where step four's interim trust relationship is honoured in code instead of in a document, and where evidential accuracy is served: it records who sent each claim event and when, so a change can still be attributed after the data centre is gone. PAT-03 enforces at the group identity provider, which is why single sign-on is most of what the roadmap is about.

Step 8, the gap. Four lines, each a number from the capture measured against the target. Five of the twenty-three systems holding claims or policy data meet the pattern for their kind, so eighteen do not. Nineteen applications hold a current design document against a target of thirty-one, so twelve have to be written. Two identity providers, target one. Three unapproved paths, target zero, two shut already. Marion Deis takes four numbers to the board instead of a diagram, because four numbers can be funded.

Step 9, the roadmap, its funding and the gate. Four lines, each with an owner, a window and a funding source. R1, identity consolidation onto PAT-03, Theo Baxter, four quarters, on the integration budget agreed at the deal. R2, both acquired products onto PAT-01, Theo Baxter, three quarters, inside each product's own release. R4, the twelve design documents, Callum Reid, three quarters, on his team's existing time. R3, the data centre exit, Callum Reid again, starting once R1 and R2 are done and unfunded until the FY28 capital plan is set in November. Claims availability is the attribute that puts R3 last: the exit cannot start until the claims path in PAT-02 has run a full quarter without a gap. The gate opens at the same time, and any project that changes a trust boundary, adds an external integration or handles customer data is reviewed against the patterns before build.

Step 10, the first exception. The acquired quote-and-buy product is the first design through the gate and the first half of R2. It meets PAT-01, and it cannot meet PAT-03, because its staff still authenticate against the acquired identity provider. The review records EX-07: the gap, the owner Theo Baxter, who also owns R1, an expiry set to R1's date, and the compensating step taken this month, moving the acquired provider's administrator accounts into the group privileged access process. The exception opens a risk register entry with the same owner and date, so it cannot expire in silence.

What changed in who decides. No new committee, and three decision rights written down. The monthly technology forum becomes the architecture forum by taking the patterns onto its agenda, and a project keeps the pattern version it started on until its next review, so a change cannot silently fail a design in build. Two signers approve a design. And a residual risk is accepted by its named owner outside any forum, which is why EX-07 carries Theo Baxter's name and a date instead of a committee's.

The measures. Three numbers go to the board each quarter: the share of live projects that passed the gate, the exceptions past their expiry date, and roadmap lines closed against plan. The target for the middle one is zero, and none of the three counts documents produced.

The audit walk. Fourteen months later an ISO 27001 assessor opens Annex A 5.9, inventory of information and other associated assets, and asks how the group knows what it runs and how each thing is protected. The inventory says what exists; the target domain model says which domain each asset sits in and which trust relationship carries data between them. Annex A 5.19 to 5.23 lands on PAT-02; 5.2, roles and responsibilities, on the four attribute owners and on Theo Baxter against EX-07; clauses 6.1.2 and 6.1.3 on the risk entry EX-07 opened and on the Statement of Applicability the patterns feed. Nothing in that walk was written for the assessor.

Common mistakes

Seven failure modes account for most of the enterprise security architecture work that produces nothing.

1. Drawing the estate instead of deciding anything. A map of every system is out of date the week it is finished. Publish the domain model, the principles and the patterns, and let the inventory carry the estate.
2. A target state with no current state behind it. Capture what runs, date it and state the gap as a number, or nobody can sequence the work or fund it.
3. Attributes nobody can test. "Secure" and "modern" cannot be measured, so they cannot be traced to a control or defended in a budget round.
4. A principle with no enforcement point, or a pattern nobody can find. Name where each principle is decided and applied, and keep the pattern where a project starts, with a version and a date on it.
5. A review delivery can route around. The review sits in the delivery path with a named signature, and the exception route has to be fast enough to use.
6. Exceptions that never expire, and roadmap lines with no funding source. An exception with an owner and a date is a decision; an item nobody has paid for moves a quarter every quarter.
7. Measuring documents instead of what changed. Count the projects that adopted a pattern, the exceptions past expiry and the risk entries the architecture closed.

Mistakes four, five and six fail in the same place, the path a project takes from a design to a live system.

The second path costs one review per project and one pattern to maintain. The first costs a design per project and an exception nobody can close.

Enterprise security architecture compared with its neighbours

Most of the argument about this term is about scope, and it resolves in one line each.

The three frameworks are not alternatives: take SABSA's layers and traceability, TOGAF's method where an enterprise architecture practice already runs, and Zachman's schema when two teams disagree about what they are holding.

Standards and references

NIST CSRC glossary, security architecture (read September 2026). Free. Both definitions quoted at the top of this guide, and the statement that scope and level of abstraction vary.

NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (26 February 2024). Free. Section 3.1 is the dated statement of the current profile, the target profile, the gap analysis and the action plan that closes it. The GOVERN function states roles, authorities and resourcing as outcomes.

NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems (November 2022). Free. Written for system engineering, and still the best statement of what the architecture process should produce.

The SABSA Institute, SABSA Executive Summary (read September 2026). Free to read, and the methodology is free to use. The white papers are released on request: W100 (2009) covers the matrix cell by cell. Our summary is at SABSA.

Rassoul Ghaznavi-Zadeh, Enterprise Security Architecture: A Top-down Approach, ISACA Journal 2017 Volume 4 (28 July 2017). Free, and the only dated start-here sequence among the pages ranking for this term.

Network Applications Consortium, Enterprise Security Architecture: A Framework and Template for Policy-Driven Security (3 December 2004). Free, and better than its age suggests. The source of the three-part split, the eight principles and the decision and enforcement point pattern used above.

The Open Group, G152, Integrating Risk and Security within a TOGAF Enterprise Architecture (current edition 25 April 2022). Forty-four pages, produced with The SABSA Institute. The record is public; the text is behind a sign-in.

ISO/IEC 27001:2022 (October 2022). Sold, not free. Clauses 6.1.2 and 6.1.3 are where architecture decisions land as risk, and Annex A is where an assessor looks for the function.

Also used here, all free. Destination Certification's Enterprise Security Architecture Models (9 November 2025) for the SABSA layer names; Zachman International's own description of the schema, at zachman-feac.com; Wikipedia's Enterprise information security architecture for the term's origin at Gartner.

How Alvor helps

At enterprise scope the question is what a project inherits and where the inheritance is kept. In Alvor the patterns and blueprints carry immutable published versions in Secure by Design, so a project picks up a fixed version, not whatever the pattern said last week, and the controls it depends on, the designs that adopted it, the risks it left open and the evidence behind it sit on the same record.

The link to compliance runs through the asset record. A design's diagram elements point at assets in the inventory, threats anchored to those elements map to controls, and the Compliance module tracks those controls against frameworks such as ISO 27001, SOC 2, NIST CSF and the Essential Eight. Evidence is attached once and read by each framework through crosswalks, and status is never shared across one, so each framework is assessed on its own wording. You can add any framework in Alvor in the publisher's own structure, which is how an organisation's own control set is held alongside the published ones.

The design review gate runs inside the product, not in a process document. Every project takes the same path: classification and a business impact analysis, architecture design on a canvas, threat modeling on that diagram, control mapping, testing and evidence, then named sign-offs before go-live, with role-based gates and an event trail. A finding becomes a risk register entry with an owner, and a threat nobody can mitigate is accepted as a risk with an owner and a rationale. That is what turns an exception with an expiry date into a record instead of a promise.

The roadmap and the measures live in Security Management, which holds programs, projects and tasks, KPIs with thresholds, maturity assessments with history, and a board pack PDF in one click. It is where a target state becomes sequenced work with owners and dates. Enterprise architecture repositories sit beside that: the repository keeps the portfolio, the application map and the technology standards, and Alvor keeps the security side of the same systems, and the two meet at the asset inventory.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped, with all eight modules in every deployment. The AI Assistant is bring-your-own-model, so the model runs wherever the network requires, and every write it proposes waits on an approval card for a person to accept or reject. The Security Architecture page covers the category and what the platform holds.