Zero-Day Management and Incident Recovery: Assess, Mitigate, Respond

A zero-day vulnerability is disclosed affecting a component in your production stack. What do you do? If the answer involves scrambling, ad-hoc decisions, and "it depends on who's on call" — your security posture has a gap that no product can fill.

Managing zero-days isn't about having the right tool. It's about having the right posture: assess the risk, put actions in place to mitigate it, and know exactly what to do if it's exploited. This is a framework, not a product pitch.

Security Posture: The Foundation

Security posture is your organisation's overall cybersecurity strength and readiness. It's measured not by how many tools you've deployed, but by how quickly and effectively you can:

• Detect a threat or vulnerability
• Assess its risk to YOUR specific environment
• Decide on the appropriate response
• Execute that response within an acceptable timeframe
• Recover if the worst happens

Certifications and compliance frameworks (ISO 27001, SOC 2, NIS2) provide structure for building this posture. They're not the solution — they're the scaffolding that ensures you've thought about every angle.

Phase 1: Assess the Risk

When a zero-day is disclosed, the first question isn't "how do we patch?" — it's "what's our actual exposure?"

Immediate Assessment (First 2 Hours)

• Asset inventory: Where does the affected component exist in our environment? (This requires an up-to-date CMDB or software bill of materials — SBOM)
• Exposure analysis: Is the vulnerable component internet-facing? Behind a WAF? In an isolated network segment?
• Exploitability: Is there a known exploit in the wild? What's the CVSS score? What's the EPSS (Exploit Prediction Scoring System) probability?
• Business impact: Which critical services (Tier 0, Tier 1) are affected? Refer to your Business Impact Analysis.
• Threat intelligence: Are threat actors actively targeting this vulnerability in your sector?

Risk Rating Matrix

Classify the risk based on your assessment:

• Critical: Actively exploited + affects Tier 0/1 services + internet-facing. Response: immediate (hours).
• High: Exploit available + affects critical services + reachable from untrusted networks. Response: within 24 hours.
• Medium: Exploit possible + affects non-critical services or mitigated by existing controls. Response: within 7 days.
• Low: Theoretical exploit + isolated system + limited impact. Response: next patch cycle.

Phase 2: Mitigate the Risk

Patching is ideal but not always immediately possible. Mitigation buys you time:

Immediate Mitigations (Before Patch Is Available)

• Network segmentation: Restrict access to affected systems. If the vulnerable service doesn't need internet access, remove it.
• WAF/IDS rules: Deploy virtual patches — signatures that detect and block known exploit patterns
• Disable unnecessary features: If the vulnerability is in a specific module or protocol, disable it if the business can function without it
• Increase monitoring: Add specific detection rules for indicators of compromise (IoCs) related to this vulnerability
• Reduce blast radius: Ensure the affected system runs with minimum privileges. If it's compromised, limit what an attacker can reach.

Structured Patching

When a patch becomes available:

• Test in staging first — rushing an untested patch to production can cause outages worse than the vulnerability
• Prioritise by risk rating: Critical and High first, Medium and Low in normal cycles
• Validate the patch actually resolves the vulnerability (re-scan after deployment)
• Document everything: what was patched, when, by whom, what was the test result

Phase 3: Respond If It Happens

Despite your best efforts, the vulnerability may be exploited before you can mitigate. Your incident response must be pre-planned:

Incident Response Playbook

• Detection: How will you know you've been compromised? (SIEM alerts, anomaly detection, threat hunting, user reports)
• Containment: Isolate affected systems immediately. Network disconnection, credential rotation, session termination.
• Eradication: Remove the threat. This may mean rebuilding systems from known-good images, not just patching.
• Recovery: Restore services from isolated minimum infrastructure or validated backups. Verify integrity before reconnecting.
• Post-incident: Root cause analysis, lessons learned, update procedures and detection rules.

Communication Plan

Who needs to know, and when?

• Internal: CISO, CTO, affected business unit leaders, legal, communications
• Regulatory: NIS2 requires initial notification within 24 hours, full report within 72 hours. DORA has similar requirements for financial entities.
• Customers: If personal data is affected, GDPR requires notification within 72 hours
• Law enforcement: For serious incidents, especially those involving nation-state actors or critical infrastructure

The Role of Certifications and Compliance

Compliance frameworks don't solve security problems. They ensure you've built the structures needed to solve them consistently:

• ISO 27001: Provides the Information Security Management System (ISMS) structure — risk assessment methodology, control selection, continuous improvement
• SOC 2: Validates that your controls are operating effectively over time (not just designed well)
• NIS2: Mandates specific capabilities (incident reporting, supply chain security, business continuity) with enforcement penalties
• DORA: Requires ICT risk management, incident classification, digital operational resilience testing, and third-party risk management
• ISO 22301: Business continuity management — ensuring you can maintain operations during and after incidents

Building Your Security Posture

A strong security posture for zero-day management requires:

1. Asset visibility: You cannot protect what you don't know exists. Maintain an accurate, automated inventory including SBOMs.
2. Risk-based prioritisation: Not all vulnerabilities need the same response. Use context, not just CVSS scores.
3. Pre-planned mitigations: Generic runbooks for common vulnerability types (RCE, privilege escalation, data exposure) so teams don't start from scratch each time.
4. Tested response: Regular tabletop exercises and actual failover tests. Annual at minimum, quarterly for Tier 0 services.
5. Continuous improvement: Every incident and every exercise produces lessons. Feed them back into your processes.

Start Here

If you're starting from scratch:

1. Week 1: Can you list every internet-facing service and its software components? If not, start there.
2. Week 2: For each, what's the risk rating if a zero-day is disclosed tomorrow? Document your assessment criteria.
3. Week 3: Write a one-page incident response runbook. Who does what in the first hour?
4. Week 4: Run a tabletop exercise using a recent real-world zero-day as the scenario. Document every gap.
5. Ongoing: Close the gaps. Test again. Improve. Repeat.

Security posture isn't a state — it's a practice.