The First 72 Hours: Stabilize and Assess
The period immediately following incident containment is chaotic. Your security team is exhausted, leadership wants answers, and every stakeholder has a different urgent question. Having a structured approach prevents the response from creating new problems.Confirm Containment Before Pivoting to Recovery
Before any recovery work begins, verify with your incident response team (internal or external) that the attacker has been fully evicted from your environment. Premature recovery — rebuilding systems while the attacker still has access — is one of the most common and costly mistakes in incident response. Confirm that attacker access has been revoked across all affected accounts and systems, that compromised credentials have been reset, that the initial access vector has been identified and closed, and that monitoring is in place to detect any re-entry attempts.Establish a Recovery Command Structure
Incident response and business recovery require different skills and different leadership. Designate a Recovery Lead — ideally someone from operations or business leadership, not your security team — to coordinate the recovery effort. Your security team should remain focused on forensic investigation and monitoring while the Recovery Lead manages the restoration of business operations. Create a clear chain of communication. Who reports to whom? Who authorizes decisions about system restoration priority? Who speaks to customers, regulators, and the press? Establishing this structure before the chaos peaks is essential.Assess the Blast Radius
Work with your incident response team to document exactly what was affected. Determine which systems, data, and services were compromised, encrypted, destroyed, or accessed without authorization. Categorize the impact into operational impact (which business processes are disrupted), data impact (what data was accessed, exfiltrated, or destroyed), and financial impact (revenue loss, recovery costs, potential fines). This assessment drives every decision that follows — what to restore first, who to notify, and what to tell stakeholders.Week 1: Begin Restoration and Notification
Prioritize System Restoration by Business Impact
Not all systems are equally critical. Work with business unit leaders to rank systems by their impact on revenue, customer commitments, and safety. Restore the systems that keep your business running first, then work outward to supporting systems and lower-priority services. For each system, decide whether to restore from backup, rebuild from scratch, or implement a temporary workaround. Restoring from backup is faster but requires confidence that your backups are clean and weren’t compromised. Rebuilding takes longer but ensures a known-good state. Document every restoration decision and the rationale behind it.Activate Your Legal and Regulatory Notification Obligations
Data breach notification laws vary by jurisdiction, and failing to notify on time carries its own penalties. In the United States, 50 states plus the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands all have separate breach notification laws. Notification timelines range from 30 to 90 days depending on the state, with some states requiring notification “without unreasonable delay.” At the federal level, HIPAA requires notification within 60 days for breaches affecting 500 or more individuals. The SEC requires publicly traded companies to disclose material cybersecurity incidents within four business days of determining materiality. Defense contractors have 72-hour notification requirements under DFARS. If you have EU customers or employees, GDPR requires notification to the relevant Data Protection Authority within 72 hours of becoming aware of a breach involving personal data, and notification to affected individuals “without undue delay” if the breach poses a high risk to their rights and freedoms. Engage your breach counsel early. They will help you map your notification obligations based on the data involved, the jurisdictions affected, and the nature of the incident. Getting this wrong creates legal exposure on top of the operational disruption you’re already managing.Notify Your Cyber Insurance Carrier
If you haven’t already, formally notify your carrier in writing. Provide a summary of what happened, what data was affected, and what response actions have been taken. Request approval for any recovery expenditures that you expect the policy to cover. Keep your carrier informed throughout the recovery process — surprises during the claims process rarely end well.Weeks 2 Through 4: Communicate with Stakeholders
Communication after a breach is where many organizations do the most lasting damage — not from the breach itself, but from how they handle the message. Silence, deflection, and corporate jargon erode trust far more than the incident itself.Communicating with Customers
Customers want to know three things: what happened, how it affects them, and what you’re doing about it. Tell them clearly and directly. Avoid vague language like “a security event” when what happened was a ransomware attack or data exfiltration. Acknowledge the impact honestly, explain what steps you’ve taken to contain and remediate the incident, describe what you’re doing to prevent recurrence, and provide specific actions they should take (change passwords, monitor accounts, enroll in credit monitoring if applicable). Provide a dedicated channel for questions — a phone number, email address, or web page — and staff it with people who can actually answer questions. Nothing frustrates an affected customer more than being routed to a generic support queue.Communicating with Employees
Your employees are stakeholders too, and they’re often the most anxious. They want to know whether their personal data was affected, whether their jobs are at risk, and what the company is doing. Be transparent with your workforce. If employee data was compromised, tell them immediately with the same specificity and support you’d offer customers. Provide clear guidance on what they should do to protect themselves. Also address operational concerns. If workflows have changed, systems are unavailable, or processes are disrupted, give employees clear instructions on interim procedures. The faster you reduce uncertainty, the faster productivity recovers.Communicating with Regulators
Regulatory communications should be factual, precise, and managed by your legal team. Provide the information required by the relevant notification statute and nothing more. Voluntary over-disclosure can create additional legal exposure. Your breach counsel will advise on the appropriate level of detail for each jurisdiction and regulator.Communicating with the Media
If your breach attracts media attention, designate a single spokesperson and prepare a written statement. Keep the statement factual, empathetic, and forward-looking. Acknowledge what happened, express concern for affected individuals, and outline the steps you’re taking. Avoid speculation about the attacker, the scope of the breach (until you’re confident in your assessment), or blame. Do not say “we take security seriously” — it has become a meaningless cliche that signals the opposite of what you intend. If you have a communications or PR team, activate them immediately. If you don’t, your cyber insurance policy likely includes access to crisis communications professionals. Use them.Communicating with Partners and Vendors
If the breach affects data you share with partners or vendors, or if it originated through a supply chain compromise, those partners need to be notified promptly. Beyond legal obligations, maintaining trust with business partners requires honesty and speed. Provide them with enough technical detail to assess their own exposure and take protective action.Months 1 Through 3: Recover and Rebuild
Conduct a Post-Incident Review
Once the immediate crisis has passed, conduct a thorough post-incident review (sometimes called a “lessons learned” or “after-action” review). This should involve everyone who participated in the response, including IT, security, legal, communications, executive leadership, and any external parties (forensics firms, breach counsel, insurance carrier). The review should document the full timeline of the incident from initial compromise to detection to containment to recovery. Identify what worked well in the response and what didn’t. Assess where detection was too slow and why. Evaluate whether the incident response plan was followed and where it broke down. Catalog specific improvements needed in technology, process, and people. The output of this review should be a prioritized action plan, not a shelf document. Assign owners and deadlines to every improvement item.Address Root Causes, Not Just Symptoms
If the attacker gained access through an unpatched VPN appliance, patching that appliance is necessary but insufficient. The root cause question is: why wasn’t it patched? Was there no vulnerability management program? Was there a program but no enforcement? Was there enforcement but no visibility into that asset? Dig until you find the systemic issue and fix that. Otherwise, the next incident will follow a different path to the same outcome.Rebuild Trust Through Visible Action
Customers, partners, and employees will judge your organization not by the breach, but by your response to it. Organizations that communicate transparently, act decisively, and demonstrably improve their security posture often emerge with stronger relationships than they had before. Consider publishing a summary of the improvements you’ve made (without revealing specific vulnerabilities). Offer affected customers ongoing monitoring or protection. If appropriate, share anonymized lessons learned with your industry peers or through ISACs (Information Sharing and Analysis Centers).Building Long-Term Resilience
Update Your Incident Response Plan
If your plan didn’t work perfectly during the incident — and no plan survives first contact — update it based on what you learned. Test the updated plan through a tabletop exercise within 90 days of the incident.Invest in Detection and Response Gaps
The post-incident review will almost certainly reveal gaps in your detection and response capabilities. Whether that means deploying managed detection and response, improving log retention and analysis, or adding identity threat detection, invest in closing the gaps that allowed the incident to progress as far as it did.Establish a Regular Cadence of Testing
Tabletop exercises should happen at least twice a year, with at least one involving executive leadership and external partners (legal, insurance, communications). Penetration testing should occur annually at minimum. Backup restoration tests should happen quarterly. Recovery readiness isn’t something you build once. It’s something you practice continuously.Key Takeaways
The breach itself is rarely what destroys an organization. It’s the slow, fumbled, opaque response that follows. Having a recovery playbook, clear communication templates, and a practiced command structure transforms a crisis into a manageable business challenge. Prepare for the aftermath with the same rigor you apply to prevention.ContraForce helps organizations detect, respond to, and recover from security incidents with clarity and speed. Learn more about our platform.