Security Control Matrix
Each required control mapped to the specific mechanism that implements it, the evidence it produces and the person accountable for it.
The curriculum covers what an architect should know. This covers what an architect actually hands over: 55 artifacts, each with a worked example, a note on when it is worth producing, who reads it, and the ways it usually goes wrong. Filter by the artifact's type, the kind of engagement that calls for it, the stack or industry it is drawn against, or the audience it is written for.
Identify the deliverable → 42 diagrams, shown one at a time with the answer withheld. Nothing to submit.
2 of 55 deliverables shown.
Each required control mapped to the specific mechanism that implements it, the evidence it produces and the person accountable for it.
flowchart LR
user(["Customer<br/><i>untrusted</i>"])
admin(["Admin<br/><i>privileged</i>"])
subgraph edge["Boundary 1 — public edge"]
cdn["CDN / WAF"]
end
subgraph app["Boundary 2 — application tier"]
direction TB
api["Order API"]
auth["Auth Service"]
end
subgraph datab["Boundary 3 — data tier"]
direction TB
db[("Order Store<br/><i>PII + card token</i>")]
kms[("Key Vault")]
end
ext["Payment Provider<br/><i>third party</i>"]
user -->|"F1 HTTPS"| cdn
cdn -->|"F2 HTTPS + mTLS"| api
admin -->|"F3 admin console"| api
api -->|"F4 token introspection"| auth
api -->|"F5 TLS + parameterised"| db
api -->|"F6 fetch DEK"| kms
api -->|"F7 HTTPS outbound"| ext
ext -->|"F8 webhook — signed"| cdn
Processes, stores and flows with trust boundaries drawn across them, so that every boundary crossing can be enumerated for threats.