Services / Resilience
Incident Response
A retained team that answers the phone, and a plan written before you need it.
The problem
Something is wrong in production at 2am. The person on call does not know whether this is an incident, who to wake, whether to pull the machine off the network, or whether a clock has started running. Everything that follows depends on the next hour, and nobody has rehearsed it.
The method.
Write the plan around decisions and clocks
Severity definitions with concrete triggers, an escalation path with names and phone numbers that are actually current, declared authority for containment actions, and the regulatory clocks written into the plan: 72 hours to the supervisory authority under GDPR, notification duties to the Israeli Privacy Protection Authority, customer contractual windows that are often shorter than either.
Ensure the evidence will exist when you need it
Before an incident, verify that the telemetry an investigation requires is being retained: EDR telemetry, cloud control-plane logs (CloudTrail and equivalents) in all regions, authentication and IdP sign-in logs, VPN and remote access, application and database audit logs. Retention is checked against the realistic dwell time, not against the default. Most investigations fail here, not at the analysis.
Retain the response capability in advance
A retainer with defined response SLAs, a signed scope so nobody negotiates a contract during a breach, pre-agreed access paths for the responders, and the forensic and communications contacts (including the insurer's panel, if the policy mandates one) already in the plan.
Respond: contain, preserve, investigate, eradicate, recover
Containment that does not destroy the evidence: isolate rather than reimage, snapshot volumes and capture memory before shutting anything down, revoke tokens and rotate credentials in the right order, and preserve the timeline. Then scope the compromise (initial access, persistence, lateral movement, what was accessed or taken) before declaring anything eradicated.
Handle notification as a defined workstream
Determine whether a notification duty is triggered, on what facts, with what deadline. Pre-drafted templates for customers, supervisory authorities and staff, reviewed before the incident. The public account you give must be one the forensic timeline can support.
Close it properly
A written after-action report with a factual timeline, root cause, and corrective actions with owners and dates, which is both the ISO 27001 requirement and the only part of an incident that ever makes the next one less likely.
What should an incident response plan contain?
Severity definitions with concrete triggers, a current escalation path with names and phone numbers, explicit authority for containment actions such as taking production offline, the regulatory and contractual notification clocks with their deadlines, evidence-preservation steps, pre-drafted communication templates, and the external contacts: forensics, insurer, counsel. A plan that lacks named authority stalls at the first real decision.
How long do you have to report a data breach?
Under the GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, and to affected individuals without undue delay where the risk to them is high. Israeli law requires notification to the Privacy Protection Authority for severe incidents affecting medium- and high-tier databases. Customer contracts frequently impose shorter windows (24 or 48 hours), and those are the ones companies most often miss.
What is the first thing to do when a breach is suspected?
Preserve, then contain. Isolate the affected system from the network rather than shutting it down or reimaging it: memory and volatile evidence are lost on power-off, and reimaging destroys the only record of how the attacker got in. Snapshot volumes, capture memory where possible, start a written timeline immediately, and escalate according to the plan before making any irreversible change.