Why the First 72 Hours Define the Outcome
Ransomware does not give you time to think. The decisions your team makes in the first three days determine whether you contain the damage, meet your regulatory obligations, and recover with operations intact — or spend the next several months managing a much larger crisis.
Most organizations that struggle after a ransomware attack do not fail because they lacked the right technology. They fail because no one had a clear plan for those first 72 hours. Who makes decisions? Who contacts regulators? What gets restored first, and from where?
This article walks through a practical incident response framework organized by time window. It is written for CISOs, IT Directors, and Heads of Risk and Compliance who need a clear sequence of actions — not a generic checklist.
Hour 0–4: Contain Before You Investigate
When ransomware hits, the instinct is to understand what happened. Resist that until you have stopped the spread.
Ransomware typically moves across networks before it encrypts files. Every minute a compromised system stays connected is a minute the attacker's code can reach adjacent systems, shared drives, and backups.
Isolate Affected Systems Immediately
Disconnect affected endpoints from the network — physically unplug cables and disable Wi-Fi where possible. Do not simply power down machines unless your incident response plan specifically calls for it. Shutting down a system can destroy volatile memory evidence that forensic investigators will need later.
Segment your network at the firewall level and block traffic between affected segments and the rest of your environment. If you have a Security Information and Event Management (SIEM) system or a Security Operations Center (SOC) in place, your team should already be seeing alerts — use those logs to identify which systems are behaving abnormally.
Disable compromised accounts. If you can identify which credentials the attacker used, suspend those accounts immediately. Do not delete them — they are part of the evidence chain.
Preserve Evidence Before You Touch Anything Else
Before any remediation begins, take memory dumps and system images from affected machines where technically feasible. Capture network traffic logs, authentication logs, and endpoint detection logs. Store everything on isolated, write-protected media.
This matters for two reasons. First, it tells your forensic team how the attacker got in and how far they moved. Second, regulators in Singapore and Indonesia may require documented evidence of your response. Under Singapore's Personal Data Protection Act (PDPA) and comparable frameworks, your ability to demonstrate a structured response can directly affect how a breach is assessed.
Hour 4–24: Assess the Scope and Activate Your Response Team
With containment in place, you can start building a clear picture of what you are dealing with.
Map What Was Affected
Work through your asset inventory and identify every system that was encrypted, accessed, or potentially exfiltrated. Pay particular attention to systems holding personal data, payment card data, or health records — these carry specific regulatory notification obligations.
For each affected system, answer three questions:
- Was data encrypted, or was it accessed and potentially copied before encryption began?
- Does this system hold regulated data under PDPA, the Payment Card Industry Data Security Standard (PCI DSS), HIPAA, or another framework?
- Is this system connected to third-party vendors or partners who may also be at risk?
That last question matters more than many organizations expect. If compromised systems share data with vendors or have API connections to partner platforms, those parties may be exposed too. Your incident response plan should include a vendor notification protocol — and if it does not, that gap is now visible.
Notify the Right People Internally
Activate your incident response team. This typically means your CISO or IT Director, legal counsel, a communications lead, and the senior business stakeholders whose operations are directly affected.
Set up a single communication channel for incident updates — a dedicated channel in your internal messaging platform works well — and keep all incident-related discussion there. It creates a documented record and stops misinformation from spreading through informal conversations.
Brief your executive team early. They need to know what happened, what is being done, and what decisions may need to be escalated. They should not be learning about a major ransomware incident from a board member who read about it elsewhere.
Hour 24–48: Regulatory Obligations and External Notifications
By this point you should have a working picture of the scope. Now your regulatory obligations come into focus.
Know Your Notification Deadlines
Different frameworks carry different timelines, and missing them compounds your exposure significantly.
In Singapore, the PDPA requires organizations to notify the Personal Data Protection Commission (PDPC) of a notifiable data breach within three calendar days of assessing that a breach is notifiable. That window starts from the moment of assessment — not discovery — which means your assessment process needs to move quickly.
If your organization operates under MAS Technology Risk Management (MAS TRM) guidelines, you have additional obligations around reporting significant incidents to the Monetary Authority of Singapore.
For organizations subject to PCI DSS, a breach affecting cardholder data triggers notification requirements to your acquiring bank and the relevant card brands within specific timeframes.
If you operate in Indonesia, you also need to account for the Personal Data Protection Law (UU PDP), which is now in full effect and carries its own breach notification requirements.
Document every decision and action with timestamps throughout. Regulators will want to see that your response was structured and proportionate.
Engage External Support If You Need It
If your internal team does not have the forensic capability to investigate the breach, bring in outside support now — not on day three. Waiting means losing critical evidence and losing time.
An experienced security consulting firm can run parallel workstreams: forensic investigation, regulatory notification support, and recovery planning. If you do not already have a retainer in place, this is the moment you will wish you had.
Hour 48–72: Begin Controlled Recovery
Restoring systems before full containment is one of the most common mistakes organizations make. If you have not identified and closed the initial access vector, you may be restoring into an environment the attacker can still reach.
Restore From Clean Backups Only
Before restoring any system, verify that your backups are clean. Many ransomware operators specifically target backup systems to maximize pressure — do not assume yours are untouched.
Restore in order of business priority, starting with systems that support critical operations. Validate each restored system before reconnecting it to the broader network.
Change all credentials across your environment, not just the accounts you know were compromised. Any credential that existed on an affected system should be treated as potentially exposed.
Document Everything as You Go
Your post-incident report will need a complete timeline: when the attack was detected, what actions were taken, by whom, and at what time. This documentation supports your regulatory submissions and your internal lessons-learned review.
It also matters for insurance claims if your organization carries cyber liability coverage. Insurers will want evidence that your response followed a defined process.
What Happens After 72 Hours
The 72-hour window closes, but the work does not. After immediate containment and recovery, you need to complete a full root cause analysis, close the initial access vector, and assess whether your security controls need to change.
This is also when organizations typically see the gaps that made the incident worse than it needed to be: no tested incident response plan, no isolated backups, no documented asset inventory, no security awareness training that might have caught the phishing email that started everything.
A Vulnerability Assessment and Penetration Testing (VAPT) engagement after a ransomware incident is not unusual. It gives you an independent view of what other vulnerabilities remain before an attacker finds them again. And if your organization does not yet have an Information Security Management System (ISMS) aligned with ISO 27001, this is the moment to build one — not as a compliance exercise, but as the operational framework that makes structured incident response possible in the first place.
Kamindo works with mid-to-large enterprises across Singapore and Indonesia on post-incident security improvement and the preparedness work that reduces the impact of incidents before they happen. The firm's practitioners work directly inside client environments, covering regulatory requirements across both markets.
FAQs
Should you pay the ransom? This is a legal and business decision, not a purely technical one. Paying does not guarantee data recovery, and it does not prevent the attacker from publishing exfiltrated data. Depending on your jurisdiction and the identity of the threat actor, payment may also create legal exposure. Consult legal counsel before making any payment decision, and do not communicate directly with attackers without guidance.
How do you know if data was exfiltrated before encryption? Forensic log analysis can identify unusual outbound data transfers in the period before encryption began. Many ransomware operators use a double-extortion model — they copy data before encrypting it and threaten to publish it. Your forensic investigation should specifically look for evidence of data staging and exfiltration.
What is the most common initial access vector for ransomware attacks? Phishing emails remain the most common entry point, followed by exploitation of unpatched vulnerabilities and compromised remote access credentials. This is why security awareness training and regular VAPT are both meaningful preventive controls, not just compliance checkboxes.
Do you need to notify all affected customers immediately? Notification obligations depend on what data was affected and which regulatory frameworks apply to your organization. Under Singapore's PDPA, you notify the PDPC first, and the PDPC may direct you on customer notification. Under PCI DSS, your acquiring bank guides the process. Get legal counsel involved before making any public statements.
How long does ransomware recovery typically take? It varies significantly based on the scope of encryption, the quality of backups, and the complexity of the environment. Organizations with tested incident response plans and clean, isolated backups recover faster. Those without them often spend weeks rebuilding systems manually.
What should be in a ransomware incident response plan? At minimum: a defined escalation chain, a system isolation procedure, a backup verification process, a regulatory notification checklist with deadlines, a communications protocol for internal and external stakeholders, and a list of external contacts including legal counsel and incident response support. The plan should be tested through tabletop exercises before you need it.
How does ISO 27001 relate to ransomware preparedness? ISO 27001 requires organizations to implement controls across asset management, access control, incident management, and business continuity. An ISMS aligned with ISO 27001 does not prevent ransomware, but it creates the documented controls and tested procedures that make your response faster and more structured when an incident occurs.
The Time to Prepare Is Before the Incident
The organizations that manage ransomware incidents well are not necessarily the ones that respond fastest in the moment. They are the ones that built the plan, tested it, and had the right controls in place before anything happened.If your organization does not have a tested incident response plan, isolated backups, or a clear picture of your vulnerability exposure, those are the gaps worth addressing now.
Want to assess where your incident readiness stands? Talk to a Kamindo consultant at kamindo.co.