Guidance

What to do when cyber attacks disrupt your organisation

How to recover from disruption, get ready for future incidents and make them less likely.

Page 3 of 5

1. Immediate activities (what to do in the first hours)

The first response to a disruptive cyber attack is often highly emotional. Senior leaders and responders may experience stress, uncertainty, guilt or a strong desire to assign blame. In incidents involving ransomware or extortion, attackers may deliberately seek to increase pressure in order to influence decision‑making.

It's important for leaders to set a calm, professional tone from the outset, to avoid rushing to judgement, and to support their people through the uncertainty ahead. Maintaining composure and focus not only improves decision‑making, but also reduces the leverage attackers can exert over the organisation.

In the first hours, organisations should take the following immediate actions to stabilise the situation, begin to establish a shared understanding of what has happened, and enable informed decision‑making.

Technical lead

Activity

Incident triage: establishing the current operational state

Carry out initial triage to understand your organisation’s current position

Further information

Before you design your recovery programme, you need to establish a shared understanding of your ‘as-is’ operational state. (This includes activities in 1.4.1 - 1.4.5).

Incident command will establish initial priorities and adjust them as more information becomes available and understanding improves. This will shape workaround and recovery efforts, and should not be expected to be fully defined in the first few hours.

1.4.1 Technical lead: Identify critical business functions

Identify critical business functions and ascertain the extent to which they have been affected. The needs of the business must drive prioritisation for recovery, not solely IT considerations.

1.4.2 Technical lead: Assess system impact

Identify which systems remain operational and which are degraded. (Further investigation will be needed to understand if any systems will require rebuilding).

Establish if your corporate communications channels are available and can be trusted for use.

Where communications channels are unavailable or cannot be trusted, establish alternative mechanisms for communicating with staff, stakeholders and customers. If large numbers of people may be affected, consider setting up dedicated support channels to provide updates, answer questions and manage enquiries.

1.4.3 Technical lead: Identify priority systems and dependencies

Identify which systems – and any systems they rely on to operate – underpin critical business functions and should be recovered first. (These may be outlined in business continuity plans).

1.4.4 Technical lead: Review backups

Ideally backups will support the rebuild of the entire environment, including applications, identity systems and trust services – as well as the data itself.

To understand how much support your backups will provide:

ascertain when your last backups were taken
investigate whether they are available and if they have been compromised

1.4.5 Technical lead: Understand attacker status

Establish from the CIR provider’s findings whether the attacker has been contained or whether risk of further harm remains. This is often inconclusive. Use the provider’s assessment, assumptions and confidence levels to inform decisions about ongoing risk.

These two accordions display the immediate activities in an alternative format:

Activity	Further information
1.1 Establish an incident command structure Establish a clear governance structure for directing and coordinating the organisation’s response to the incident. Refer to your cyber incident 'playbook', if you have one. Decisions made through this structure will guide many of the subsequent response and recovery activities.	To bring together appropriate stakeholders to share information and enable rapid decision making across technical, legal, operational and business areas. Where possible, organisations should use established incident management structures. In practice, the CEO will normally lead on the organisation’s response to a cyber incident, delegating responsibilities as appropriate to other executive senior leaders. To support and facilitate effective information flows, put in place sufficient governance to coordinate and control between workstreams. This may include an incident command structure such as Gold, Silver and Bronze which provides a governance hierarchy and a framework for delivering strategic, tactical and operational responses to the incident. The incident command should: hold regular coordination meetings provide clear authority for making containment, recovery and communication decisions ensure that technical investigation, operational response and executive oversight are aligned maintain a shared and up-to-date understanding of the situation as it develops ensure decisions are communicated and completed
1.3 Decide whether to disconnect or shut down systems Decide whether to disconnect systems from networks or power them down entirely.	Disconnecting systems (for example from the internet or other internal networks) can: prevent attackers from issuing further commands limit further spread preserve valuable forensic evidence However, it may not stop malicious activity already underway. Shutting systems down may be quicker to implement and may halt active processes, but can: result in loss of investigative evidence make it harder to understand the incident and confirm the attacker has been removed The decision should balance business impact, incident containment, safety, incident investigations and any other relevant factors, informed by specialist advice where available. You may also need to speak to any third parties or suppliers.
1.5 Identify and complete any immediate regulatory or other requirements	This includes: checking if there are laws or regulations which require you to report the incident within a specific timeframe, for example GDPR commencing any investigations or risk assessments, as necessary identifying further potential requirements from other sources, such as cyber insurers
1.7 Establish a central record to log and share situational awareness Set up a central record to capture and share incident information.	A single, authoritative record helps ensure all teams are working from the same understanding and supports effective decision‑making. It may also be required by external parties such as regulators or insurers. The record should capture: what was discovered when it was discovered decisions taken, by whom, and why actions agreed and their status Standardise time references where relevant to avoid confusion. Consider appointing a designated recorder. Learning captured at this stage will also support later recovery, rebuild and improvement activities.
1.8 Establish communications with key stakeholders Establish controlled and coordinated communication channels.	Early communication helps reduce confusion and conflicting messages. Initial stakeholders typically include: senior technical and security leadership legal advisers executive leadership customer relationship managers those providing operational cover and support As the incident develops, communications will need to extend to wider internal and external audiences. Communications should be timely, accurate and coordinated. Consult the NCSC guidance on effective communications during a cyber incident.

Activity

Further information

1.1 Establish an incident command structure

Establish a clear governance structure for directing and coordinating the organisation’s response to the incident. Refer to your cyber incident 'playbook', if you have one.

Decisions made through this structure will guide many of the subsequent response and recovery activities.

To bring together appropriate stakeholders to share information and enable rapid decision making across technical, legal, operational and business areas. Where possible, organisations should use established incident management structures.

In practice, the CEO will normally lead on the organisation’s response to a cyber incident, delegating responsibilities as appropriate to other executive senior leaders.

To support and facilitate effective information flows, put in place sufficient governance to coordinate and control between workstreams. This may include an incident command structure such as Gold, Silver and Bronze which provides a governance hierarchy and a framework for delivering strategic, tactical and operational responses to the incident.

The incident command should:

hold regular coordination meetings
provide clear authority for making containment, recovery and communication decisions
ensure that technical investigation, operational response and executive oversight are aligned
maintain a shared and up-to-date understanding of the situation as it develops
ensure decisions are communicated and completed

1.3 Decide whether to disconnect or shut down systems

Decide whether to disconnect systems from networks or power them down entirely.

Disconnecting systems (for example from the internet or other internal networks) can:

prevent attackers from issuing further commands
limit further spread
preserve valuable forensic evidence

However, it may not stop malicious activity already underway.

Shutting systems down may be quicker to implement and may halt active processes, but can:

result in loss of investigative evidence
make it harder to understand the incident and confirm the attacker has been removed

The decision should balance business impact, incident containment, safety, incident investigations and any other relevant factors, informed by specialist advice where available. You may also need to speak to any third parties or suppliers.

1.5 Identify and complete any immediate regulatory or other requirements

This includes:

checking if there are laws or regulations which require you to report the incident within a specific timeframe, for example GDPR
commencing any investigations or risk assessments, as necessary
identifying further potential requirements from other sources, such as cyber insurers

1.7 Establish a central record to log and share situational awareness

Set up a central record to capture and share incident information.

A single, authoritative record helps ensure all teams are working from the same understanding and supports effective decision‑making. It may also be required by external parties such as regulators or insurers.

The record should capture:

what was discovered
when it was discovered
decisions taken, by whom, and why
actions agreed and their status

Standardise time references where relevant to avoid confusion.
Consider appointing a designated recorder.

Learning captured at this stage will also support later recovery, rebuild and improvement activities.

1.8 Establish communications with key stakeholders

Establish controlled and coordinated communication channels.

Early communication helps reduce confusion and conflicting messages.

Initial stakeholders typically include:

senior technical and security leadership
legal advisers
executive leadership
customer relationship managers
those providing operational cover and support

As the incident develops, communications will need to extend to wider internal and external audiences. Communications should be timely, accurate and coordinated.

Consult the NCSC guidance on effective communications during a cyber incident.

Activity	Further information
1.2 Secure the services of an NCSC-assured cyber incident response (CIR) provider. They should be assured at either the Enhanced or Standard level, as appropriate.	A CIR provider will help your organisation to investigate the incident, to understand: how the attackers gained initial access how they have moved within the environment what actions they have taken whether they have maintained access Understanding attacker activity is critical to: preventing re-compromise informing containment decisions enabling safe recovery of systems Where possible, investigation should take place before systems are restored, as findings will inform impact understanding, regulatory reporting requirements, and system rebuild and recovery decisions. Make sure you allow sufficient time and CIR access for the investigation. Rushing recovery before understanding the incident can significantly increase risk.
1.4 Incident triage: establishing the current operational state Carry out initial triage to understand your organisation’s current position	Before you design your recovery programme, you need to establish a shared understanding of your ‘as-is’ operational state. (This includes activities in 1.4.1 - 1.4.5). Incident command will establish initial priorities and adjust them as more information becomes available and understanding improves. This will shape workaround and recovery efforts, and should not be expected to be fully defined in the first few hours.
1.4.1 Identify critical business functions	Identify critical business functions and ascertain the extent to which they have been affected. The needs of the business must drive prioritisation for recovery, not solely IT considerations.
1.4.2 Assess system impact	Identify which systems remain operational and which are degraded. (Further investigation will be needed to understand if any systems will require rebuilding). Establish if your corporate communications channels are available and can be trusted for use. Where communications channels are unavailable or cannot be trusted, establish alternative mechanisms for communicating with staff, stakeholders and customers. If large numbers of people may be affected, consider setting up dedicated support channels to provide updates, answer questions and manage enquiries.
1.4.3 Identify priority systems and dependencies	Identify which systems – and any systems they rely on to operate – underpin critical business functions and should be recovered first. (These may be outlined in business continuity plans).
1.4.4 Review backups	Ideally backups will support the rebuild of the entire environment, including applications, identity systems and trust services – as well as the data itself. To understand how much support your backups will provide: ascertain when your last backups were taken investigate whether they are available and if they have been compromised
1.4.5 Understand attacker status	Establish from the CIR provider’s findings whether the attacker has been contained or whether risk of further harm remains. This is often inconclusive. Use the provider’s assessment, assumptions and confidence levels to inform decisions about ongoing risk.
1.6 Report the incident to the NCSC Report details of the incident via the NCSC’s Reporting a cyber security incident page	Report the incident if it affects: data on employees, customers or clients of the organisation the organisation's computer firmware, software or hardware personal data The NCSC is not a regulatory body and won’t pass information to regulators without consent. Reporting the incident to the NCSC allows us to provide: expert guidance support in managing the incident potential access to unique information and insights coordinated engagement with other parts of government, if required It also allows the NCSC to spot trends across incidents to understand patterns that might affect the UK broadly. You should be aware that: Reporting using this service does not fulfil any legal or regulatory reporting requirements that you might be subject to. You should always consider whether you are under an obligation to make additional reports of the cyber incident elsewhere. The Cyber Incident Signposting Service can help determine this.

Also see

Guidance