Security architecture review
Find the security gaps while it is still a document.
At design time a missing control is a paragraph to write. After build it is a system to change.
Upload a low-level design, or just its diagrams. Every architectural security question comes back answered, unanswered or ruled out — across the AWS, Azure and Google Cloud well-architected frameworks and the architecture-testable subset of ISO/IEC 27001 Annex A — each citing the page it came from.
This build ships recorded analyses: complete results produced by the real pipeline against real documents, with the document itself downloadable beside each one. Every screen says so.
The design document
cited — page 12Page 12 · section 5, Proposed architecture
The diagram, read
- Application Gateway
- Web Server
- SQL MI Primary
- SQL MI Secondary
- edge · Sync
Four components and the edge between them, at the coordinates the extraction recorded.
A check is matched
CHK-DATA-REST-014
Databases encrypt data at rest
Not evidenced
Databases encrypt data at rest
The design is silent on how the managed instances encrypt at rest. Not a pass, and not a fail.
page 12, section 5 — Proposed architectureA real page, its real diagram, and the finding that came out of it, from the recorded Ingram Micro analysis rather than an illustration. The citation points back at the page it started from. That is the whole product.
Reconciled by hand
What a security architecture review costs today.
- Four catalogues open at once: AWS SEC 1–11, the Azure SE checklist, the Google Cloud recommendations, ISO 27001 Annex A.
- A hundred-page design read end to end, because the security controls are in the back half.
- The same question answered four times under four clause numbers, then reconciled by hand when the answers disagree.
- Findings pasted into a deck with no page reference, so nobody downstream can check them.
- Days of a senior reviewer, which is why the review is the thing that gets skipped.
One workbook, every row cited
What comes back, in about the time it takes to make coffee.
- About sixty canonical checks, each already mapped into all four frameworks.
- The whole document indexed and retrieved against, not the first few thousand characters summarised.
- One question answered once, projected onto four clause numbers, so the frameworks cannot disagree.
- Every row cites a page and a section, and clicking a citation opens the source text.
- One workbook and a browser view, produced unattended, that a reviewer spends their day judging rather than assembling.
What it costs to run
~60
canonical checks
One per architectural question, each mapped into AWS, Azure, Google Cloud and ISO 27001 Annex A.
6–8
validation batches per document
About sixty checks, clustered by shared evidence rather than asked one at a time. A batch takes a second call when the model fetches a section, so calls run higher than batches. Seven of the eleven pipeline stages call no model at all.
≈ $1.50
target cost per document
Budgeted per document, and measured per call by the token ledger. A diagram-heavy design carries the cost: extraction is four passes per diagram, so seven to ten diagrams is most of this figure.
≈ 5 min
target wall clock
Upload to browser report and downloadable workbook, unattended, with no review gate in the middle.
The cost and time figures are the design targets this build is engineered against and measures itself with: the token ledger records model, tokens and dollars for every call. The recorded analyses were produced against live models, and their measured cost sits either side of the target — a three-diagram design came in well under it, a five-diagram one over. Treat these as budgets that are enforced, not as results from a production fleet.
What a reviewer gets
Doing this naively with a language model is worse than not doing it at all. A keyword match reports a pass on“TDE is not enabled”because the string contains “TDE”. A summary of the first few thousand characters reads the title page and the table of contents, and the security controls live in the back half. And a claim with no citation cannot be checked, which means it cannot be defended in front of the client who paid for it.
So the output is built to be argued with. Every row names where it came from, every suppression names why, and every confidence level names the signal it was derived from rather than asking the model how sure it feels.
Citations that resolve
Every claim points at a block id. Clicking “page 27, section 4.3.2” opens the actual source text and its neighbours. A citation you cannot open is decoration.
One canonical check layer
About sixty checks, each mapped to clauses in all four frameworks. The model is never asked the same question twice, so the frameworks cannot disagree with each other.
Nothing disappears silently
Every suppressed check is shown with the reason it was suppressed, and every extraction item carries the confidence it was read with, and why.
A workbook a reviewer can work
One row per clause with remarks and verdict columns, stable finding ids so an annotated workbook can come back in, and a first-class “not evidenced” sheet.
Four statuses, and a silent design is one of them
A design that never says how it encrypts its data has not passed and has not failed. It has a documentation gap, which is exactly what a low-level design review exists to find.
- Passed
pass
The design says the control is in place, and the cited block actually says so.
- Failed
fail
The design says it is not, or says something that contradicts it — "TDE is not enabled" is a fail, not a keyword match on "TDE".
- Not evidenced
not_evidenced
The design is silent. A documentation gap, reported as one, on its own sheet of the workbook. Never counted as a pass.
- Not applicable
not_applicable
The check does not apply to this design — no object storage, so no object-storage check. The reason is recorded and shown.
What comes back
The cloud frameworks are reported as alignment and ISO as architecture-testable control coverage. Neither is a compliance attestation and the report never calls it one. The two cards below are illustrative shapes with invented numbers, not a real assessment.
Illustrative sample — not a real assessment
Azure Well-Architectedalignment
21 of 42 applicable checks passed
There is no percentage here, and there is no field to put one in. The denominator moves with the design, so a percentage punishes a thorough document.
Illustrative sample — not a real finding
No WAF in front of the internet-facing application gateway
Why this confidence: anchored evidence retrieved and the cited block verifiably contains the claim; the affected component was extracted with high confidence.
Those citations are buttons in the real report. Clicking one opens the source block and its neighbours, so a reviewer can check the claim rather than take it on trust.
One finding, several framework references — not several rows a reviewer reconciles by hand.
Three ways in
A document
One PDF or Word low-level design. Cloud platform, compliance scope, data classification and stated controls are all derived from the text.
Diagrams only
Architecture images plus a short scope declaration, because without prose there is nothing to derive the cloud, the regimes or the environment from. This mode is a diagram sanity check, not a compliance review, and the report says so at the top.
Diagrams with written context
Images plus pasted text. The text becomes a document with anchors of its own, so it can be cited exactly like a real one.
How it works
Eleven stages. Seven of them never call a model.
That is not a cost trick, it is the reason the same document reviewed twice gives the same answer. Everything that can be ordinary deterministic code is ordinary deterministic code, and the model is asked only the questions that genuinely need judgement.
Parse and anchordeterministic
Builds the anchored document model: every block carries a page, a section number and a stable id.
Asset triagemodel call
Filters image candidates down to real diagrams.
Diagram extractionmodel call
Reads zones, components, edges and labels out of each diagram.
Indexdeterministic
BM25 plus embeddings over the document, in process.
Profilemodel call
Determines cloud, services, environment, data classification and compliance scope.
Component linkingdeterministic
Matches diagram components to the prose that describes them.
Check selectiondeterministic
Selects applicable checks and records every suppression with its reason.
Evidence assemblydeterministic
Retrieves anchored evidence for each selected check.
Validationmodel call
Clustered batch validation against the canonical check layer.
Scoringdeterministic
Projects results onto framework clauses and derives confidence.
Reportdeterministic
Builds the web report payload and the Excel workbook.
Parsing, indexing, component linking, check selection, evidence assembly, scoring and report generation are ordinary code. Only asset triage, diagram extraction, profiling and validation call a model — and validation, the expensive one, is six to eight batches because there are about sixty canonical checks clustered by shared evidence, not two hundred framework clauses asked one at a time.
The canonical check layer
One question, answered once, projected onto four clause numbers
The four frameworks are largely the same checks wearing different clause numbers. Strip out what a design document cannot answer and roughly a hundred and twenty-five testable items across the four collapse to about sixty distinct architectural questions. So the knowledge base is not four parallel rule sets. It is one canonical layer with framework clauses attached.
One canonical check — asked once
Is data at rest encrypted with managed keys?
Evidence is retrieved once, the model answers once, and the answer carries the block it was read from.
AWS Well-Architected
SEC08-BP01
Security pillar, SEC 8
Azure Well-Architected
SE:07
Security checklist
Google Cloud
SBD-04
Secure by default
ISO/IEC 27001:2022
A.8.24
Use of cryptography
The model is never asked the same question twice, so it cannot contradict itself across frameworks. One answer is projected onto four clause numbers. A clause passes when every check mapped to it passes and fails when any of them fails.
A clause with no architecture-testable check mapped to it is reported in its own band — not counted as a pass, and not held against the design. Physical controls and incident-response procedure are not things a low-level design can answer.
It is also why validation is six to eight batches rather than two hundred: about sixty checks clustered by shared evidence, instead of roughly two hundred framework clauses asked one at a time.
What this is not
Not a compliance attestation
Cloud frameworks are reported as alignment and ISO as architecture-testable control coverage. A certification body signs attestations; a review tool does not.
Not a review of the running system
It reads what the design says. A control the document claims but the deployment never received will read as a pass here — and the citation shows you exactly which sentence to go and verify.
Not the whole of a framework
Physical controls, incident-response procedure and secure-coding practice cannot be judged from an architecture document. They are reported in their own band, counted separately, and never quietly dropped.