What is security architecture?

NIST gives the definition to quote when precision matters: "a set of physical and logical security-relevant representations (i.e., views) of system architecture that conveys information about how the system is partitioned into security domains and makes use of security-relevant elements to enforce security policies within and between security domains based on how data and information must be protected" (SP 800-160 Vol. 1 Rev. 1, November 2022). The UK's National Cyber Security Centre gives the short version: security architecture is "the practice of designing the technology, people and processes within computer systems to achieve security goals."

The same glossary carries a second definition, inherited from SP 800-39 and published in SP 800-37 Rev. 2, which treats security architecture as an integral part of the enterprise architecture, describing the structure and behaviour of an organisation's security processes, information security systems, personnel and sub-units, and their alignment with the mission. One is the system view, the other the organisation view: the same practice at two scopes.

Why security architecture matters

Security, in NIST's own terms, is "freedom from those conditions that can cause the loss of assets with unacceptable consequences". That makes loss, rather than threat count, the thing a design is measured against. An adequately secure system delivers the capability it was built for despite adversity, and constrains itself so that only the behaviours that capability needs are realised. Security architecture applies that to structure: the unacceptable losses are made hard to reach, and the losses you live with are on the record with a name against them.

The work is commissioned by events, not by a calendar. Six triggers account for most of it: a new system or service; a new external integration, where somebody else's credentials now sit inside your data flow; a change to authentication or authorisation; a new category of regulated data in a system not designed to hold it; a customer security review; and an assessor asking how a control is met. Each one changes the shape of the system, and shape is what architecture decides. A date in the calendar is not one of them. Most of the work is a move rather than a drawing: from the system as it runs today to the system the organisation has decided it will have.

Taking that decision early is what keeps it cheap. A design decision costs an hour in a room. The same change after the build costs a rebuild and the quarter it was scheduled into. CISA, the NSA, the FBI and fifteen international partners put the position plainly for product builders in Shifting the Balance of Cybersecurity Risk (April 2023, revised 25 October 2023): secure by design investment "cannot be 'bolted on' later".

Skip the practice and four things happen, usually in this order. Controls get chosen project by project, so two teams solve the same problem twice and differently. Trust boundaries live in one engineer's head and leave when the engineer does. An audit cannot connect a control to the system it protects, so the evidence is a screenshot with nothing attached. And a threat model gets written that nobody acts on, which is the most expensive of the four because it looks like the work is being done.

How security architecture works, step by step

Architecture is a named process with a defined output, not a stage where somebody opens a drawing tool. NIST SP 800-160 Vol. 1 Rev. 1 gives System Architecture Definition its own technical process: generate architecture alternatives, select one or more that frame stakeholder concerns and meet the system's requirements, and express the result in consistent views and models. Among the security outcomes NIST attaches to it is traceability of the security aspects of architecture elements back to stakeholder and system requirements. Traceability is a standards expectation, not a vendor idea.

What the process produces is a small, fixed set of parts: one drawing of the structure, and four records kept about it.

Ten steps produce those parts, in this order.

1. Set the protection needs

Do this before any drawing, because every later argument about a control is an argument about whether a loss matters. ISO/IEC 27001:2022 clause 6.1.2 already requires risk acceptance criteria and named risk owners, so most organisations are applying criteria they have published. The output is a protection needs statement short enough that the engineering lead reads it.

2. Capture the current state honestly

You cannot plan a move out of a place you have not described. Write down the system as it runs today: the components, the flows, the credentials that exist, the boundaries that are only assumed, and the parts nobody would design that way now. Record what is true rather than what the runbook says, and date it, because a current-state view is only accurate on the day it was taken. NIST asks for the same material in its Stakeholder Needs and Requirements Definition process, which expects stakeholder assets to be identified, environmental adversities to be characterised and protection priorities to be determined. NIST's Cybersecurity Framework 2.0 calls the organisation-scale version a Current Profile: the outcomes an organisation is achieving now, and to what extent.

3. Draw the target state

Put the components, the data stores, the flows between them and the external entities on one diagram. That diagram is a data flow diagram, and it is the surface everything later attaches to. Then draw the trust boundaries. A security domain is a part of the system running under one security policy; a trust boundary is the line between two of them, where the level of trust changes. Number them, because everything downstream refers to them.

The target state is a decision rather than an aspiration: the structure the organisation has agreed it will have, dated and owned. CSF 2.0's Target Profile is the same idea at organisation scope, the desired outcomes an organisation has selected and prioritised, allowing for changes it can already see coming.

4. Name the gap between the two

The gap is the difference between the two views, written as work: something to build, something to move, something to retire, something to decide. CSF 2.0 makes it a step of its own, a gap analysis between the Current and Target Profiles that produces a prioritised action plan in a familiar form: a risk register, a risk detail report, a plan of action and milestones. Size each line while you are there, because an unsized gap becomes a roadmap item with no date, and a roadmap item with no date is a wish. Where a line says a system needs a design record, that means one set kept per system: the diagram with its numbered boundaries, the design explanation, the threat model, and the controls that came out of it.

5. Generate alternatives, then choose

NIST's process asks for alternatives and a selection, which is the part most teams skip. Two candidate structures and a paragraph on why one won is enough. The rejected alternative is often the more useful half, because it is what a future engineer is about to propose again.

6. Apply the order of precedence before adding controls

NIST puts a security design order of precedence ahead of adding features, and states its objective as "minimizing the system design basis for loss potential". This is the step that separates architecture from control selection, and the only one that removes work rather than adding it.

7. Threat model the chosen design

Threat modeling is the analytical step inside the design work. Walk the diagram element by element and ask what an attacker could do at each one. STRIDE, the six-category checklist from Microsoft's method, covers spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. What makes the model useful is the last column, where every threat ends in a decision: mitigate it, accept it with an owner and a review date, or change the design.

8. Turn decisions into controls and build requirements

A mitigation that stays inside the threat model changes nothing. Each one leaves the review as a control written in the language of the build: what is implemented, where, and how a reviewer will know. Map those controls to the frameworks the organisation answers to, because that is what turns design work into audit evidence. ISO/IEC 27001:2022 clause 6.1.3 requires risk treatment, a treatment plan and a Statement of Applicability, so design decisions are risk treatment decisions whether or not anyone files them that way.

9. Review and sign off by name

A design that was discussed is not a design that was accepted. The review produces a decision from named people, usually an engineering owner and a security owner, recorded with a date. Sign-off is where residual risk, what is left once the chosen controls are in place, is accepted explicitly rather than by silence. Then the design is baselined, so the next change is a decision against it rather than drift.

10. Keep it current

Re-open the design on a material change, not on a date. A calendar review catches the triggers above too late, every time. The output is a change record against the baseline, which is the shortest answer when an assessor asks whether the design still describes the system that runs.

How the transition is planned and governed

The steps above end with a target state and a gap for one system. An organisation with forty systems runs the same three moves at portfolio scale, then answers the question that decides whether any of it happens: in what order, out of whose budget, and who says yes.

The transition, planned as a roadmap

A roadmap is the gap list put in order, with a name and a date against each line. Order it by what removes exposure rather than by what is easiest to schedule, so the design selections that delete a class of loss come before the controls that detect one. ISO/IEC 27001:2022 clause 6.2 gives the shape of each line: what will be done, what resources it needs, who is responsible, when it is due and how the result is evaluated.

Funding belongs on the line. NIST SP 800-160 Vol. 1 Rev. 1 puts it in its Portfolio Management process, which expects budgets for the security aspects of each project to be allocated, responsibilities and authorities to be defined, and projects that stop meeting their security criteria to be redirected or terminated. Plan the retirement alongside the build: NIST runs its Transition and Disposal processes concurrently when a system is replaced, so the old path is decommissioned as the new one is commissioned, and the transition strategy carries the back-out plan, the training and the readiness review.

The organisational change that carries it

Architecture changes who decides what, and that is the change people feel. CSF 2.0 puts the expectation in its Govern function: roles, responsibilities and authorities for cybersecurity risk management are established, communicated, understood and enforced, with resources allocated to match. NIST SP 800-160 says the same at the level of one decision, expecting a decision management strategy that identifies the security-relevant roles, accountabilities and authorities, and a record of the resolution, the rationale and the assumptions. Its requirements process lists among the stakeholders those who hold milestone decision authority and acceptance authority, so architecture has to know who those people are before it starts.

Four changes to the operating model do most of the work. The design review becomes a gate with a named pair signing rather than a meeting with opinions in it. A standing forum owns the patterns, so the fourth project inherits authentication instead of inventing it. Any change to a baselined design goes back to a forum and onto the record. An accepted risk carries the name of whoever accepted it and the date it expires. SABSA calls the posture behind all four through-life: the method runs from business requirements engineering to managing the solutions delivered, which works only when someone owns the design after it is signed.

A worked example: a shipment tracking platform

A 400-person freight forwarder is building a shipment tracking platform. Customers log into a web app to see where their freight is, and carriers push status events in from their own systems. A tracking API serves the web app and a handful of customers who integrate directly. An events database holds the history, and the monthly on-time performance reports customers are billed against are produced from it.

Step 1, protection needs. One page names three unacceptable losses: a customer seeing another customer's shipments, a carrier feed going quiet so stale positions are shown as current, and the loss or alteration of the event history the on-time reports are produced from. The third makes the events database the system of record behind a commercial commitment, and that changes the design.

Step 2, the current state. A prototype is already in production with two carriers on it. Each carrier holds a database account and writes events straight into the events database. The web app checks authorisation endpoint by endpoint, and two of the eleven endpoints were added last month by a contractor who has since left. Nothing is drawn. The team writes that down in one dated page, those two endpoints included, because a current-state view that flatters the system is worth nothing to the people planning from it.

Step 3, the target state. The target-state diagram numbers every element so everything downstream can refer to it: two external entities, the tracking API (C1) and the carrier ingestion service (C2), the events database (DS1), four flows (DF1 to DF4) and three boundaries. TB1 is the public internet reaching C1, TB2 the carrier networks reaching C2, and TB3 the line between the application tier and the data tier, which both DF3, the validated writes from C2, and DF4, C1 reading shipments and events back out of DS1, have to cross. The three threats that decide the build are pinned where they sit.

Step 4, the gap. Side by side, the difference is four lines of work: build the ingestion service and move both carriers onto it, close the two carrier database accounts, move the authorisation check into the data access layer of C1, and notice a feed that has gone quiet. The team cannot fund the fourth line inside the release, and naming it here turns it into a dated decision rather than an omission.

Steps 5 and 6, alternatives and precedence. Two structures reach the review. In the first, each carrier is issued database credentials and writes into DS1 directly, which is what the prototype does. In the second, carriers post to C2, which validates each event and is the only thing that writes to DS1. The second is chosen, and the design explanation records why: under the first, an external party holds write credentials to the system of record behind the on-time reports, and no control placed later removes that. Choosing C2 is design selection rather than a control, and it removes interfaces as well: the rejected structure added an account and a write path per carrier, where the chosen design has one ingestion path for all of them.

Step 7, threat model. The team walks the diagram and records the threats that survive the chosen structure. Three of them decide the build, and each is pinned to the flow and boundary it crosses in the diagram above. T1 is information disclosure, and it sits on two crossings: on DF1 at TB1, where a customer asks for a shipment, and on DF4 at TB3, where C1 reads the events database to answer. It is mitigated by control SA-1. T2, tampering on DF2 across TB2, is mitigated by control SA-2. T3, denial of service on the same flow, is accepted for release one with an owner and an expiry.

Step 8, controls as build requirements. Two controls leave the review as work, each on the boundary its threat crosses. SA-1 covers both of T1's crossings at once: every DF1 request is authorised against the account that owns the shipment inside C1's data access layer, which is the same layer that issues the DF4 read across TB3, so a new endpoint inherits the check and no read reaches DS1 unauthorised. SA-2 sits on TB2: C2 authenticates each carrier, rejects events for shipments that carrier is not carrying, and records what it rejected, so nothing reaches DF3 unchecked. Both are written against the elements they protect, so a reviewer can test them without reading the whole design.

Step 9, the accepted risk and the sign-offs. Feed staleness detection lands in release two. An architecture decision record, ADR-014, holds that choice: the alternatives considered, the reason (there is no alerting to hang it on yet, and release one ships in six weeks), and the compensating step taken instead, which is that the web app and the API both return the timestamp of the last event received, so staleness is visible even while it is not alerted. The decision carries a named owner, Dana Okonjo in operations, and an expiry at release two, and it opens RISK-212 on the register rather than closing in a chat thread. Two dated sign-offs then gate the build, Priya Raghavan as engineering lead and Tom Whelan as security architect, and the design is baselined.

The roadmap that closes the gap. Release one carries the first two lines, both owned by Priya Raghavan's platform team and funded inside the release: the ingestion service with the carrier migration behind it, and the authorisation move. The last carrier database account closes the day the second carrier moves across, so the old write path is retired as part of the move rather than left switched on beside it. Release two carries staleness detection, owned by Dana Okonjo and funded from the alerting work already approved for operations, and it is the release RISK-212 expires into. Every line has an owner, a release and a funding state, which is what makes a roadmap reviewable rather than a list of intentions.

What changed in who decides. Before this design, a carrier was onboarded by whoever had time, and handing out a database account was a decision made inside a ticket. Afterwards three decision rights are written down. Priya Raghavan and Tom Whelan approve a design together, dated against a baseline. Dana Okonjo, not the security team, accepts RISK-212 and carries it to its expiry. Any change to the baseline goes back to the review that signed it. No committee was added: the freight forwarder named who decides, and put the decision where the next person looks.

Step 10, a material change re-opens it. In March a fourth carrier arrives that can only drop files onto a bucket, which adds a flow and a boundary to a design baselined in November. The change goes back to the review that signed it: the diagram gains the file-drop path, the threat model is re-run for the new crossing, and the baseline carries a dated change record instead of a quiet edit.

The walk an auditor takes. Nine months after go-live an auditor asks how the organisation applies Annex A 8.27 on this platform. The answer is the chain the work already left behind, read in reverse:

1. The design record is this system's answer to 8.27, and the design explanation carries the structure, the reason and the rejected alternative.
2. The threat model shows the analysis, T1 to T3 anchored to elements and each ending in a decision, and SA-1 and SA-2 are the controls those decisions produced, with build tickets and test evidence.
3. RISK-212 is the one threat not controlled, with Dana Okonjo against it, and the dated sign-offs from Priya Raghavan and Tom Whelan say who accepted all of it.

Every line of that walk is an artefact produced during the work, not a document written afterwards for the auditor.

Common mistakes

Nine failure modes account for most of the security architecture work that produces nothing. They share one root: the artefact gets treated as the deliverable instead of the decision. Seven of the nine land in the same place, the design record itself. Here is that record written both ways.

All nine, in the order they usually appear:

1. Starting with a control list instead of the structure. Draw the system and its boundaries first; a catalogue names the answer, it does not find it.
2. Treating the diagram as the deliverable. The decisions and their reasons are the deliverable; the diagram is how they are read.
3. Skipping alternatives. NIST's System Architecture Definition process asks for them, and a design with no rejected option has no recorded reasoning. One rejected structure and one paragraph on why it lost is enough.
4. Adding a control where the design could remove the exposure. If an external party does not need write access, the answer is a structure where it has none.
5. Architecture that never becomes a build requirement. A mitigation that leaves the review as a paragraph rather than as work an engineer is asked to do is gone by the second sprint.
6. No named sign-off, and a decision that lives in a chat thread. Without a name and a date, the residual risk was accepted by nobody.
7. A baselined design that drifts silently. Change after sign-off needs a gate, or the signed document describes a system that no longer exists.
8. Writing for the auditor instead of the engineer. Write the explanation an engineer would need in six months; it satisfies the auditor as a side effect, and the reverse is not true.
9. A target state with no current state behind it. A design that says where the organisation wants to be, with nothing recorded about where it is, produces a roadmap nobody can cost or sequence. Capture what runs today first, including the embarrassing parts.

Security architecture compared with its neighbours

Most of the confusion around this term resolves once you see what sits inside what.

Threat modeling, the design review and network security architecture are parts of the practice rather than alternatives to it. Security engineering and GRC are the two that meet it from outside. Each neighbour, and the line that separates it:

GRC and architecture meet at the control: the one a design review produced as a build requirement is the one a framework assessment reads. Held separately, that meeting has to be arranged by hand every time.

Standards and references

NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems (November 2022). Free, and the most useful single document on this subject. Appendix E holds the 30 principles for trustworthy secure design; D.3 the security design order of precedence; H.4 the System Architecture Definition process and the traceability it expects; I.3 and J.3 the decision rights, budgets and authorities a transition runs on.

NIST CSRC glossary, security architecture (read September 2026). Four sourced definitions, including the two quoted at the top of this guide: the system view and the enterprise view.

NCSC (UK), Security architecture (read September 2026). The shortest defensible definition in circulation, plus the NCSC's own design guidance. The page carries no publication date.

NIST Cybersecurity Framework 2.0 (26 February 2024). Section 3.1 is the current-to-target method in public: a Current Profile, a Target Profile, a gap analysis between them and a prioritised action plan. The Govern function is where roles, responsibilities and authorities are expected to be written down and resourced.

The SABSA Institute, SABSA (read September 2026). A business-driven method whose distinguishing claim is two-way traceability between business objectives and security decisions. It has evolved since 1995, the Institute maintains it as an open-use method that is free to use, and it runs through-life, from business requirements engineering to managing the solutions delivered.

The Open Group, G152, Integrating Risk and Security within a TOGAF Enterprise Architecture (first published January 2016, current edition 25 April 2022). Forty-four pages from The Open Group Security Forum with The SABSA Institute, for teams already running TOGAF. The full text is behind an Open Group sign-in.

CISA, NSA, FBI and fifteen international partners, Shifting the Balance of Cybersecurity Risk (April 2023, revised 25 October 2023). The source of the position that secure by design products start with written threat models describing what the creators are trying to protect and from whom.

ISO/IEC 27001:2022 (October 2022) and ISO/IEC 27002:2022. Annex A 8.27, Secure system architecture and engineering principles, is where an ISO audit asks for this work. Clause 6.1.2 carries risk acceptance criteria and named risk owners, and 6.1.3 the treatment plan and the Statement of Applicability. Clause 6.2 is about objectives, and its planning list is what this guide borrows as the shape of a roadmap line.

How Alvor helps

With Alvor, an organisation can hold the artefacts of security architecture, the decisions made about them, and their connections to controls, risks and evidence in one record. The artefacts are diagrams, design explanations and threat models; the decisions are reviews, decision records, named sign-offs and baselines. Holding them together turns a mitigation chosen in design into a build requirement, a risk register entry and evidence an auditor accepts.

The join runs through the asset record. A design in Secure by Design links its diagram elements to assets in the inventory. Threats anchored to those elements map to controls, and those controls are the ones the Compliance module tracks against frameworks such as ISO 27001, SOC 2, NIST CSF and the Essential Eight. A review finding becomes a risk register entry with an owner, so the threat model, the control set, the risk and the evidence trail all describe the same system.

The work runs as a governed program: 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. Role-based gates are where agreed decision rights become the way the work runs, and every change is recorded in the event trail. A threat that cannot be mitigated is accepted as a risk with an owner and a rationale, and changes past high-level design are governed, so a baselined design cannot drift without a decision on record. Enterprise architecture repositories and Alvor meet at the asset inventory: the repository keeps the portfolio, Alvor carries the security side of the same systems.

The AI Assistant is bring-your-own-model, pointed at Anthropic, OpenAI, Google, Azure OpenAI, Amazon Bedrock, or any OpenAI-compatible endpoint including self-hosted vLLM and Ollama. It draws architecture diagrams as editable shapes, proposes threats and controls, and drafts design explanations. It sees only what the signed-in user can see, every write pauses on an approval card, and every action is audit-logged. Sign-off stays with named people.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers as the same containerised platform, or fully air-gapped with a self-hosted model inside the boundary. All eight modules and the AI Assistant are in every deployment. The Security Architecture page covers what the platform holds, and Secure by Design covers how a design moves from intake to sign-off.