Your first incident-response conversation: what to bring
A clear account of what you observed helps the response team ask better questions and coordinate the next action.
Read article : Your first incident-response conversation: what to bring
CYBER INCIDENT RESPONSE
When an incident unfolds, bring the next move into focus.
Understand what is happening. Coordinate containment. Build a recovery path your business can trust. Start with a safe conversation about the situation in front of you.
SUSPECT SOMETHING IS WRONG?
Start with the facts. Bring the right people together.
You do not need a complete diagnosis to raise a concern. Unusual sign-ins, encrypted files, unexpected account changes or an alert from a provider can all justify a coordinated review.
Use a trusted contact route
Reach your designated IT or security contact from a device and communication channel you reasonably believe are unaffected. If your email may be compromised, avoid relying on that same mailbox to coordinate the response.
Capture what you observed
Note the time, affected services, messages and actions already taken. Distinguish what you saw from what you suspect. Share a short description first; arrange a suitable channel for sensitive evidence.
Coordinate the next action
Follow your incident plan and authorised responder guidance. Containment decisions should consider spread, evidence and operational safety. Avoid unplanned changes that make the situation harder to understand.
Need to discuss a suspected incident? Use the enquiry popup or call +1 646 220 8881.
Availability and engagement scope must be confirmed directly. Sending a website enquiry does not start an emergency engagement.
ONE SHARED PICTURE
Technical response. Business decisions. Connected from the start.
An incident creates several conversations at once. The people investigating need context; the people running the business need clear decisions. A shared incident record keeps those conversations connected.
The incident lead
Coordinates decisions, owners and the next update.
Technical workstream
Evidence, affected systems, containment actions and recovery validation.
Business workstream
Service priorities, operational workarounds, stakeholder updates and authorised decisions.
Known facts → Open questions → Decisions → Named owners
Depending on the situation, the response may involve your internal IT team, MSP, leadership, legal advisers, insurer and specialist investigators. Responsibilities and authority need to be clear before actions are taken.
A RESPONSE THAT ADAPTS AS EVIDENCE CHANGES
From the first signal to a controlled return.
These workstreams overlap. New evidence may change the scope or require containment to be revisited. The sequence below explains the decisions—not a promised timetable.
01
Establish the situation
Clarify what was noticed, when it began and which services appear affected. Identify an incident owner and a safe channel. Build an initial picture from available records without assuming the first alert explains the whole event.
Decision to make: What needs immediate attention, and who can authorise the response?
02
Limit further harm
Evaluate how affected identities, devices or connections can be contained. Balance the need to interrupt malicious activity with operational dependencies and evidence preservation. Record changes so responders understand what has already happened.
Decision to make: Which containment actions reduce risk without creating avoidable disruption?
03
Investigate the scope
Review relevant records to understand affected assets, possible access paths and the sequence of events. Separate confirmed observations from hypotheses. Where specialist forensic work is required, agree its scope, access and evidence-handling requirements.
Decision to make: What is known, what remains uncertain and what additional evidence matters?
04
Remove the cause and prepare recovery
Address the identified access paths and persistence mechanisms within the agreed scope. Coordinate account, configuration and system changes. Identify recovery dependencies and the checks needed before a service reconnects.
Decision to make: What must change before this environment can safely support recovery?
05
Restore with checkpoints
Recover prioritised services into an appropriately controlled environment. Test business functions, access and monitoring with their owners. Reconnecting a system is a decision supported by checks, not simply the moment it starts.
Decision to make: Who has verified the service, and what monitoring or restrictions remain?
06
Turn the incident into improvement
Record the timeline, decisions, limitations and agreed next steps. Assign owners to remaining actions. Update response procedures and exercise the changes so lessons become operating improvements.
Decision to make: Which changes will reduce recurrence and improve the next response?
PRESERVE THE STORY
The evidence can change while you are responding.
Logs rotate. Accounts change. Systems restart. An investigation depends on knowing what was present, when it was collected and which response actions may have altered it.
Relevant evidence can include identity sign-ins, mailbox activity, endpoint alerts, network events and system records. Collection should be proportionate to the incident and handled by people with the appropriate skills and authority.
Do not upload sensitive logs, passwords or confidential incident evidence through a general website form. Agree a secure exchange method and access boundaries with the response team.
AN EVIDENCE RECORD SHOULD EXPLAIN
Origin
The system, account or provider the record came from.
Timing
When it was observed and collected, including the time zone.
Handling
Who collected it, who can access it and how it is protected.
Limitations
Missing periods, incomplete logs and changes already made.
DIFFERENT SIGNALS. DIFFERENT DECISIONS.
Start with the situation you actually have.
Ransomware or a suspected extortion event
Files may be unavailable, a ransom note may appear or a third party may report stolen information. Encryption and data theft are separate questions; absence of one does not rule out the other.
Where the response focuses
Coordinate containment and preservation with responders. Identify affected services, protect available recovery options and evaluate evidence of data access. Recovery, communication and any specialist negotiation support require clear responsibilities and scope.
A compromised business account
Unexpected sign-ins, forwarding rules, payment instructions or new access grants may indicate misuse of an account. The visible email can be only one part of the incident.
Where the response focuses
Review sessions, permissions, recent activity and connected applications with the authorised team. Coordinate access changes and independent verification of consequential requests. Establish whether other accounts or systems are affected.
An alert with an uncertain cause
An endpoint or cloud alert may be a genuine incident, a configuration problem or benign activity. Dismissing it too early and treating it as a confirmed breach are both poor starting points.
Where the response focuses
Preserve the alert context, identify the affected asset and ask who can validate the activity. Use evidence to determine scope and escalation. Record uncertainty so the next person does not mistake a working theory for a conclusion.
A supplier reports an incident
A supplier event can affect availability, information or trusted connections without a visible alert inside your own systems. The impact depends on the actual relationship.
Where the response focuses
Identify the services, data and access shared with the supplier. Establish a verified contact, request relevant facts and review your own evidence. Decide on proportionate access restrictions and operational contingencies with service owners.
RECOVERY IS A CONTROLLED HANDOVER
Back online is a milestone. Back in control is the objective.
Recovery decisions connect technical evidence to the services your people need. Agree the release criteria and decision owner before pressure turns a restart into an untested return.
A
Understand the boundary
Document the affected scope and remaining uncertainties. Explain what has and has not been investigated.
B
Address the access path
Validate agreed containment and remediation work. Review credentials, permissions and dependencies that could reopen the route.
C
Prove the service
Test the important business workflow, not only the server. Confirm data, user access and operational acceptance.
D
Watch the return
Define enhanced monitoring, escalation and rollback arrangements. Assign ownership of unresolved actions.
Explore backup and disaster recovery or ransomware recovery for the restoration workstream.
COMMUNICATION UNDER PRESSURE
Give each audience the information it needs.
A useful update states what is known, what is being checked and what decision is needed. It should not promise a recovery time that the evidence cannot support.
Agree who approves communications and who receives them. Keep a decision log and a predictable update rhythm. Legal advisers and the relevant business owners should guide any contractual, regulatory or notification decisions.
ILLUSTRATIVE STATUS UPDATE
Facts first. Next action clear.
- Current impact: the services affected and the operational consequence.
- Confirmed actions: what the team has completed and validated.
- Open questions: uncertainties that could change the response.
- Decision required: the owner, options and relevant trade-offs.
- Next update: a defined time or a specific event that will trigger it.
Use a trusted channel. Limit sensitive technical detail to the people who need it.
BEFORE THE NEXT ALERT
Preparation makes the first conversation better.
Keep contacts usable
Maintain current internal and external contacts somewhere accessible if normal systems are unavailable. Include an alternate communication route and the people authorised to make operational decisions.
Make plans practical
Map critical services, dependencies and recovery priorities. Check evidence retention and escalation paths. A concise plan that people can use is more valuable than a document nobody can find.
Exercise the decisions
Walk through realistic scenarios with business and technical teams. Test the handoffs, record gaps and follow up on actions. Use tabletop exercises and recovery drills to strengthen the process.
QUESTIONS WHEN CLARITY MATTERS
Incident response, explained.
What should I do if I suspect an incident right now?
Contact your designated IT or security lead through a trusted route and follow your incident plan. Record what you noticed and when. Coordinate technical actions with authorised responders; avoid making broad changes without understanding their impact on evidence and operations. If contacting us, share a brief description and safe callback details first.
Can I contact you before we know whether it is a breach?
Yes. An initial conversation can start with an alert, unusual activity or uncertainty. Be clear about what you observed rather than describing every concern as a confirmed breach. Availability, scope and the next steps must be agreed directly.
Does submitting the form activate an emergency response?
No. The form is an enquiry route. Response availability, responsibilities, access and commercial terms must be confirmed before an engagement begins. If you already have an incident-response provider or an emergency escalation route, use that agreed process.
Should we turn off affected computers?
There is no universal instruction that fits every environment. Powering down can lose volatile evidence, while leaving a system connected can allow further harm. Authorised responders should choose containment based on the situation, the incident plan and operational safety. Do not delay your established escalation process while waiting for website advice.
Can you work with our IT team, MSP or existing security provider?
We can discuss a coordinated engagement with your existing teams and advisers. Agree who leads, who makes changes, who owns evidence and how updates are shared. Clear responsibilities help prevent duplicate or conflicting actions.
Will incident response include forensic investigation and recovery?
The included activities depend on the agreed engagement. Initial triage, containment coordination, investigation, specialist forensics and restoration have different requirements. We define scope and responsibilities explicitly and identify when additional expertise or a separate workstream is needed.
Can you guarantee recovery or that no data was taken?
No. Outcomes depend on the incident, available evidence, affected systems and recovery options. A response should explain confidence and limitations rather than offer certainty that the evidence cannot support. Recovery progress and possible information exposure are assessed separately.
What happens after the immediate incident is contained?
Review the timeline, decisions and remaining uncertainties. Validate recovery, assign outstanding actions and update the relevant controls and response procedures. Follow-up work should have owners and completion evidence, with exercises used to check important changes.
FROM THE RANSOM SECURE BLOG
Useful guidance before you need it.
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
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 guidance: CISA #StopRansomware Guide. The hero is a conceptual illustration; examples do not represent a customer incident.
TAKE THE NEXT STEP WITH CONTEXT
Tell us what you are seeing. Let’s clarify the next step.
A short description and a safe contact route are enough to start the conversation. Keep sensitive evidence out of the initial enquiry.
Prefer to call? +1 646 220 8881