Risk Rating and Security Requirements

Chapter 7 left the refund service with a residual path: replay defenses stop a duplicate command, but they do not stop a compromised operator from creating several distinct, valid refund decisions. The review now has to answer a harder question than “Is this bad?” It must decide how bad, what must change, whether release can proceed, and how long the organization may remain exposed.

Suppose the facts are these. The console is reachable only through the corporate identity provider. Refund operators may issue up to $10,000 per transaction without a second approval. The payment worker accepts any correctly authorized decision, and no aggregate limit constrains one operator. A daily reconciliation would eventually reveal excess refunds, but there is no real-time alert. Money can usually be recovered through a manual process; customer trust and investigation time cannot.

One reviewer calls the path critical because it changes money. Another calls it medium because an attacker first needs an operator session. Neither label is yet a decision. A defensible rating begins when both reviewers use the same scenario, the same evidence, and the same rules.

Build the record before choosing the color

Begin with an actor, an action, an affected system, the conditions that make the action possible, and the resulting harm. Rate that scenario, not a scanner finding, weakness category, or control name. “Insider abuse” is too broad to rate. “An attacker using a current refund-operator session creates many valid refund decisions without secondary approval” is concrete enough to investigate.

Then record nine dimensions in ordinary language:

• Impact: the plausible harm to people, money, confidentiality, integrity, availability, safety, commitments, or operations.
• Likelihood: the chance of this path during the decision period, based on observed activity and credible prerequisites rather than intuition alone.
• Exposure: who can reach the relevant surface: the internet, a partner, another tenant, the workforce, a narrow administrator group, or only a local process.
• Exploitability: the skill, access, timing, user action, tooling, and repeatability the path requires.
• Data sensitivity: the credentials, secrets, personal data, regulated records, or other protected material the path can reach.
• Business criticality: the revenue, identity, production-control, safety, or customer function that depends on the system.
• Privilege: the authority gained or abused, including administrative, cloud, CI/CD, service, tenant, and data-plane rights.
• Detectability: the probability and speed of discovering the action from a signal someone actually watches.
• Recovery: the work needed to contain the path and restore trustworthy state, including key rotation, rebuild, reconciliation, notification, and correction.

For the refund path, financial integrity and customer impact are significant. Exposure is narrow but real: every refund operator has the necessary reach. Exploitation requires a current session, yet after that prerequisite the action is ordinary and repeatable. The workflow is privileged, detection may lag by a day, and recovery requires investigation and reconciliation. The recoverable money and restricted entry point constrain the impact; they do not erase the path.

A heat map can summarize impact and likelihood after this analysis. It cannot perform the analysis. When a reviewer points to a colored cell, ask which recorded fact placed the scenario there and which fact would move it.

A severity method two reviewers can repeat

Use the following calculator as a decision record, not as arithmetic theater:

Scenario:
Decision period:
Evidence timestamp:

Impact and affected parties:
Likelihood and observed activity:
Exposure and reachability:
Exploit prerequisites and repeatability:
Data and business criticality:
Privilege gained or abused:
Detection coverage and delay:
Recovery path and irreversible harm:

Enforced, tested compensating controls:
Material unknowns, owner, and answer-by date:
Severity and rule used:
Remediation class and policy due date:
Required controls, verification, and evidence:
Residual risk and accepting authority:
Revisit triggers:

Anchor the labels to decisions. Critical means severe harm has a current or low-barrier path: exploitation is active, readily repeatable, broadly exposed, or able to cross a consequential privilege or tenant boundary. Treat it as an emergency or a release blocker. High means a credible path can cause significant harm, although meaningful prerequisites, narrower reach, or containment keep it below critical. Give it priority work, an owner, and an explicit release decision. Medium means the weakness is material but its impact or reach is limited, or exploitation depends on substantial conditions that evidence supports. Plan and verify the repair. Low is a small or genuinely remote defense-in-depth gap. Informational records a useful observation that is not a present vulnerability.

Apply a few rules consistently:

1. Confirmed or strongly suspected exploitation enters incident handling and the emergency decision path. Do not average it down with favorable dimensions.
2. Severe impact plus a credible, reachable path is at least high. Severe impact plus low barriers, broad reach, or consequential privilege is critical.
3. Credit a compensating control only when it covers this path, is enforced, has been tested, and produces a signal someone owns. A planned control is a requirement, not a reduction.
4. Do not turn missing evidence into a favorable assumption. Record the uncertainty, assign an owner and answer-by time, and use the more protective release posture until the answer arrives.
5. Keep issue severity, service assurance, and remediation class separate. A critical service can contain a medium issue; a baseline service can expose a critical path.

Under these rules, the refund scenario is high: the path is credible and repeatable once a privileged session is obtained, its financial and customer impact is significant, and detection is slow. Narrow workforce exposure, transaction limits, and recoverability keep the stated facts below critical. Remove the per-transaction cap, observe active session theft, or discover that one operator can reach unrestricted payment credentials, and the rating becomes critical. Add enforced aggregate limits, secondary approval, prompt anomaly detection, and tested revocation, and the residual rating may fall.

The two reviewers do not have to share a temperament. They have to show which fact and rule support the label. A disagreement that survives this record usually reveals a missing fact or an ambiguous policy boundary worth fixing.

Put vulnerability scores in their proper place

A component score describes properties of a vulnerability; it does not know whether this application loads the component, exposes the vulnerable path, grants it privilege, or protects data that matters here. Use vendor severity and a standard score as inputs, then add current exploitation, exploit maturity, deployment reachability, asset context, compensating controls, and the available response.

Walk a component finding in this order:

1. Check for confirmed exploitation in your environment and credible reports of exploitation elsewhere.
2. Establish whether the vulnerable code or configuration exists in the deployed artifact and whether the path is reachable.
3. Record external, tenant, partner, internal, and privileged exposure.
4. Test the exploit prerequisites against the actual configuration and runtime authority.
5. Identify affected data, downstream systems, and business functions.
6. Verify compensating controls and their monitoring; do not infer them from an architecture diagram.
7. Choose the fastest safe response: patch, configuration change, feature disablement, isolation, rollback, or another tested control.

This is why a medium library issue proven unreachable belongs in the normal backlog with an update plan, while an exploited edge vulnerability enters the emergency path even if a scanner happened to give both findings similar colors. Preserve the reachability evidence and revisit it when the build, feature flags, runtime loading, or deployment topology changes.

Turn the rating into requirements

A label cannot change a system. The refund record must produce requirements that name the protected behavior and how the team will prove it. For example:

The refund console MUST require approval by a second eligible operator when one refund or an operator’s rolling total exceeds the configured risk limit. The commerce team owns enforcement at the authoritative refund decision, tests same-operator, concurrent, boundary-value, and worker-bypass cases, and stores the results with the release review.

That sentence has scope, normative force, an owner, an enforcement point, verification, and evidence. “Improve refund controls” has none of them.

Requirements also arrive from outside the threat model. Data classification determines protection, retention, logging, and deletion rules. Laws, regulatory obligations, contracts, and customer commitments impose promises that the system must meet, though the team should confirm their interpretation with the appropriate legal or compliance owner. Operational constraints require safe rollback, isolation, recovery, and observability. Incidents turn observed failures into new controls. The service assurance level sets the default depth of review and proof.

Keep the release-significant chain compact enough to inspect at once:

The table earns its space because a reviewer must compare every requirement across the same chain. It is an index into code, tests, detections, and records—not a claim that those things exist.

Set the service’s assurance level once

An assurance level applies stable defaults to a service; it should not be reinvented for each finding. A baseline service has low-sensitive data and limited blast radius, and carries the minimum security bar, ownership, inventory, logging, and dependency hygiene. A sensitive service is internet-facing, handles confidential data, integrates with partners, or exposes a privileged internal workflow; it needs a threat model, stronger access review, data-flow controls, and release security review.

A critical service supports revenue, identity, tenant isolation, production control, regulated processing, or a core customer commitment. It needs formal review, high-priority telemetry, recovery testing, an emergency remediation path, and explicit risk ownership. High assurance is reserved for systems where failure can threaten safety, financial integrity, critical infrastructure, signing or key authority, or broad administrative control. Independent review, stricter change control, stronger evidence, deeper testing, and narrow exception authority are appropriate there.

The refund service is critical because it changes financial and customer state. That classification raises its standing requirements and the authority needed for an exception. It does not automatically convert every issue in the service to critical severity.

Convert severity into a clock

Publish a small set of remediation classes and bind each class to dates in organizational policy. The class expresses response posture; the policy supplies the exact clock.

• Emergency: contain or remediate now. Use it for active exploitation and critical exposed paths; engage incident and risk owners, and block release when the unsafe path would ship.
• Expedited: place a critical but not currently exploited issue on a fixed short schedule with compensating controls, monitoring, and leadership-visible ownership.
• Priority: assign a high issue to named work with a due date, test evidence, and an explicit decision about any imminent release.
• Normal: carry a medium issue in the planned security backlog with evidence for the conditions that lowered urgency and a verified update plan.
• Opportunistic: repair a low issue through maintenance or control-maturity work without pretending that it outranks consequential paths.

Thus an exploited vulnerability on an internet-facing service takes the emergency path. A critical but non-exploited vulnerability on a sensitive internal system is expedited. The high refund path is priority work unless new evidence raises it. The unreachable library issue is normal, with its reachability proof attached.

If the policy due date cannot be met, the team has not created more time; it has requested an exception. Record the accountable risk owner, the reason, enforced compensating controls, detection and containment paths, expiration, reapproval condition, and the event that ends the exception early. An exception without an expiry quietly rewrites policy.

Keep one set of facts through every conversation

The risk record is the source. Each audience receives the part needed for its decision.

The engineering task names the console and worker enforcement points, the precise behavior to build, boundary and bypass tests, owner, due date, and rollback risk. The security review receives the scenario, high rating, assumptions, required controls, residual risk, and evidence links. An executive summary can say: “A stolen refund-operator session could issue repeated valid refunds before daily reconciliation. Exposure is restricted to workforce identities, no abuse is known, and the decision is high/priority. Aggregate limits, secondary approval, and real-time detection are due before the named release.”

If exploitation is suspected, the incident bridge needs current facts, containment, known customer impact, the next decision, its owner, and the next update time. Any customer communication must state confirmed scope, action taken, customer action if any, and only commitments the organization can honor. Legal and incident leaders should review it. The customer should not receive speculation disguised as certainty.

Changing the level of detail is useful. Changing the underlying severity or facts because an audience finds them uncomfortable is communication drift.

Carry the decision into architecture review

Before this risk enters Chapter 9’s review packet, another reviewer should be able to reconstruct it without asking what the author meant. The record should contain the concrete scenario; timestamped evidence for impact, likelihood, exposure, exploitability, data, criticality, privilege, detectability, and recovery; the severity rule applied; requirements with owners and proof; the remediation class and policy date; any expiring exception; and audience summaries derived from those facts.

Risk rating cannot make uncertain futures precise. It can make present judgment inspectable. For the refund service, the useful result is not the word high. It is the chain from a compromised session to enforced limits, independent approval, visible abuse, owned recovery, and a release decision that the next reviewer can verify.