Security Architecture Review

A penetration test tells you what broke. An architecture review tells you why that class of thing keeps breaking.

We review how a system or an estate is designed — trust boundaries, identity, segmentation, data flow — and judge it against how an attacker would actually move through it. It is the cheapest point at which security decisions can still be changed, and the one most organisations skip.

Hand sketching a system design on paper
Cheaper to change on paper than in production
Who this is for

Four points where a review earns its cost

You are about to build

The design is settled enough to review and not so far advanced that changing it is expensive. This is the best moment and the rarest one.

Testing keeps finding the same thing

Successive tests surface variations of one underlying weakness. That is a design problem wearing a findings-report costume.

The estate grew by accretion

Systems were added over years, each sensibly, and nobody has stood back to look at the whole since.

You are being asked for a roadmap

Someone wants to know what to spend on security over the next two years, and a list of findings is not an answer to that.

What we review

The decisions that determine how far an intrusion travels

Trust boundaries

Where the design assumes trust, whether that assumption is enforced by a control or only by convention, and what sits on either side.

Segmentation

What an attacker reaches after the first foothold. Most environments are far flatter than their diagrams suggest.

Identity architecture

How authentication and authorisation are decided, where privilege concentrates, and which single account would be worst to lose.

Data flow

Where sensitive data travels, which systems it passes through that nobody thinks of as sensitive, and where it comes to rest.

Detection by design

Whether the architecture produces the evidence you would need during an incident, or whether visibility was left to be added later.

Resilience and failure modes

How the design behaves when a component is lost or compromised, including what fails open.

How we work

Reviewed against a threat model, not a checklist

01

Understand the system

Documentation where it exists, and sessions with the people who built it where it does not — which is the more common case.

02

Agree the threat model

Who realistically comes after this, what they want, and what you are willing to accept. Without this a review is just opinion.

03

Trace the paths

We work through how an attacker moves from each plausible entry point, and where the design does or does not stop them.

04

Roadmap

Changes sequenced by how much exposure each removes, separated into what to do now, what to do at the next refresh, and what to accept.

Deliverables

What you receive

  • An architecture assessment describing the design as it actually is, which is frequently not how it is documented
  • A threat model agreed with you, naming who you are defending against and what they would go for
  • Attack path analysis showing how far an intrusion travels from each entry point
  • A prioritised roadmap separating what to change now from what to change at the next refresh
  • A session with your architects and engineers, because a roadmap nobody argued with does not survive contact
Scoping

Timing and cost

Cost depends on whether we are reviewing one system or an estate, how much documentation exists, and how many teams need to be involved. A single application design is a contained piece of work; an enterprise estate with a decade of history is not.

We do not publish packages or rates. Every engagement begins with a short call, followed by a written scope and a fixed price for that scope before any work starts.

What we need to scope it

What the system does, roughly how large it is, whether it exists yet or is being designed, and what documentation you can put in front of us.

FAQ

Common questions

Do we need documentation before you start?
No. Very few organisations have current architecture documentation, and reconstructing the real design from conversations and configuration is part of the work. If accurate diagrams exist they speed things up, but their absence is not a blocker — and the reconstruction is often valuable on its own.
Should we do this or a penetration test first?
If you are building something, review the design first — findings are far cheaper to act on before the thing exists. If you have a running estate and no idea of its condition, a test gives you concrete evidence of exposure quickly. If tests keep finding the same class of issue, the review is what actually resolves it.
Is this a zero trust engagement?
It can inform one. We assess the design against your actual threat model rather than against a named architectural doctrine, and where the answer points toward removing implicit trust we will say so. We would rather not sell you a label.
Will you tell us to replace everything?
No. A roadmap that requires rebuilding the estate is a roadmap nobody funds. The output is sequenced by what each change actually removes in exposure, which usually means a small number of structural changes and a longer tail of smaller ones.

Tell us what you are building or running

Thirty minutes and we will tell you whether a review is the right thing now, and what it would look at.

Start with a scoping call