Secure Architecture Review Process

Chapter 8 delivered a high-risk path to the refund service: a compromised operator can issue many distinct, valid refunds before daily reconciliation notices. It also delivered requirements for aggregate limits, independent approval, real-time detection, and tested revocation. Those are good requirements. They are not yet an architecture.

The review has to find where each control lives, whether another path bypasses it, what happens when a dependency fails, and what evidence will stop the release if the promise is still only prose. That work is cheapest while the system can still change on a diagram.

A security architecture review is complete only when three things survive the meeting: the packet that made the decision possible, an explicit decision, and evidence that every release condition was resolved.

Trigger review when an assumption changes

The refund team plainly needs a review: it is changing a privileged workflow, authorization policy, payment-worker behavior, security logging, and recovery. Less obvious changes deserve the same attention when they alter an assumption on which a security decision depends.

Require review for a new public endpoint, API, webhook, or mobile surface; a new store, queue, export, warehouse, or vector index; a new identity provider or authorization model; and a new administrator, support, or break-glass path. A third-party or SaaS integration changes trust and continuity. An AI or ML feature can add retrieval, model, prompt, and tool boundaries. Changes to encryption, keys, networks, tenancy, logging, build systems, or recovery can invalidate controls even when the product feature appears unchanged.

The useful fallback is not “large changes need review.” Size is a poor proxy for security consequence. Ask whether the change creates or moves a trust boundary, privileged action, sensitive-data path, external dependency, or recovery assumption. If it does, record the trigger and review the delta.

Review early enough to alter the design. A concept review may settle the identity model, data placement, and prohibited dependencies. A later design review can test detailed flows and control placement. Before release, reviewers should verify implementation evidence rather than conduct the first serious architecture conversation.

Admit a packet, not a presentation

The system owner begins with a short intake record:

System and accountable owner:
Change and review trigger:
Decision needed:
Target release and decision date:
Assurance level and reason:
Affected users, data, regions, and dependencies:
Links to the versioned review packet:
Open questions and named decision authorities:

The linked packet must contain eight things.

First, a system context diagram names users, administrators, services, stores, vendors, networks, build systems, and operational systems. Second, a data-flow diagram shows sources, processors, stores, recipients, protocols, identities, data classes, and direction. Third, trust boundaries mark every change in network, tenant, privilege, runtime, administrative control, or external ownership. Chapter 10 develops the method for drawing these three views; this review requires them because controls cannot be assessed against an unnamed crossing.

Fourth, the asset and data inventory supplies ownership, exposure, criticality, classification, important dependencies, telemetry, and recovery needs. Fifth, the identity and authorization model names human and workload identities, tenant context, privileged roles, and the places where policy is enforced. Sixth, the threat model carries its high-priority paths, controls, tests, detections, response, and residual risk. Seventh, security requirements state the behavior to enforce, the owner, and the proof required. Finally, the operational plan explains logging and alert ownership, vulnerability handling, backup and restore, containment, incident response, and exceptions.

For the refund service, one packet version should show the console, authoritative refund decision, payment worker, payment provider, decision store, event stream, reconciliation job, identity provider, and administrative path. It should identify where rolling limits and distinct-approver policy are enforced, and whether the worker can be called without that decision. The operational plan must say who receives an anomaly alert and how that person revokes operator authority and reconciles provider outcomes.

A packet need not be ornate. It does need to be internally consistent and specific enough to challenge. Reviewers should be able to follow the same identity and refund identifier across the diagram, requirements, tests, telemetry, and recovery procedure. If basic actors, flows, data, or owners are missing, return the packet during pre-read. A meeting is an expensive way to discover that nobody knows which service makes the decision.

Follow one risky action through the design

Pre-read should produce questions tied to flows, not a cloud of general concerns. In the meeting, start with the consequential action and walk it end to end. For the refund service: an operator session requests a refund; policy reads the operator, amount, rolling total, and any approval; an authoritative component records a decision; a worker sends the mutation to the provider; telemetry observes the result; recovery can stop further action and reconcile state.

At each crossing, ask:

• What asset is exposed, to whom, and in which region or tenant?
• Which human or workload identity is presented, and how is it authenticated?
• Which component authorizes this action on this object? Can a worker, queue consumer, administrator, retry, or maintenance path bypass it?
• Where are credentials and secrets created, stored, rotated, consumed, accidentally logged, and revoked?
• Which data classes cross the boundary, and what governs encryption, masking, retention, sharing, and deletion?
• What limits movement across network, tenant, runtime, cloud-account, and administrative boundaries?
• Which event proves allow, deny, mutation, approval, and control failure? Who owns the alert?
• If identity, policy, logging, the payment provider, or a key service fails, does the system deny, degrade, retry, queue, or require intervention?
• Which packages, images, runners, vendors, models, and deployment artifacts are trusted on this path?

The questions should change the design or its evidence. “Authorization is handled by the API” invites the bypass question. If both the console API and a batch worker can create the same provider mutation, a control in only one route is not the architecture the requirement promised.

The reviewer should also test recovery claims against state. Suppose the provider completes a refund but the internal response times out. A blind retry may duplicate money movement; a blanket fail-closed rule may leave the books uncertain. The packet needs an idempotency key, a durable decision and attempt record, reconciliation behavior, and an owner for ambiguous outcomes. Resilience and security meet at the point where the organization must distinguish “nothing happened” from “the attacker or retry changed money.”

Record the decision where the release can enforce it

End the meeting with one of five decisions.

Approved means the design and required proof are sufficient for the stated scope. Approved with conditions means named conditions must be evidenced at named gates; it is not permission to remember them later. Rework required returns a design whose structural gaps prevent approval. Exception required routes an out-of-policy residual risk to an authorized owner with compensating controls, detection, expiry, and reapproval. Prohibited pattern stops a design that violates a non-negotiable rule.

Every decision names its scope, decision maker, date, release effect, owners, due dates, evidence locations, and revisit triggers. “Looks good” supplies none of these.

The refund review might approve the architecture with three conditions: enforce aggregate limits and distinct approval at the authoritative decision; prove that the payment worker rejects unsigned or stale decisions; and replay the anomaly detection through the alert and revocation path. Put each condition in the delivery system as a release gate. The architecture record links to the task, but the passing test result, deployed policy, detection version, and exercise record close it. A checked box without that evidence does not.

When the review resolves a meaningful design choice, preserve this decision record beside the packet:

Decision and scope:
Context, threats, data classes, assurance level, and constraints:
Chosen architecture:
Alternatives rejected and why:
Required implementation, tests, telemetry, and operations:
Residual risk and accepting authority:
Review conditions, owners, due dates, and release gates:
Evidence links and packet version:
Revisit triggers:

For example, the team may choose a single authoritative refund-decision service over separate limit checks in the console and worker. The record should explain why scattered checks were rejected, what happens when the policy store is unavailable, how decisions are bound to amount and approver, and which tests prove that neither a queue message nor a direct worker call can enlarge the authority granted. That history helps a future engineer evaluate a proposed shortcut and helps an incident responder understand the expected state transitions.

Close conditions with evidence

Follow-up is part of the review, not clerical work after it. The system owner collects proof. Control owners explain discrepancies. The decision authority closes conditions or changes the outcome. Store the final packet version, review notes, decision record, conditions, exceptions, and evidence under a durable system identifier rather than in one attendee’s messages.

Before marking the review complete, confirm all of the following:

• the intake identifies the trigger, scope, accountable owner, assurance level, decision, and release date;
• the context, data flow, boundaries, inventory, identity model, threat model, requirements, and operational plan are present and agree;
• high-priority threats connect to enforced controls, verification, detection, response, and stated residual risk;
• the outcome and its authority are recorded;
• every condition has an owner, due date, release effect, and durable evidence link;
• every exception has an authorized risk owner, compensating controls, detection, expiry, and revisit event;
• the released design and configuration match the reviewed version;
• future changes that reopen review are named.

This checklist proves the review record is complete. It does not prove the system is secure. Evidence has to carry that second burden: test output for enforcement and bypass paths, configuration or policy versions, relevant deployment identity, detection replay, alert ownership, recovery exercise, and any exception approval. The kind of proof follows the claim.

Turn repeated decisions into bounded patterns

A sound decision can become an approved pattern when repeated use will save reasoning rather than conceal it. The catalog entry needs a reference diagram, exact applicability and non-applicability, required controls and defaults, tests, logging and monitoring, known failure modes, evidence expectations, and exception rules. Give it an owner and version.

A “privileged financial action” pattern might define authoritative policy enforcement, distinct approval above configured limits, decision binding, idempotent execution, immutable audit events, anomaly detection, and reconciliation. It can shorten the next review only while the new system shares its assumptions. A different identity provider, tenant model, data class, execution path, provider behavior, or recovery guarantee requires a delta review. Resemblance is not conformance.

What weak reviews leave behind

A late review leaves expensive structural findings. A verbal approval leaves no scope or accountable decision. An operations-free design leaves controls that nobody can observe or recover. A conditional approval without a release gate quietly becomes approval. An approved pattern copied beyond its assumptions turns yesterday’s reasoning into today’s blind spot.

All five failures have the same remedy: keep the chain inspectable. Trigger on the changed assumption, admit a coherent packet, trace risky actions through real boundaries, record the decision, bind conditions to release, and preserve the proof. When an incident later asks what the system was supposed to do, the answer should already exist.