Incident Response

What is incident response?

Incident response is how an organisation handles a cybersecurity incident, from the first alert to the lessons learned afterwards. A good programme limits the damage, gets services back quickly, preserves evidence and meets the legal duty to tell regulators, customers and affected people in time.

Every major framework expects it. ISO/IEC 27001, NIST CSF, SOC 2 and PCI DSS all include incident management controls, and laws such as GDPR, NIS2 and DORA set firm reporting deadlines.

What does NIST recommend?

NIST’s main guide is SP 800-61 Revision 3, published in April 2025, replacing the 2012 Revision 2. The older version described a separate four-phase lifecycle. Revision 3 instead builds incident response into everyday cybersecurity risk management, organised around the six functions of NIST CSF 2.0:

• Govern, Identify and Protect: preparation, including roles, policies, asset knowledge and the protections that make incidents less likely and less damaging;
• Detect: spotting and analysing possible incidents;
• Respond: containing, eradicating, communicating and reporting;
• Recover: restoring operations and confirming they are trustworthy, then feeding lessons back into the rest.

The message is that incident response isn’t a team that switches on during a crisis. It depends on work done all year.

What does a programme include?

• An incident response plan: who leads, who decides, how incidents are classified by severity, and when to escalate to executives, lawyers, insurers and law enforcement.
• Playbooks for likely scenarios, such as ransomware, business email compromise, a compromised cloud account or a lost device.
• Logging and detection good enough to see what happened, and logs kept long enough to investigate.
• Communication plans for staff, customers, regulators and the media, including out-of-band channels if email or chat is compromised.
• Third-party arrangements: retainers with forensic and legal specialists, and clear incident duties in supplier contracts.
• Exercises: tabletop simulations and technical drills, followed by fixes to the plan.

What are the reporting deadlines?

Deadlines depend on the law, the sector and what was affected, and several can apply at once. Common examples:

• GDPR: personal data breaches to the supervisory authority within 72 hours of becoming aware, where there is a risk to people.
• NIS2: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month.
• DORA: an initial notification of a major ICT-related incident within hours, under timelines set in its technical standards.
• India’s CERT-In directions: specified incidents within 6 hours of noticing them.
• HIPAA: breach notification to affected individuals without unreasonable delay and no later than 60 days after discovery.

Map every clock that could apply to you before an incident happens, and build them into your plan.

Common pitfalls

Plans that have never been exercised, no one able to make decisions out of hours, missing logs, backups that attackers can also reach, and reporting clocks that start before anyone has looked at them. Run at least one realistic exercise a year with the people who would actually be in the room.