In brief
Review findings with the responsible teams, add business context, assign accountable owners and agree validation before closing actions. Keep accepted risk separate from a technically resolved finding. A closure record should explain what was checked, under which conditions, what remains exposed and who made any residual-risk decision.
1 Confirm the finding and the decision it creates
Ask the assessor to explain the affected asset, supporting evidence, relevant conditions, proposed action and test limitations. Record uncertainty rather than treating a disputed finding as either confirmed or closed. ‘Not tested’ and ‘tested without identifying an issue’ should remain different entries.
The UK National Cyber Security Centre’s (NCSC) penetration-testing guidance places risk assessment and decisions about fixes with the customer. Use the report as evidence for that decision, not as a transfer of ownership to the assessor.
Source: UK National Cyber Security Centre. Penetration testing
Our suggested prioritisation discussion considers technical severity alongside exposure, affected service, data, available access and existing safeguards. The purpose is to explain the chosen action and target, not to silently alter the assessor’s rating or invent a universal remediation deadline.
2 Assign treatment and safe implementation
Name the person accountable for coordinating each finding. Record the proposed treatment, technical contributors, dependencies, target and escalation route. The accountable owner may need to coordinate several teams; assigning a department alone leaves that coordination unclear.
Before a change, consider compatibility testing, operating windows, supplier involvement and rollback arrangements. If a permanent fix is unavailable, document the interim measure, its limits and the decision required from the risk owner. ‘Waiting for the supplier’ describes a dependency, not the complete treatment decision.
The US National Institute of Standards and Technology (NIST) includes prioritisation and installation verification in patch management. Patching is one possible treatment; findings may also require configuration, application or process changes.
Source: US National Institute of Standards and Technology. Guide to Enterprise Patch Management Planning
3 Agree validation and closure states
Specify what the validation owner will check before declaring the finding resolved. Record the environment, version, relevant roles and limitations. A completed change ticket establishes that an action was recorded; it is not, by itself, evidence that the original weakness is no longer present.
| State | Meaning | Decision still needed |
|---|---|---|
| Resolved within tested scope | Agreed validation no longer reproduces the original issue | Record scope and remaining limitations |
| Partly resolved | Some exposure remains or only part of the change was checked | Assign remaining action and owner |
| Unresolved | Finding remains or treatment is incomplete | Prioritise, escalate or seek a treatment decision |
| Unable to verify | Access or test conditions prevented a conclusion | Arrange validation or record the uncertainty |
| Risk accepted | Authorised owner accepts specified residual exposure | Retain approval, conditions and next review |
These labels are our proposed record structure, not an official standard. Do not count accepted risk as a verified technical fix. Keep implementation, validation and risk acceptance as separate decisions even if your tracker presents them together.
4 Work through a fictional closure record
Illustrative example: an assessment identifies an access-control weakness in a fictional customer portal. The application team changes the authorisation logic. The validation owner checks the agreed customer and support roles in the nominated release. No attack instructions or real incident details are involved.
| Record field | Example entry |
|---|---|
| Action owner | Application lead coordinates the corrective change |
| Validation evidence | Assessor records the release, roles checked and outcome |
| Limit of conclusion | An external integration was excluded and remains unverified |
| Finding status | Resolved for the checked path; separate integration question remains open |
| Risk decision | Authorised owner decides treatment of the excluded dependency |
| Review trigger | Reassess when the integration changes or the agreed review falls due |
The example is intentionally bounded. It does not claim that one retest proves the portal or the organisation secure. The excluded dependency needs its own owner and decision; it should not disappear inside an overall closure percentage.
5 Give management a decision record
Report material overdue findings, blocked changes, unverified treatments and exceptions requiring approval. For each, state the business service affected, the remaining uncertainty, the proposed action and who must decide. Use totals to orient the discussion, but retain the important unresolved items.
The NCSC’s vulnerability-management guidance includes prioritisation, ownership of update risk and verification of the process. Use those principles to review the workflow as well as individual tickets.
Source: UK National Cyber Security Centre. Vulnerability management
When a target cannot be met, ask management to choose among an achievable change plan, an interim treatment, a reduction in exposure or an explicit residual-risk decision. Evaluate those options with the responsible technical and business owners. Do not let a missed target become silent acceptance.
What should you do now
- Security lead: confirm material findings and the prioritisation rationale.
- System owner: plan safe changes and identify dependencies.
- Delivery owner: maintain an accountable owner and target for each action.
- Validation owner: record what the check established and what it did not.
- Risk owner: approve or reject residual exposure explicitly.
India and Australia context
For an Indian audit engagement, CERT-In’s 2025 audit guidance identifies scope elements including audit type, assets, reporting, data handling and timelines. Check its applicability to the engagement rather than assuming it governs every purchase.
Source: Indian Computer Emergency Response Team (CERT-In). Comprehensive Cyber Security Audit Policy Guidelines
Australian government vulnerability-disclosure guidance also addresses who tests, what is in scope, confidentiality and how findings are communicated. Use these planning questions to clarify the engagement; the guidance does not establish a universal service package.
Source: Australian Government cyber.gov.au. Vulnerability disclosure programs explained
How Bravewall helps
Bravewall coordinates scoped VAPT and red teaming engagements around agreed requirements. VAPT and Red Teaming
This article is general information for awareness and education. It is not legal, regulatory or professional advice and does not take into account the circumstances of your organisation. Laws, standards and threats change; check the primary sources cited and take qualified advice before acting.