Guide 040 template

How to communicate residual risk after a partial fix

Communicate a partial repair by naming the protected and remaining paths, operational tradeoffs and next owner without claiming an unsupported risk percentage.

Tell stakeholders what harmful action may still be possible, who could attempt it, what the partial fix now prevents, and what decision is needed next. Keep those facts separate from uncertainty. A merged patch, fewer alerts or a lower score is not a complete risk statement. If one path is verified fixed and another remains, say “partially fixed” and keep the finding open for the remaining path. If the second path is only suspected, label it unresolved and name the evidence needed. The security leader's update should be short enough to act on, with a technical appendix available to authorized reviewers.

Residual risk is about the conditions that remain after a control changes. FIRST's CVSS v4.0 specification separates the intrinsic severity of a vulnerability from environment-specific mitigations and says business factors can sit outside the score. A lower environmental score can inform a decision; it cannot tell a stakeholder which customer data or workflow is still at risk.

Work through an illustrative partial fix

Illustrative case, not a customer incident: ValeDocs lets account members download their own document exports. An approved finding at revision V3 traced an account-ownership gap in two paths: an interactive download route and a scheduled bulk-export job. In the source-supported scenario, a caller who can name another account's export might get that account's document. No live exploit is claimed in this example.

At revision V4, the interactive route now checks the export's owning account against the caller's account. A separate reviewer confirms that source path, an authorized staging check with synthetic accounts sees the intended own-account download succeed and the cross-account request denied, and the release owner maps V4 to the active interactive-route artifact. The scheduled job still calls the old retrieval helper. A scheduler permission policy changed between V3 and V4, but its effective enforcement and the member-controlled parameter flow have not yet been reassessed at V4. The job path was part of the approved V3 finding; the new policy is a possible fix that still needs positive evidence. The team has fixed one known entry path but cannot claim that the harmful action is impossible through all paths. OWASP's Authorization Cheat Sheet recommends checking access to each resource rather than relying on a user's general authentication.

There are two possibilities for the scheduled job at V4. If review confirms a member-controlled export ID still reaches the helper without an effective ownership check, the approved finding remains open on that path. If the changed scheduler policy now blocks the original harmful action, record the exact deployed policy and a positive reassessment before closing that scope. Until that check, the fix result is inconclusive and the approved V3 finding stays open; this is uncertainty about a claimed repair, not a newly approved or rejected vulnerability. The example below uses that inconclusive fix state.

Send one short decision request

The evidence ledger below can produce this five-sentence message. All records and assumed outcomes remain part of the constructed ValeDocs exercise, not an actual customer assessment:

Interactive downloads are corrected in the active V4 artifact. Scheduled bulk exports have not yet been positively reassessed against the changed scheduler policy, so the approved finding remains open for that path. If the old member-controlled path still works, another account's document could be delivered; no actual customer access is established here. Please reserve the export owner and AppSec reviewer for the scheduled-path assessment by tomorrow at 14:00 UTC. Operations owns the proposed scheduling restriction and must confirm its enforcement; I will update this decision when that evidence arrives or at the checkpoint.

The requested leadership action is capacity for one bounded assessment. The proposed restriction has an operational owner and an evidence state, rather than becoming a second vague request. The technical appendix holds the revision, route, policy and controlled-check details. OWASP's reporting guidance supports making scope and limitations visible; the opening message need not reproduce the whole review record.

Build the update from an evidence ledger

Before writing the summary, the security lead asks the AppSec and service owners for the following short ledger. It prevents optimistic prose from getting ahead of the review.

Question Evidence needed ValeDocs answer
What was the original harmful action? Approved finding, actor-to-effect path and affected revision Source-supported cross-account document export through two paths at V3; no live exploit observed.
Which path changed? Diff, new immutable revision, current deployment evidence Interactive download changed at V4; staging behavior observed and active artifact mapped.
Which path remains? Caller and control map, not just a scanner label Scheduled job still uses older retrieval helper.
Is the remaining path positively fixed at V4? Independent reassessment of job authority, parameter control, and deployment Not yet; changed scheduler policy and data-layer controls need review, so the approved V3 finding stays open.
What temporary restriction exists? Configuration, owner, deployment and behavior check Operations proposes restricted scheduling; effectiveness pending confirmation.
Who acts next? Named owner and due checkpoint Export-service owner maps job authority; AppSec reviews; operations verifies restriction.

If a row cannot be answered, keep it unknown. Do not replace it with “low likelihood,” “covered by defense in depth” or a single severity label. The OWASP Vulnerability Management Guide describes exception decisions, compensating controls, remediation assignments and audit trails as separate management steps. That separation lets leaders accept a bounded delay without rewriting the technical verdict.

Change the sentence when the evidence changes

Update A: restriction confirmed. Operations supplies the active scheduler policy, producer inventory and a controlled synthetic job check showing ordinary members cannot submit the affected job while the operations group can run its authorized workflow. The new message is:

Interactive downloads remain fixed. The affected scheduled entry is now restricted to the checked operations workflow in the selected deployment; this reduces the ordinary-member exposure while the retrieval helper remains uncorrected. The original finding stays open for permanent repair and any separately identified operations-path issue. Please keep the accepted repair slot; next update follows the corrected artifact or a restriction failure.

That update replaces “proposed restriction, enforcement unknown” with a specific confirmed boundary. It does not say all exports are safe or that the code is fixed. The operations actor's actual object authority still belongs in the technical record.

Update B: deadline passes without evidence. If the owner cannot produce the effective policy by the agreed 14:00 UTC checkpoint, the message changes differently:

Interactive downloads remain fixed. We still cannot establish whether the changed scheduler policy blocks the previously approved member-controlled path. The planned restriction is unverified, so it is not a basis for lowering the remaining exposure. Operations should use its existing response authority to restrict the affected scheduling entry while obtaining the missing evidence today. Please resolve any capacity or business-continuity conflict that prevents that action; AppSec will reassess before restoration or closure.

This asks for a new decision because the earlier checkpoint failed. It does not recycle “monitoring” as if time itself reduced the risk. Any interruption of legitimate scheduling and the restoration criteria should accompany the operational decision.

The two updates preserve the same original approved V3 finding. A missing V4 reassessment does not turn it into a false positive, and an effective temporary restriction does not rewrite its source defect. If a later review establishes a complete permanent repair, issue a separate closure message with its scope and evidence.

Adapt the same facts for engineering and business readers

The technical owner and business owner need different depth, but they should receive the same underlying state. For ValeDocs, the engineering note can name the scheduled job's retrieval helper, the changed policy and the exact artifact still awaiting reassessment. The business note should name the remaining possible cross-account delivery, the current restriction state and the decision needed to finish the work.

Do not make the business version more certain merely to keep it short. “Scheduled exports are mitigated” is shorter than the five-sentence update, but it becomes inaccurate while enforcement is unverified. A concise alternative is: “Interactive downloads are fixed; scheduled-export protection is not yet verified; operations owns the restriction check and engineering owns the remaining repair.” That sentence preserves the operational distinction.

A technical appendix can answer the questions that would otherwise generate a long email chain:

Reader question Evidence reference to retain
Which download path is fixed? V4 route, account-bound query, controlled fixture result and active artifact.
Why is scheduled export still open? Original V3 claim, current helper and unresolved effective scheduler decision.
What does the temporary restriction cover? Current producer/entry inventory and enforcement evidence, or explicit pending state.
What ends the temporary arrangement? Permanent correction, positive reassessment and restoration condition.

The appendix should remain access controlled. Leadership rarely needs raw source or synthetic attack details to choose capacity. Engineers need enough detail to challenge the path; provide it through their authorized evidence system rather than broadening the audience of sensitive material.

Report progress without turning paths into percentages

If one of two paths is fixed, “50% risk removed” is not justified. The paths may differ in audience, data reach, frequency and effect. Report the completed capability and the surviving capability directly. ValeDocs can say that interactive downloads enforce the account boundary while scheduled jobs remain under reassessment. That statement is more informative than a percentage with no defensible unit.

Likewise, separate source completion, rollout and verification. A patch prepared for the scheduled helper is progress; it is not evidence that active jobs use it. A new policy is progress only to the extent its effective attachment and behavior are established. Use those milestones to explain what the remaining slot will accomplish.

At the checkpoint, update the requested decision. If the restriction is now verified, leadership may only need to preserve the accepted repair capacity. If the restriction failed, the next request may concern service interruption or additional engineering help. Repeating the previous request after the facts change makes the update feel procedural and can delay the action actually needed.

The final closure message should explicitly replace the partial status, identify its scope and retain any separate historical-exposure inquiry. Completing the repair does not establish that no earlier access occurred. The communication record should therefore end with a clear technical outcome and any remaining independent work, not a broad claim that the original event never mattered.

Before sending a real update, trace each sentence to the ledger: improvement to new-path evidence; remaining harm to the original approved path and current limits; mitigation to enforcement evidence; request to a named decision owner. Remove adjectives that imply a measured probability when no such measurement exists.

For this week's status report, take one partially resolved finding and write the five-sentence update with one requested decision. Have its technical owner verify every sentence. Then use the compensating-control record for any temporary restriction, and the fix-verification guide before reporting complete closure.