Describe a business-logic finding by naming the specific action an actor can cause, the asset or customer process affected, the condition required, and the outcome supported by evidence. Put any wider financial, operational or regulatory consequence in a separate conditional sentence with the missing evidence named. Do not turn “could be abused” into “was exploited,” or a single demonstrated case into an unlimited loss estimate. Keep technical severity, practical difficulty, confidence and business priority as separate judgments.
The description changes when new evidence arrives. A source path may support a plausible way to hold reservations too long. A controlled observation may show that one synthetic reservation stayed unavailable past its limit. Neither alone proves thousands of customers were denied service or that revenue was lost. OWASP's reporting guidance asks for exploitability, impact, affected functions and remediation, while OWASP API6:2023 explains why impact in a sensitive business flow depends on the business model.
Use a six-part impact statement
Copy this structure into a review note or ticket:
Actor and access: [who can initiate the action and what they need].
Rule and deviation: [what the product allows and what the reviewed path permits instead].
Supported effect: [the direct asset or workflow change shown by source or controlled observation].
Scale boundary: [one object, one account, a rate limit, a time window, or what is unknown].
Business consequence: [plain-language consequence tied to the affected process, labeled conditional if not observed].
Evidence and next check: [revision, deployment, observation, missing fact, owner].
Add the technical verdict separately: candidate, investigation, verified finding, rejected claim or fixed after reassessment. A category label such as “business logic” does not substitute for a verified mechanism. MITRE's CWE-840 is a category, not a specific weakness by itself; the underlying mistake may involve access control, workflow order, input validation or arithmetic.
Filled example: a reservation hold that outlasts policy
Illustrative service, policy and numbers: Seabrook Classes sells ten seats in a workshop. Its stated policy permits one unpaid hold per account for an absolute ten minutes from creation, with no renewal. The intended purpose is to give a customer time to check out without locking inventory indefinitely. A source review at revision SAMPLE-130 finds that the “refresh checkout” path sets a new expiry based on the refresh time without checking the original deadline. No production requests or customer losses were observed.
A restrained filled impact note is:
Actor and access: a signed-in customer with an active unpaid reservation.
Rule and deviation: Seabrook intends one hold that expires ten minutes after creation; the reviewed refresh path appears to extend expiry past that absolute deadline.
Supported effect: source review supports a path by which a seat could remain reserved longer than policy allows. It has not shown that a seat was actually held beyond ten minutes in the deployed service.
Scale boundary: one hold was traced in source. The maximum number of simultaneous holds per account, cross-account controls and rate limits are not yet established.
Business consequence: if the path is reachable in the selected deployment, other customers may see fewer available seats while an unpaid hold persists. Lost sales and broader inventory exhaustion are unmeasured possibilities, not observed outcomes.
Evidence and next check: review the deployed refresh handler and reservation store at SAMPLE-130; product owner confirms the absolute no-renewal policy; an authorized tester checks expiry with synthetic reservations and no real inventory.
This note lets a product owner understand why the behavior matters without requiring an inflated severity word. It also gives a developer a concrete condition to inspect. If a downstream store caps the total hold time, that counterevidence may defeat the claim. If a controlled test confirms repeatable long holds, update the supported effect and evidence, then consider the actual concurrency and inventory scope. Do not silently change “may” to “did” across all customer accounts.
Separate four decisions that often get collapsed
| Decision | Question | Seabrook example |
|---|---|---|
| Evidence status | Is the actor-to-effect path independently supported? | Source path exists; deployment and actual hold effect unresolved. |
| Technical severity | What direct confidentiality, integrity or availability consequence can successful exploitation cause under a stated scoring method? | Potential effect on seat availability needs bounded facts before a score. |
| Practical difficulty | What access, timing, knowledge and controls would a person need? | Signed-in account and active hold known; rate and account limits unknown. |
| Business priority | When should this team act, given workshop demand, ownership and competing work? | Product owner may prioritize near an event; that does not alter technical evidence. |
FIRST's CVSS v4.0 specification separates Base, Threat and Environmental metrics and instructs assessors to constrain impact to a reasonable outcome they are confident an attacker can achieve. Its user guide explains how environment-specific context affects scoring. CVSS is useful when the organization applies it consistently, but a CVSS number is not a measured revenue loss, nor does it replace the product owner's scheduling decision. Do not invent a vector when the prerequisites and effect are unsettled.
Practical difficulty is also distinct from a theoretical worst case. A path requiring a paid account, precise timing and a narrow inventory window differs from one any visitor can repeat at scale. Those facts should be written out, not hidden inside “high” or “critical.” Conversely, a modest per-action effect can become important if a permitted actor can repeat it widely; establish the repeatability and limits rather than assuming them.
Review steps before publishing the wording
- Pin the rule. Ask the product owner what behavior is intended and where that rule is recorded. A strange workflow may be a supported feature.
- Trace the smallest supported path. Name actor, input, state, control and direct effect at an immutable revision. Seek the control that could defeat the concern.
- Mark the evidence type. Distinguish source review, configuration review, controlled validation and observed production incident. A code citation establishes code, not an executed exploit.
- Bound the population. Identify whether the effect applies to one object, one role, one account, one deployment or an unknown set. Do not multiply an unproven per-object effect by the whole customer base.
- Write two consequence sentences. First state the direct supported effect. Then state a plausible wider business consequence as conditional and say what measurement would establish it.
- Assign the next fact. Product confirms the rule; engineering identifies deployed control and rate limits; an authorized reviewer validates a synthetic case if needed. Give each unknown an owner.
A useful falsifier for Seabrook is “the reservation store enforces an absolute hold expiry unaffected by checkout refresh.” If evidence supports that, revise or reject the suspected prolonged-hold claim. Another finding might remain if refresh creates a different effect, but it needs its own actor-to-effect trace. If the only evidence is that repeated refresh calls are possible, do not claim the seat remains unavailable.
Edit the claim as the evidence changes
Start with an intentionally bad synthetic headline:
“Any user can indefinitely exhaust all seats and cause unlimited revenue loss.”
Four unsupported jumps are hidden in it: signed-in becomes any user; one hold becomes all seats; a refresh branch becomes indefinite operation; and unavailability becomes measured lost revenue. The source evidence supports a much smaller statement: “The checkout refresh path appears to extend one unpaid hold past the product's absolute deadline.”
Now introduce two additional invented evidence packets. They are assumed inputs to this writing exercise, not tests the author ran. Packet A describes an authorized synthetic validation in which a hold created at 10:00 remains unavailable at 10:12 after refresh, despite a 10:10 policy deadline. Packet B identifies an enforced maximum of one active hold per account. The revised direct-effect sentence becomes:
In the supplied synthetic validation record, a signed-in account kept one seat reserved for at least two minutes beyond the ten-minute deadline by refreshing checkout. The current account limit permits one simultaneous hold; bypass of that limit and multi-account scaling have not been established.
“At least two minutes” is supported by the 10:12 observation. “Forever” is not. One account can affect one of the workshop's ten seats under the stated limit; that does not prove an attacker can control ten accounts, hold ten seats or prevent a sale. The deadline violation remains actionable even after the scale claim shrinks.
The same facts support two useful outputs:
| Audience | Filled wording |
|---|---|
| Engineering ticket | Refresh derives expiry from current time instead of enforcing creation time plus ten minutes. Preserve the absolute deadline across refresh and make availability/payment admission honor it even if the cleanup worker runs late, while ordinary checkout before the deadline works. Validate the current deployed path and inventory reconciliation. |
| Product lead | A customer can retain one unpaid seat beyond our advertised hold policy in the supplied synthetic case. We have not measured lost sales or shown larger-scale exhaustion. Prioritize the deadline correction before the next high-demand workshop; that scheduling choice reflects event sensitivity, not a new technical severity fact. |
Do not silently promote the example to a verified production finding. A real note should identify its source or validation record and build; record independent review separately when it occurred. The exercise shows how evidence can strengthen the direct effect and narrow its scale at the same time.
Show leadership what would change the impact statement
Seabrook's next evidence should answer a bounded question. To establish the direct deadline defect, inspect the deployed refresh and availability decisions for one synthetic hold. To establish wider scale, inspect account limits and whether a permitted actor can create additional independent holds. To estimate commercial consequence, obtain actual demand and inventory context. Those are different evidence tasks; completing one should update only the corresponding sentence.
If the product owner says renewal is intentionally allowed, revisit the original rule before retaining the finding. The behavior may still need clearer limits or product wording, but an inconsistency with an assumed no-renewal policy is no longer established. Record the policy change or clarification rather than retroactively claiming the scanner knew the intended business rule.
The same care applies after a repair. A corrected deadline can close the supported source path while historical misuse remains unknown. A lack of available logs does not prove that no seat was ever held too long. The final note should separate repaired behavior, assessed deployment, and any incident question the organization chose to investigate.
A short decision table can help the owner: enforce the absolute deadline; preserve normal checkout until that deadline; define treatment of a payment completing afterward; and name the evidence needed before restoring any temporarily restricted flow. This translates the impact statement into engineering and product decisions without adding an unsupported monetary figure.
The resulting priority may still be high before a popular workshop. That is a reasonable scheduling judgment based on the business calendar. It should remain visibly separate from the evidence that one signed-in account can extend one hold under the supplied synthetic conditions.
For an unresolved Seabrook claim, the next action is to confirm the absolute expiry behavior and the deployed route. If the issue becomes a verified finding, attach the filled impact note to the remediation handoff and update it when controlled evidence changes the boundary. Use the alert-to-claim guide to resolve the path, then the prioritization guide to schedule verified work without rewriting technical severity as business urgency.