Keep an incident decision log that people can use
Capture the reasoning behind response actions so technical and business teams can stay coordinated.
Read article : Keep an incident decision log that people can use
RANSOM SECURE / FIRST-HOUR RANSOMWARE CHECKLIST
When pressure rises, bring structure to the response.
A practical guide to initial observations, trusted communication and coordinated decisions after a suspected ransomware incident.
Suspect an incident? Start a coordinated response.
Use your organization’s incident plan and a trusted contact route. A website checklist cannot assess the event or authorize containment. If essential services or people may be at risk, involve the responsible operational and emergency contacts promptly.
THE FIRST PRIORITY IS CLARITY
Separate what you know from what you suspect.
Ransomware can affect access to files, applications and business services. An unusual message, unexpected encryption or a security alert may be the first sign, but the visible symptom does not establish the full scope of an incident.
Avoid a rush to make unrelated changes. Establish who is coordinating, which communication route is safe and which observations need preserving. Response work may run in parallel; the sequence below is a way to organize decisions, not a promise that an incident can be resolved in sixty minutes.
A PRACTICAL RESPONSE SEQUENCE
Make the next decision with the right people.
01
Raise the concern through a trusted route
Contact the designated responder or IT lead using contact details already known to the organization. If normal email may be affected, use an agreed alternative. Name a coordinator and a person who records decisions so that technical staff are not receiving conflicting instructions.
02
Describe the observable impact
Record which service is affected, when the issue was noticed and what people can no longer do. Capture exact alert wording and useful timestamps where safe. Separate a direct observation from an assumption about the attacker, entry route or extent of compromise.
03
Coordinate containment with authorized responders
Isolation can help limit spread, but the appropriate action depends on the affected system and operational consequences. Follow the incident plan and responder guidance. Avoid blanket shutdown, wiping or rebuilding before the team has considered evidence and safety.
04
Protect recovery options and records
Identify who administers backups and recovery infrastructure. Responders should assess whether those systems or credentials may be affected. Preserve relevant logs and original messages through an agreed process; do not upload sensitive incident evidence into a general contact form.
05
Agree the next briefing and handover
Keep a concise record of decisions, responsible people, affected services and outstanding questions. Set a time for the next update. Coordinate business, legal, insurer and communications contacts where applicable rather than making unsupported public statements.
YOUR FIRST-HOUR REVIEW
Track the essentials. Keep the record factual.
Tick an item when it has been reviewed with the responsible person. An unchecked item is a prompt for follow-up, not a diagnosis. Selections stay in this page and disappear on refresh.
Use your approved incident system for the detailed record. This checklist is not a secure evidence repository and does not contact an incident response team.
- A response coordinator and safe contact route are identified.
- Affected business services and initial observations are recorded.
- Containment decisions are assigned to authorized responders.
- Original messages and useful timestamps are preserved appropriately.
- Backup and recovery access owners have been involved.
- Required business advisers and escalation contacts are identified.
- The next update time and handover responsibilities are agreed.
THREE CONNECTED WORKSTREAMS
Respond together. Avoid conflicting instructions.
Business coordination establishes priorities and authority. Technical response investigates scope and containment. Recovery preparation identifies the people, dependencies and copies needed to restore agreed services when it is appropriate to do so.
These workstreams need a shared record. An executive should not receive an unexplained “all clear” while technical questions remain open, and a restoration team should not reconnect a system without the agreed validation and approval.
DECISIONS TO HANDLE CAREFULLY
Urgency should not remove the checks.
Restarting or rebuilding affected systems
A restart or rebuild may change evidence and may not remove the cause of compromise. Coordinate the action with the incident lead and the people responsible for the system. Record what was changed and why.
Restoring the newest available backup
The newest copy is not automatically a safe recovery point. Recovery decisions should consider the compromise timeline, available evidence, system integrity and the dependencies needed for useful operation.
Forwarding incident details widely
Use a controlled distribution list and a trusted channel. Share what each recipient needs for their role. Original evidence, credentials and sensitive customer information should follow an appropriate handling process.
Assuming a payment solves the incident
Payment does not establish that systems are safe, data will be restored or stolen information will be removed. Decisions involving an extortion demand need specialist advice and appropriate organizational authority.
QUESTIONS THAT MATTER
A clearer answer. A better next step.
Should we disconnect every device immediately?
Do not apply a blanket action without considering the environment. Follow the incident plan and authorized responder guidance. The appropriate containment action depends on the suspected spread, affected systems and operational or safety consequences.
Should we contact you before our IT team?
Use your established incident contact route and involve the people responsible for your systems. External support can be coordinated alongside them. An enquiry does not by itself confirm availability or begin an emergency engagement.
What information should our first message include?
A brief description of the affected service, when the issue was noticed and a safe callback route. Keep passwords, recovery keys, customer records and confidential evidence out of the general website form.
Can we keep working on unaffected systems?
That decision requires an assessment of scope and dependencies. A service that appears unaffected may still share identities or infrastructure with an affected system. Ask the response lead to define permitted activity.
Does this checklist cover reporting obligations?
It prompts you to involve the appropriate advisers. Notification requirements depend on the incident, contracts, policies and applicable law. Obtain qualified advice rather than relying on a general checklist.
Is this a complete incident response plan?
No. It structures the first conversation and review. Your organization needs defined roles, contact routes, technical procedures and rehearsed decisions appropriate to its own operations.
KEEP EXPLORING
Put the guidance in context.
Before you restore: evaluate the recovery point
A recent backup is a starting point. Check what it contains, what it depends on and whether it supports the service you need.
Read article : Before you restore: evaluate the recovery point
A restore test should end with a business check
Plan a recovery rehearsal that checks data, dependencies and a useful workflow—not simply a successful backup console message.
Read article : A restore test should end with a business checkFurther reference: CISA #StopRansomware Guide. This resource is practical guidance, not a certification or a substitute for an assessment of your environment.
TURN INFORMATION INTO ACTION
Bring your questions. Leave with a clearer direction.
Tell us what you want to protect, where the uncertainty is and who needs to be involved. We will discuss the scope and practical next steps with you.