Direct answer
Treat confirmed exploitation as an incident, not a patch ticket. Identify affected assets and exposure, apply the fastest safe containment or compensating control, preserve evidence of exploitation, review for persistence and follow-on access, remediate the vulnerability, and validate recovery before closing the incident.
When to activate this playbook
A security control reports exploit activity against a vulnerable asset.
Threat intelligence or a known-exploited-vulnerability notice matches an exposed internal asset.
Unexpected processes, accounts, files or network activity appear on a vulnerable system.
A vulnerability-management record is linked to incident evidence or active compromise.
First 15 minutes
Open an incident and identify the vulnerable asset, owner, service and exposure path.
Apply an approved containment or compensating control when exploitation is plausible or confirmed.
Preserve system, network and security-control evidence before patching destroys relevant artefacts where feasible.
Identify other assets with the same vulnerable component or exposure pattern.
First hour
Determine whether exploitation succeeded and what the attacker could access.
Review for new accounts, services, scheduled tasks, files, keys, tokens or other persistence.
Correlate indicators across endpoints, network controls, identity systems and cloud logs.
Choose remediation based on exploitability, business criticality, exposure and recovery risk rather than severity score alone.
First day
Patch, upgrade, remove, isolate or otherwise remediate the vulnerable component.
Rotate credentials or secrets exposed through the affected system.
Validate that persistence and malicious changes are removed and monitoring is active.
Update the vulnerability, exposure and incident records with evidence of remediation and validation.
Evidence to preserve
EvidenceVulnerability and asset records at the time of exploitation.
EvidenceEndpoint, process, file, network and authentication evidence.
EvidenceWAF, firewall, IDS/IPS, EDR or other detection records.
EvidencePatch, configuration and compensating-control changes.
EvidenceThreat-intelligence or known-exploited-vulnerability context used in prioritisation.
Key decision points
Is exploitation confirmed, attempted or only theoretically possible?
Is the vulnerable asset internet-facing or business-critical?
Was privileged access or persistence achieved?
Can the system be safely patched in place or should it be rebuilt or isolated?
Communication discipline
Keep exploitation status separate from vulnerability severity.
Escalate material compromise to incident, legal/privacy and business owners.
Document why a compensating control was accepted if immediate remediation is not possible.
Where Cybatar fits
Vulnerability, exposure, asset and incident records linked in one operating context.
Threat-intelligence and known-exploitation context for prioritisation.
Remediation ownership, evidence, exceptions and reporting.
Forensic escalation when exploitation evidence requires deeper analysis.
Claim boundary
Cybatar can help prioritise and coordinate vulnerability and incident work, but it does not guarantee exploit detection, patch availability, safe patching or removal of attacker persistence. Technical remediation depends on the affected product, system owner and specialist controls.
Related evidence and guidance
Known exploited vulnerabilities researchhttps://cybatar.co/research/prioritising-known-exploited-vulnerabilities
Exposure & Vulnerability Managementhttps://cybatar.co/platform/exposure-vulnerability-management
Vulnerability prioritisation backloghttps://cybatar.co/security-problems/vulnerability-prioritisation-backlog
Evidence preservation checklisthttps://cybatar.co/incident-evidence-preservation-checklist
Incident Response Checklisthttps://cybatar.co/incident-response-checklist
Evidence Preservation Checklisthttps://cybatar.co/incident-evidence-preservation-checklist