Use this severity and money-flow decision table
Read the vector before the number. Access requirements, user interaction, privileges, and impact explain the base score. Then draw the route from the flaw to a real payment, balance, or data object in your product. That route sets local urgency.
| Item | Check or owner | Evidence |
|---|---|---|
| CVSS vector | Technical exploit properties | Keep full vector, not score alone |
| Money movement | Can funds leave or be reassigned? | Trace authorization path |
| Exposure | Is the affected route reachable? | Check active deployment |
| Compensation | What blocks misuse now? | Verify with test |
Test and retest
Record a technical score and a separate business priority. A high score on an unreachable old host can have a different repair order from a lower score on an active payout API. Document the evidence for both decisions and test any proposed compensating control.
Evidence to keep
Write a decision note beside the CVSS vector: who can reach the affected path, whether it is deployed, what object can change, and what independent control blocks it. Test the blocking control before reducing urgency. If the answer depends on a manual finance review, state when that review runs and what it sees. A control that catches bad payouts next week may limit loss but does not prevent an unauthorized payout today. Keep that difference visible in the priority call.
Read the vector before setting priority
Synthetic example: a public API endpoint leaks the last four digits of a beneficiary account for another customer. A separate staff-only bug can change the full beneficiary account before payout. A single base score cannot tell a payment team which fix to release first. Read each CVSS v4.0 vector: attack path, needed rights, user action, vulnerable-system impact, and later impact on another system. Then record the local facts: which version is live, which role can reach it, whether payouts use the changed value, and whether a control blocks the action.
FIRST separates Base, Threat, and Environmental metrics in the CVSS v4.0 specification. Keep the published Base vector as the source assessment. Record any local Threat or Environmental metrics in a labeled assessment, then add business priority with an owner and reason. A verified path to changing a payout destination deserves an urgent business decision even if another issue has a higher Base number. Retest the real payout path after repair.
Show how the metrics affect the decision
CVSS v4.0 can report Base alone or combine it with Threat and Environmental metrics. Label the score type and keep the full vector for each assessment. Environmental metrics describe deployment conditions; Threat metrics describe facts such as exploitation. A local reassessment is valid when its changed inputs and method are recorded. Preserve the vendor’s original vector beside it rather than silently replacing it.
For a synthetic payout flaw, write the impact chain without inventing a number: signed-in customer can edit recipient; payout release reads that edited value; stale approval is accepted; sandbox provider receives the new account. Check each link. If the worker rechecks the frozen recipient and blocks the call, the claimed money path is incomplete. Save that guard’s test before changing repair priority.
Business priority also needs amount limits, affected customer count, active misuse, detection delay, and a fix owner. These facts guide the response even when they sit outside CVSS. A daily reconciliation alert detects a payout after release; it does not prevent it. Use that timing to choose containment and retest. FIRST’s consumer guide explains score interpretation and local context.