Security Architecture & Design Review

Coverage

What we review

Threat Modelling

Identify threat actors, attack vectors, and potential impact using STRIDE/DREAD frameworks tailored to your system.

Data Flow Analysis

Map every data path from ingestion to storage, identifying where sensitive data is exposed or inadequately protected.

Trust Boundaries

Evaluate where trust transitions occur between components, services, and networks and whether controls are in place.

Cloud Configuration

Review IAM policies, network security groups, storage access, encryption settings, and logging across AWS, Azure, or GCP.

Auth & Access Design

Evaluate authentication flows, session management, role-based access, and privilege escalation paths in your design.

Third-Party Integrations

Assess risks from external APIs, SDKs, and SaaS dependencies in your architecture.

Methodology

Review process

A design review is cheap compared with rebuilding a live system. These four phases turn your diagrams into a ranked list of design changes, with the reasoning attached so your team can argue with it.

01

Collect Architecture Artefacts

We start from whatever you actually have: system diagrams, data-flow documents, API specifications, Terraform or CloudFormation, IAM policies, network diagrams, and a list of the third parties in the request path. Perfect documentation is not a prerequisite — if the diagram is three years stale, that is itself a finding worth knowing about.

We then interview the people who built it. The gap between the documented architecture and the one running in production is where a surprising share of real risk lives, and it only surfaces in conversation.

You provide
Diagrams, IaC repositories or read-only cloud access, API specs, and an hour each with two or three engineers.

We do
Review the artefacts, reconstruct the real data flows, and record trust boundaries and assumptions.

You get
A validated architecture and data-flow picture, including the drift we found from your documentation.

Typical time
2–4 days
02

Threat Model

We apply STRIDE to every component and, more importantly, to every trust boundary — the points where data crosses from something you control into something you do not, or from one privilege level to another. For each boundary we ask what an attacker on the wrong side of it could reach, and what would stop them.

The output is a set of concrete threat scenarios specific to your business, not a generic list. “A compromised CI runner can read the production database credential from the pipeline environment” is something a team can act on. “Consider insider threat” is not.

You provide
Availability for a two-hour threat-modelling session with the engineers who own each component.

We do
STRIDE analysis per component and boundary, attacker-goal mapping, abuse-case development.

You get
A written threat model with scenarios ranked by likelihood and blast radius.

Typical time
3–5 days
03

Control Gap Analysis

Each threat scenario is checked against the controls you already have. Many will already be covered, and saying so plainly matters — it stops budget going to problems that are already solved. What remains are the gaps: places where the design, not the configuration, is what leaves you exposed.

We separate gaps that need an architectural change from those a configuration fix will close, because the two have very different costs and timelines. We also flag controls that exist but cannot be evidenced — a distinction your next auditor will care about.

You provide
Access to existing control documentation, monitoring configuration, and any prior assessment reports.

We do
Map controls to threats, test whether key controls actually hold, and rate residual risk.

You get
A gap register separating design-level changes from configuration fixes.

Typical time
2–4 days
04

Recommendations & Walkthrough

Recommendations are delivered in priority order, each with the threat it addresses, the rough engineering effort, and the trade-off it carries — because every security control costs something in latency, cost or developer experience, and pretending otherwise is how security advice gets ignored.

We then walk the report through with your team and, where it helps, with your board or customers. Where a recommendation is a phased migration rather than a change, we sketch the intermediate states so you are never left with a half-finished design that is weaker than where you started.

You provide
A review session with engineering leadership, and decisions on which items you intend to take.

We do
Prioritised recommendations, reference designs for the significant changes, and a walkthrough session.

You get
A report, a target architecture sketch, and a sequenced roadmap you can put into sprints.

Typical time
2–3 days

FAQ

Common questions

What is a security architecture review?

A security architecture review examines your system design, data flows, trust boundaries, and technology choices to identify weaknesses before code is written or deployed. It ensures security is built in from the start rather than bolted on later.

When should I get a security architecture review?

Ideally during the design phase of any new system, major feature, or cloud migration. It's also valuable before compliance audits, after acquisitions, or when redesigning authentication and data storage systems.

What does the review cover?

The review covers threat modelling, trust boundaries, data flow analysis, authentication and authorization design, encryption at rest and in transit, network segmentation, cloud IAM policies, logging and monitoring strategy, and third-party integration risks.

Secure your architecture from day one.

Share your design documents and we'll identify risks before a single line of code is deployed.

Get in touch View all services

Security Architecture