# From findings to decisions

**Status: proposed whitepaper outline — unpublished.**

This is original working material for editorial review, not a published whitepaper, a PDF, empirical research or a required operating procedure. Local outline staged on 28 September 2026 (India Standard Time). No publication date has been assigned.

## 1. Evidence — establish the finding

Start with the observation, not the headline severity. Describe the affected asset, the observed behaviour, when it was checked and the limits of the assessment. Separate a demonstrated condition from an inference or an untested possibility.

Questions to develop:
- What was actually observed, and by whom?
- What evidence can an authorised reviewer inspect?
- Which assumptions still need validation?
- Is the finding reproducible within the agreed testing scope?

Proposed output: a short, reviewable finding statement with evidence references and explicit unknowns. Do not put credentials, secrets or unnecessary personal data into a decision record.

## 2. Context — connect it to the environment

Describe why this finding needs attention in this particular setting. Identify the service owner, the business activity involved, relevant access paths and any controls that still need to be checked. Do not substitute a generic severity label for this context.

Questions to develop:
- Which service, dependency or user group could be affected?
- Is the relevant component present and exposed here?
- What information could change the priority?
- Which claims about mitigating controls have been verified?

Proposed output: a context paragraph that distinguishes evidence, assumptions and unanswered questions.

## 3. Options — make the trade-offs explicit

Compare reasonable actions: remediation, a temporary mitigation, further investigation, or a documented exception requiring appropriate approval. Record why an option is being considered without implying that it is automatically acceptable.

Questions to develop:
- What does each option change, and what remains unresolved?
- What dependencies, testing or operational constraints matter?
- Who has authority to approve an exception?
- When should a temporary decision be reconsidered?

Proposed output: a decision with a rationale, alternatives considered and a named approver where required.

## 4. Owner — turn the decision into a commitment

Separate responsibility for implementation from authority to approve the decision. Agree a next checkpoint and the evidence expected there. Record blockers as open issues rather than hiding them behind a completion percentage.

Questions to develop:
- Who owns the next action?
- Who needs to review or approve it?
- What dependency could prevent progress?
- What date has the responsible team actually agreed?

Proposed output: one next action, one accountable owner, an agreed checkpoint and an escalation contact.

## 5. Closure — define what would count as done

Decide what evidence would support closure before marking the finding closed. Describe the validation scope, the reviewer and any residual uncertainty. A completed change request is not, by itself, a statement about the outcome of testing.

Questions to develop:
- What would be rechecked, and under what authorisation?
- Who reviews the result independently of the implementation, if needed?
- What remains open after the action?
- What later change would trigger a new review?

Proposed output: a closure decision with validation evidence, limitations and a reopening trigger.

## Decision record — a blank discussion template

- Finding reference:
- Observation and assessment scope:
- Evidence references and observation date:
- Known facts:
- Assumptions and unanswered questions:
- Affected service and owner:
- Context that influences priority:
- Options considered:
- Decision and rationale:
- Decision authority / approver:
- Next action and accountable owner:
- Dependencies or blockers:
- Agreed review checkpoint:
- Validation scope and reviewer:
- Closure evidence and remaining uncertainty:
- Reopening or exception-review trigger:

Use references to evidence held in an approved location, rather than copying sensitive material into this template.

---

**Before any publication:** validate the terminology with practitioners; obtain permission for any future examples; identify and check external sources for factual claims; review the outline with the product and editorial owners. No customer outcomes, statistics, certification claims or invented case studies are included in this draft.