Short answer: Describe the consequence of a successful attack and the effort required to make it happen in two separate statements. Business impact asks what customers, operations, or commitments would be harmed if the path worked. Exploit difficulty asks what access, knowledge, prerequisites, and controls an attacker must get past. A high-impact, difficult path may deserve a planned fix and close monitoring; a lower-impact, easy path may deserve a quick fix; a high-impact, easy path usually demands immediate attention. The choice changes when either the business context or the attack path changes. Never let a single severity label conceal those reasons.
This guide helps a security leader and engineering manager discuss a limited fix budget. It presumes the technical claim has been reviewed and that uncertainty is visible. A source-supported path is not the same as an observed exploit, and an unverified scanner claim should be investigated before it is placed in a confirmed fix queue.
Two questions, two owners
The technical reviewer can usually describe what the flaw permits, which actor reaches it, and what controls exist. The service or business owner is often needed to explain the affected customer workflow, data sensitivity, service importance, and recovery cost. OWASP's risk rating methodology distinguishes technical and business impact and says business impact may require people who know the business. NIST's risk assessment guidance likewise treats likelihood and impact as distinct parts of a risk assessment.
Write the impact in concrete terms. “Integrity loss” is a category; “a customer could alter another customer's payment instructions” is a business-relevant possibility. State the conditions and avoid claiming that fraud occurred. “Sensitive data exposure” is vague; name the data type, who could see it, and the plausible scope. If those details are unknown, ask a business owner rather than inventing a number of affected customers or a monetary loss.
Write difficulty as the attacker path. Can an ordinary user register? Must the attacker be a tenant administrator? Is a target ID normally visible? Does the route require another person's action? Is an effective control deployed? How many independent conditions must line up? CVSS v4.0 has metrics for some of these properties, but its published Base score does not know all your deployment details. Keep practical difficulty as an evidence-backed local field.
Interview the workflow owner before naming the loss
Constructed case; no customer incident, loss or executed review is claimed. Assume the source and policy evidence establishes that an ordinary customer can edit another account's payment-instruction draft. The account-bound control is absent on the supplied path. The attacker prerequisites are settled for this exercise; the business consequence is not.
The first impact sentence says “an attacker can redirect customer payments.” Finance challenges it. A short interview supplies the missing workflow:
| Security question | Finance/operations answer in the exercise | Impact implication |
|---|---|---|
| Which record does the flawed route change? | A pending instruction draft, not the approved settlement instruction. | Integrity of the draft is affected; direct settlement redirection is not yet established. |
| What promotes a draft into settlement? | A different finance approver must compare it with an out-of-band account-change request. The attacker cannot perform that approval. | A checked independent control interrupts the proposed automatic-payment consequence. |
| What happens when a mismatch is found? | The instruction is held for investigation and the customer's settlement may be delayed. | Operational disruption and reconciliation work remain plausible harm. |
| Can the original state be recovered? | Prior approved instructions are retained; drafts can be rebuilt from the authorized request. | Recovery is possible, but it consumes staff time and does not excuse the unauthorized edit. |
| How many drafts are reachable? | Not established by this review. | Leave scale unknown; do not invent a loss estimate. |
The revised impact note is:
An ordinary customer can corrupt another account's pending payment-instruction draft. The supplied approval workflow prevents that draft from directly changing settlement details without a separate finance decision. The supported business concern is payment delay, reconciliation work and loss of trust in draft instructions; direct funds redirection is not established. Affected scale and actual abuse are unknown.
The attacker still has the same ordinary-account path. Its practical difficulty did not increase merely because Finance narrowed the downstream consequence. The impact chain changed: unauthorized draft write → review discrepancy → held settlement, rather than unauthorized write → automatic funds movement.
Choose between two real consequences
Compare that flaw with an approved audit-export issue: a tenant administrator with the required fresh second factor can retrieve another tenant's audit records. The export is direct and disclosure cannot be undone by restoring a database row. Assume the exported fields include private operational history; no customer count is supplied.
The team has one fix slot. Finance prefers the payment-draft fix because settlement is approaching. The security lead prefers the audit-export fix because its disclosure path has no equivalent downstream approval barrier. The completed decision is to fix the audit export first, temporarily freeze payment-instruction draft edits through the affected route, and schedule the payment fix next. Operations accepts a manual authenticated change process for the short restriction period, with an expiry and owner.
This is not a universal ordering. It is a decision with an explicit tradeoff: direct irreversible disclosure gets the engineering slot, while a reversible route restriction protects payment drafts at an operational cost. Record Finance's objection and the agreed restoration condition instead of editing the technical ratings until everyone appears to agree.
If the approval check later proves advisory rather than mandatory, reopen the payment impact immediately. If an automated process promotes drafts without that check, the earlier consequence boundary no longer holds. The useful follow-up question is “what actually reads and approves this field?” rather than “is payment data high impact?”
Use OWASP's distinction between technical and business impact as a prompt for this conversation, not a substitute for the supplied workflow. The owner of the business process must validate the chain before it is used to make a real priority decision.
Estimate difficulty without turning assumptions into facts
Ask the security engineer to provide: actor and starting privilege; reachable entry; required identifiers or knowledge; feature, timing, and configuration prerequisites; each control and its evidence; effort and repeatability; alternate paths considered; and what remains unknown. A statement such as “hard because it needs authentication” is weak. A legitimate customer account may be easy to obtain. A statement such as “blocked by MFA” is also incomplete unless the MFA applies to the exact sensitive action and the tested deployment.
Be equally careful with outside threat signals. EPSS estimates the chance that a published CVE will be exploited in the wild in the next 30 days. It does not know the business impact of your customer workflow and it does not apply directly to custom flaws without a CVE. A CVSS Base score may encode general impact and attack properties, but it is not a business owner's priority instruction. Threat data can raise urgency; it cannot replace your asset and path review.
Use a consequence chain to avoid invented loss estimates
When a stakeholder asks for a financial amount, begin by separating what is known from what would have to happen next. The payment-draft flaw permits an unauthorized draft edit in the exercise. A financial loss estimate would also need facts about approval failure, transaction value, frequency, detection, recovery and who bears the loss. Multiplying an imagined transaction count by an imagined average payment does not make the impact statement more rigorous.
Use a short chain instead:
| Stage | Established in the exercise | Further evidence needed for a stronger claim |
|---|---|---|
| Unauthorized action | Customer can alter a foreign pending draft | Already supported by the technical packet. |
| Workflow consequence | Mandatory approver detects mismatch and holds settlement | Effective approval and escalation procedure. |
| Operational burden | Staff must reconcile the draft and authorized request | Work owner and realistic recovery steps. |
| Monetary loss | Not established | Actual amounts, delay consequences and failed recovery or control conditions. |
The chain makes a bounded estimate possible if the organization needs one. The process owner can estimate staff effort for a synthetic recovery scenario, label the assumptions and show a range. That is a planning exercise, not an observed incident cost. Preserve the distinction in any leadership summary.
For the audit-export flaw, recovery has a different meaning. Restoring a database record does not retract information already received by another party. That supports the importance of the disclosure boundary, but it still does not establish the number of recipients or records actually exposed. Ask for the export schema and reachable selection scope before describing a customer-wide event.
Revisit priority when the business process changes
A new automated promotion from draft to settlement could remove the approval boundary that limited the payment case's consequence. The source defect need not change for its business impact to increase. Link the finding's assumptions to that planned workflow change so Finance and engineering revisit the decision before launch.
Conversely, a business deadline can change the cost of temporarily restricting the route without changing the flaw's technical effect. Record that operational cost in the response choice. If the manual authenticated process cannot scale during settlement, the owner may need a faster permanent repair or additional support capacity. Do not conceal that problem by relabeling the security issue low severity.
At the review checkpoint, ask which link in the consequence chain changed. This keeps the conversation concrete and helps people disagree about the right thing: technical permission, downstream control, operational disruption or work allocation. A shared label such as “high impact” is useful only when the underlying consequence remains understandable.
Make the priority decision auditable
Keep the original technical assessment unchanged when a stakeholder changes the order. For the payment-draft case, the short record is:
Technical status: approved unauthorized draft edit in the exercise. Impact: draft corruption, possible settlement delay and reconciliation; direct funds redirection not established under the mandatory approval workflow. Difficulty: ordinary account and a target draft ID, as established in the technical packet. Work: restrict the affected edit route now; audit-export fix takes the current engineering slot; payment fix has the next accepted slot. Authority: operations accepts the temporary manual workflow; engineering accepts delivery; security owns the technical verdict. Trigger: approval bypass, changed settlement workflow or failed restriction.
This record also lets someone challenge the right part. A developer may show that a mandatory policy blocks the payment-draft write, changing the technical verdict. The business owner may show that the audit export contains more sensitive material than first described, changing the impact without changing the attacker prerequisites. Keep the reasons versioned and date the evidence. Risk acceptance, if chosen, is a separate authorized decision; it does not turn a vulnerability into a fixed one.
At the next planning meeting, ask each issue owner for one impact sentence and one attacker-path sentence, then decide which missing fact could reverse the order. Use the full limited-capacity queue method to allocate work, and the attacker-prerequisites guide when difficulty is disputed.