What is security architecture?
How the security of a system is arranged: the parts, the boundaries between them and the decisions that hold when something goes wrong.
A short definition
Security architecture is how the security of a system is arranged. It covers which parts exist, where the boundaries between them run, what is trusted, what is not, and what happens when one part fails. It is a description of structure and intent, not a product you install.
A useful way to test whether you have one: pick a system and ask where its data enters, where it leaves, who can reach it without authenticating, and what an attacker would reach next after taking over any single component. If those answers exist in writing and people agree on them, you have a security architecture. If each answer depends on who you ask, you have a set of controls instead.
Security architecture and IT architecture
IT architecture describes how a system is put together to do its job. Security architecture describes the same system from the point of view of what must not happen. They are views of one system, not two separate designs, which is why security architecture work usually starts by reconstructing the IT architecture that nobody wrote down.
Logical, physical and the words in between
The same system gets described at different levels, and the terms are used loosely across the industry. In practice three are worth separating:
- Logical: the components, trust boundaries and data flows, independent of where anything runs. This is the level at which most security decisions are actually made.
- Physical or deployment: the machines, networks, cloud accounts and regions where those components run. This is where a logical decision either holds or quietly does not.
- Operational: who holds which access, how changes are approved, and how the system is monitored and recovered. Architecture that ignores this level tends to describe a system nobody is running.
Formal models such as SABSA, TOGAF’s security views or the layered descriptions in ISO/IEC 27001 Annex A give vocabulary for this. They are useful for organising a description, and they are not a substitute for knowing your own dependencies.
What is a security architecture review?
A review examines an existing system and reports what its structure means for security. It is an assessment of design, not a scan of running machines. A penetration test asks “can I get in through this specific path?”; an architecture review asks “what would getting in anywhere reach, and was that intended?”
A review normally produces:
- A current-state description: components, data flows, trust boundaries and external dependencies, in a form your team recognises as accurate.
- The decisions that are load-bearing, including ones never written down and ones that no longer match how the system runs.
- Where a single failure or compromise spreads further than anyone assumed.
- A prioritised list of changes, with the ones that need rebuilding separated from the ones that need a setting changed.
- What was checked, what was not, and on what evidence.
When a review earns its cost
Usually at a point of change or pressure: a migration, a merger, a first enterprise customer sending a security questionnaire, a regulatory deadline such as NIS2 or the Cyber Resilience Act, or the third incident with the same root cause. Reviewing a stable system that nobody is about to change tends to produce a document rather than an outcome.
Can architecture be tested?
Not in the way a running system is tested, because there is nothing to send traffic to. What can be tested is whether the real system matches the described one. That is where most of the value sits, since architecture drifts: a boundary drawn in a diagram becomes a security group that was widened during an incident and never narrowed back.
Practical checks include comparing network rules and identity permissions against the intended boundaries, tracing one real request end to end, and reviewing what a deployment pipeline is permitted to do in production. Threat modelling is the design-time equivalent: working through how a component could be misused before it is built.
The boundary that was not one.
The reporting service reads from a replica and cannot reach customer data directly.
The replica shares credentials with the primary, so any compromise of reporting reaches production data.
A low-sensitivity service sits inside the highest-sensitivity boundary, and no control in place would show it.
Composite example of a common pattern, not a client case.
Common questions
Is security architecture the same as a security framework?
No. A framework such as ISO 27001 or the NIST Cybersecurity Framework tells you which areas to cover. Security architecture describes how your particular system is arranged. Two organisations can satisfy the same framework with very different architectures.
Do we need a security architect to have a security architecture?
No. Every system has one, whether or not anyone chose it deliberately or wrote it down. The question is whether it is understood well enough to make decisions against, and whether it matches what is running.
How is this different from a vulnerability scan?
A scan finds known weaknesses in components that exist now. An architecture review finds weaknesses in how those components are arranged, which a scanner cannot see because each part may be individually up to date and correctly configured.
How long does a review take?
It depends on how many systems are in scope and how much is already documented. A focused review of one product with a cooperative team is usually weeks rather than months. Reconstructing an undocumented estate takes considerably longer, and that reconstruction is normally the bulk of the work.
What do we need to prepare?
Whatever description already exists, even if outdated, plus access to the people who can explain how the system actually behaves. Accurate answers from engineers are worth more than a tidy diagram.
You do not need to know the technical term.
Tell us what is happening, what it affects and when you need help. We’ll discuss whether we can help and what a useful first piece of work would be.