The first hour of a ransomware incident strongly influences whether it becomes a short, contained disruption or a months-long recovery. This is the sequence that hour should follow, the errors that cost the most, the regulatory clock that starts at the same moment, and what has to exist before the alarm rather than after it.
Scope note: practical guidance drawn from published frameworks and field practice; it is not legal advice. Verify current requirements with the regulator.
Timings and sequences in this article are planning guidance drawn from incident-response practice, not predicted outcomes; every incident differs.
Why the first hour is different from the next twenty-three
It is a little before three in the morning. File extensions on a shared volume are changing. Directory replication is failing. Endpoint alerts are cascading from one server to several. Somebody on call has to decide, within the next few minutes, what kind of incident this is and what to do about it.
Everything after this hour is recovery work, and recovery work can be resourced. What happens inside this hour cannot be repeated. Volatile memory is either captured or gone. The attacker either keeps moving laterally or is contained. Backups are either protected or encrypted alongside everything else. The forensic record that will later answer the regulator, the insurer and the board is either preserved or destroyed by a well-intentioned rebuild. Organisations that come through this well are rarely the ones with better tooling. They are the ones that rehearsed.
The sixty-minute sequence
The checklist below is deliberately ordered. Within each block the order reflects what is lost by waiting. Print it, put it in the incident pack, and test it in a tabletop exercise before you need it.
- Confirm rather than debate (minutes 0 to 5). Treat file-modification rate, directory replication failure and process-tree shape as the confirming signals. A structured confirmation takes a couple of minutes. An unstructured argument about whether the alert is real takes fifteen, and fifteen minutes is a great deal of encryption.
- Declare the incident formally. Declaration is what activates the playbook, the commander roles and any response retainer. Until somebody declares, everyone is helping and nobody is deciding.
- Isolate at the network, not at the power switch (minutes 5 to 15). Pulling power destroys memory, and memory holds the process artefacts, the credentials in use and sometimes key material. Take affected hosts off the network while leaving them running. If a host cannot be isolated at the network within minutes and encryption is actively spreading, powering it down is preferable to continued loss.
- Capture volatile evidence. Memory images from affected hosts, running process lists and active network connections. This is the material that identifies the strain and the entry path, and it exists for minutes rather than hours.
- Contain the identity plane. Ransomware is a credential problem before it is a file problem. Reset or disable the accounts involved in the observed activity, protect the directory service, and block the administrative paths the attacker is using between segments.
- Protect and verify the backups. Take backup infrastructure off the reachable network, confirm that the most recent restore point predates the earliest suspicious activity, and verify that immutable or offline copies are intact. Finding out that the backups were in scope is a discovery you want at minute ten, not at hour six.
- Run the notification matrix, not the phone tree (minutes 15 to 30). Each named role is contacted once, in parallel, with a written status rather than a conversation: technical commander, executive commander, legal counsel, communications lead, regulatory liaison, and the response provider under retainer. A serial phone tree turns the containment team into a briefing service.
- Open a single incident record. One timeline, one location, a timestamp on every action and decision, and the name of the person who took it. The auditor, the insurer and possibly the regulator will read it, and it cannot be reconstructed from memory a week afterwards.
- Start forensic imaging and freeze the logs (minutes 30 to 45). Disk images of affected hosts, network capture from the current period, and a retention hold across identity, endpoint, network and cloud platforms so that nothing ages out during the investigation.
- Establish chain of custody. Evidence handled without a custody record may not support an insurance claim or a later legal position, however sound the technical analysis turns out to be.
- Assess scope from data, not from hope (minutes 45 to 60). Endpoint telemetry for lateral movement, identity logs for compromised credentials, cloud audit logs for unusual administrative activity, and data-access logs for signs of exfiltration before encryption. Assume the scope is wider than the first affected host until the data says otherwise.
- Decide the recovery track and brief the executive. At the end of the hour the executive commander needs three things: current containment status, an evidence-based scope estimate with its uncertainty stated plainly, and a recommended recovery path with its dependencies. Reassurance is not one of them.
The four errors that cost the most
Powering off affected systems. It feels decisive and it destroys the memory image. Network isolation achieves the same containment and keeps the evidence intact.
Rebuilding before investigating. A server restored from an image at minute forty is a server whose entry path can no longer be determined, which means the same path remains available to the attacker after recovery.
Serialising the notification chain. Every escalation step that asks questions before the technical team has answers converts response time into briefing time. Notification should be parallel, written and role-based.
Assuming a single affected host. The first alert marks where detection happened, not where the intrusion started. Treat the initial scope as a hypothesis to be disproved by telemetry.
The regulatory clock starts in the same hour
Response in Saudi Arabia is not solely a technical exercise. Depending on sector and data, several supervisory relationships engage at once, from the moment of awareness rather than the moment of recovery.
Under the Personal Data Protection Law and its implementing regulations, a personal-data breach that may cause harm to the personal data or to the data subjects, or that conflicts with their rights or interests, must be notified to the competent authority (SDAIA) within seventy-two hours of the controller becoming aware of it, and the affected individuals must be informed without undue delay where the breach may damage their data or conflict with their rights or interests. That is precisely why the incident record has to open at minute fifteen: the clock runs from awareness, and awareness has to be evidenced.
Organisations designated under the National Cybersecurity Authority controls carry incident reporting obligations to the authority through the channel stated in their designation, and supervised financial institutions carry a parallel obligation to the Saudi Central Bank under its cyber security framework. Sector regulators in health, education and utilities may add further reporting paths on top.
The practical consequence is that a regulatory liaison belongs in the notification matrix as a named role from minute fifteen, holding the reporting templates and contact routes already prepared. Assembling that material during an incident is how deadlines get missed.
What has to exist before the alarm
- A rehearsed playbook, not a policy document. The distinction is whether the people named in it have executed it under time pressure within the past twelve months.
- A response retainer already signed. Negotiating scope and access with a forensic provider at three in the morning costs the very hour you were trying to save.
- Monitoring with a defined escalation path. Detection is worthless if the alert lands in a queue nobody reads until morning. Monitoring and response targets should be governed by the service agreement, with escalation names and times written into it.
- Backups you have actually restored from. Immutable or offline copies, proven by real restoration rather than by successful job reports.
- An out-of-band communication channel. If the corporate messaging platform is encrypted or untrusted, the team needs a pre-agreed alternative and the numbers to reach each other on it.
- A notification matrix with names, roles and deputies. Including regulatory liaison, legal counsel and communications lead, each with a deputy for leave and travel.
Sector notes for Saudi organisations
Healthcare. Clinical continuity outranks everything, so isolation decisions are made against a documented map of which systems are life-critical and which are administrative. That map is a pre-incident artefact. It cannot be produced at minute ten.
Financial services. Supervisory reporting and customer impact assessment run in parallel with containment from the first hour, which means legal and compliance are in the room at declaration rather than at the post-incident review.
Hospitality. Reservation platforms, payment environments and guest data sit in one estate, and an isolation decision that stops arrivals carries immediate operational cost. Agree degraded-mode procedures with operations in advance, so isolation does not require a debate about revenue at minute twelve.
Where EIE fits
EIE supports Saudi organisations with the engineering side of incident readiness: assessment, control design and remediation, monitoring and response arrangements governed by each customer’s service agreement, and audit-ready evidence packs — from our Jeddah headquarters, with Kingdom-wide service coverage. Talk to our team.
Frequently asked questions
Should an organisation ever pay?
That is a legal and executive decision rather than a technical one, taken with counsel against the sanctions position, the insurance position and the likelihood that decryption works at all. What matters in the first hour is that the decision is not forced by absent evidence or unverified backups.
Is network isolation enough, or should we disconnect from the internet entirely?
Targeted isolation of affected segments is normally preferable, because a total disconnection also severs the telemetry, cloud logs and remote access that responders need. Full disconnection is a considered decision, not a reflex.
How long does a realistic recovery take?
It depends almost entirely on decisions taken in the first hour and on backup quality. An organisation with verified immutable backups, preserved evidence and a rehearsed team measures recovery in days. An organisation that powered off its servers, restored them before imaging and then discovered its backups were reachable measures it in months.
How often should the playbook be exercised?
At least annually as a full tabletop with the executive participants present, plus shorter technical drills more frequently. An exercise the executives skip does not test the part of the process that most often fails.
Sources and further reading
Incident obligations are set by the supervising bodies, and their published texts should be read at source. The National Cybersecurity Authority publishes the Essential Cybersecurity Controls (ECC-2:2024) and the Critical Systems Cybersecurity Controls (CSCC-1:2019), both specifying incident response and reporting expectations. The Saudi Data and Artificial Intelligence Authority publishes the Personal Data Protection Law and its Implementing Regulations, which govern personal-data breach notification. The Saudi Central Bank publishes its Cyber Security Framework for supervised financial institutions, including incident management and reporting requirements. Map your obligations against those texts before an incident rather than during one.
Related: Cybersecurity and compliance solutions and talk to us about incident readiness.