# Architecture Review Question Bank and Decision Records > **Intro:** Senior reviewers are valuable when they ask the shortest possible question that reveals a hidden dependency. This page is a reusable prompt bank for architecture review and a compact format for recording the decision afterward. > > **What this page includes** > > * review questions by control domain > * how to write security ADRs and decision records > * how to record compensating controls and residual risk > * what to hand over to engineering, platform, and response teams ## Question bank ### Identity * Which identities are human, workload, or service identities? * Where are long-lived credentials still used, and why? * Can the same identity deploy code and read production data? ### Data * What is the highest sensitivity data this design touches? * Which logs, exports, caches, and backups will also receive that data? * What is the deletion and retention behavior for derived datasets? ### Authorization * Where is object-level access enforced? * What prevents background jobs from bypassing user-scoped checks? * Which admin actions bypass ordinary workflow friction? ### Resilience and abuse * What would a scripted attacker do first? * Which feature is easiest to monetize or automate? * What signal would tell us misuse started yesterday? ### Release and operations * Which pipeline or manifest change could weaken this design fastest? * What is the rollback plan if a control blocks good traffic? * Which evidence needs to exist for forensics later? ## Decision-record pattern Use a short ADR-style note: | Field | What to capture | | -------------------- | --------------------------------------------------- | | Context | What changed and why now | | Decision | What control or design choice was selected | | Alternatives | Real alternatives, not strawmen | | Security consequence | What risk is reduced and what residual risk remains | | Operational cost | Ownership, latency, friction, tooling cost | | Follow-up | Date, owner, success metric | ## Good compensating controls A compensating control is credible when it is specific. “We will monitor this” is not credible. “We will alert on cross-tenant export volume above baseline by service account and retain queryable audit events for 180 days” is credible. ## Hand-off checklist After the review, route outputs to the right team: * **application team:** code changes, schema changes, workflow checks; * **platform team:** defaults, policy, identity, runner or cluster guardrails; * **product security:** risk records, release gates, compensating controls; * **response team:** logging fields, alert ideas, playbook updates. ## Related pages * [Threat Modeling Methods and Workflows](/application-security-and-secure-sdlc/index/threat-modeling-methods-and-workflows.md) * [Policy Exception Governance Pack](/metrics-audit-risk-evidence-and-compliance/index/policy-exception-governance-pack.md) * [Detection and Response](/attack-paths-testing-detection-and-hardening/index.md) *** *Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/application-security-and-secure-sdlc/index/architecture-review-question-bank-and-decision-records.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.