How to Use This Handbook

Security guidance fails when it arrives as a pile of advice. An engineer adding refunds to a payment service might need an authorization design today, an implementation review tomorrow, and an incident playbook six months later. Reading the book from cover to cover is useful, but it is not the fastest way through any of those decisions.

Use this handbook as an operating manual. Start with the work in front of you. Name its threat and trust boundary, choose the assurance level, follow the relevant requirements, and leave evidence another engineer can inspect. The route changes as the system moves from design to production; the reasoning does not.

Begin with the work, not the control

The figure is the book’s route map. Enter it at the activity that brought you here:

• For a new system or major feature, begin with governance, inventory, threat modeling, and secure design. Produce a system security profile, trust-boundary diagram, threat assumptions, and control requirements before implementation hardens the wrong choices.
• For an existing-system review, establish the minimum security bar, inventory what exists, identify credible attack paths, and record gaps with owners. A list of generic best practices is not a review result.
• For a pull request or implementation review, use the build and assurance chapters. Inspect the actual authorization path, data handling, dependencies, configuration, tests, and failure behavior.
• For production operation, use the operating chapters for access, hardening, patching, monitoring, backup, restore, and change safety. Design evidence cannot prove that a deployed control still works.
• For an incident or suspected compromise, go directly to defend and recover. Preserve evidence, make containment decisions, establish scope, and prove that recovery returns the system to a trusted state.
• For customer assurance or audit, begin with the engineering artifacts already produced. Map controls to repositories, configurations, test results, dashboards, decisions, and runbooks instead of creating a parallel paper system.

The activity determines what counts as proof. A threat model can support a design decision; it cannot prove that object-level authorization is deployed. A passing test can support a release; it cannot prove that a restore procedure works under incident pressure.

Put every decision in the same shape

Across those routes, use one operating rule:

A security decision names the threat assumption, the secure default, the exception path, and the evidence.

Consider the refund operation. The threat assumption is that a compromised support session, a confused service, or an authorization flaw could move money without the account holder’s intent. The secure default is a narrow refund permission, object- and action-level authorization, explicit limits, and a security event that identifies the actor, account, payment, amount, and decision. The exception path names who may accept a temporary gap and how the exposure will be contained. The evidence includes authorization tests, deployed policy, denied-action results, and sampled audit events.

If the team cannot fill in all four parts, it has not yet made a reviewable security decision. It may have a preference, a product requirement, or a control name. Keep working until the attack path, default behavior, exception authority, and proof are explicit.

Read requirement language precisely

The handbook uses normative words to separate requirements from options. Read them as engineering instructions, not emphasis.

Applicability tags narrow a requirement to the systems that need it: public-facing, internal, regulated-data, privileged-system, multi-tenant, AI-enabled, or critical-service. Apply every tag that describes the system. An internal administration service may be both internal and privileged-system; its network location does not erase the consequence of misuse. An AI-enabled workflow that touches customer records still inherits identity, data, logging, retention, and abuse requirements.

Pick an assurance level

Assurance level decides how much proof is required. Choose it from consequence and exposure, not team size or architectural complexity.

Level 1 — Baseline commercial fits internal tools, low-risk services, and prototypes without real sensitive data. At minimum, identify the owner, inventory, access model, logging, dependency checks, and—when the system holds state—the recovery owner.

Level 2 — Internet-facing or sensitive data adds the proof expected for public APIs, customer applications, business workflows, and systems holding personal or confidential data. Expect a threat model, security review, automated tests at identity and input boundaries, monitoring, an incident path, and restore testing for stateful systems.

Level 3 — High impact covers systems whose failure can materially affect identity, money, health, safety, regulated activity, production control, or critical infrastructure. It requires deeper abuse analysis, independent review, explicit control mapping, hardened access, strong change control, recovery exercises, an evidence pack, and named acceptance of residual risk.

The refund operation belongs at Level 3 because it moves money, even if the service is small. A low-risk internal utility can remain Level 1 and still be engineered responsibly. The level is a demand for evidence, not a status symbol.

Read a checklist as a claim to prove

A checklist item is useful only when five things are clear: the requirement, where it applies, the evidence to inspect, the pass-or-fail boundary, and any residual risk. Do not treat a checked box as evidence of itself.

Suppose a release checklist says that every refund must be authorized at the protected operation. The requirement is the authorization check. Its applicability includes the refund endpoint, background jobs, retries, and administrative tools—not only the user interface. Evidence might include the policy or code path, tests that change the account and payment identifiers, a denied-action result, and a sampled production event. The item passes when each path enforces the same decision. If a legacy batch path remains outside that boundary, the residual risk must be repaired or handled through the exception process.

This reading discipline prevents a familiar failure: a control exists somewhere, so the team assumes it governs everywhere.

Use exceptions without normalizing drift

An exception is not a promise to fix something later. It is a temporary, bounded decision to carry a specific risk. Record the unmet requirement and the reason it cannot be met now; name a risk owner with authority to accept the consequence; set an expiration date; describe the compensating controls and the detection and response plan; and state what evidence renewal would require.

“MFA deferred until after launch” is not an exception record. It has no boundary, owner, containment, or end.

Here is a usable modeled record:

Decision: The Level 2 administration console will launch with SSO and named accounts but without phishing-resistant MFA. Reason: The required identity-provider migration is scheduled for release 2026.08. Risk owner: VP Engineering. Expiration: August 31, 2026. Compensating controls: VPN restriction, just-in-time administration membership, session logging, daily review of administration events, and no shared accounts. Detection and response: alert on new membership, unusual session origin, and repeated denied actions; disable the account and follow the credential-compromise playbook when triggered. Reapproval: renewal requires evidence that the migration is blocked by a new dependency and that the compensating controls have operated as described.

Expiration should force a decision: satisfy the requirement, replace the control, renew against fresh evidence, or stop the exposed activity. An exception that renews automatically has become an undocumented default.

Build a system security profile

Every meaningful security review should leave a system security profile that another engineer can inspect. The profile is a compact statement of what must be protected and where the proof lives.

For the modeled payment service, it might say:

• Ownership: Payments Engineering owns design and change; Payments SRE owns production operation.
• Business capability: Authorize, capture, and refund customer payments.
• Users and callers: Checkout clients, the order service, a payment processor, support staff, scheduled reconciliation, and administrators.
• Data: Customer and transaction identifiers, payment tokens, refund state, credentials, and security events. Raw card data is outside the service boundary.
• Trust boundaries: Public client to API, order service to payment service, payment service to processor, support console to administration API, and production workloads to the secrets and data stores.
• Critical actions: Capture, refund, change a payout destination, alter limits, export transaction data, and grant administrative access.
• Secure defaults: Authenticated callers, object- and action-level authorization, idempotent money movement, narrow workload identities, protected secrets, tamper-resistant audit events, and tested recovery.
• Evidence: Threat model and architecture decisions in the repository; authorization and idempotency tests in CI; deployed policy exports; security-event dashboards; access reviews; refund and credential-compromise runbooks; restore exercise records.

The profile should be plain enough to survive handoff, incident response, and assurance review. A clever diagram without owners or evidence locations cannot do that job.

Field reference

Use this decision path when you need a chapter or checklist quickly:

1. Name the activity: design, build, review, operate, defend, recover, or assure. Enter the corresponding part of the book.
2. Decide the assurance level from exposure and consequence. When uncertain between two levels, begin with the stronger evidence requirement and lower it only when the system profile justifies doing so.
3. Name the asset, data, identity, critical action, and trust boundary at risk. This points to the relevant topic chapter or domain playbook.
4. State the secure default and the evidence that would prove it. Use the chapter’s checklist to test the design, implementation, or operating state.
5. If the default is unmet, stop at the exception workflow. Do not turn a failed requirement into an informal backlog item.

If the route is still unclear, begin with asset and dependency inventory, then threat modeling. Unknown assets and unstated assumptions make every later security decision weaker. Once the route is clear, the next chapter supplies the principles for turning that decision into an engineering default, review question, and operating check.