Incident Response for Defence Suppliers: What Your Plan Needs to Contain

A cyber incident rarely arrives at a convenient time.

It may begin with a compromised account, ransomware alert, suspicious administrator activity, leaked credentials, malicious email, data loss, or a supplier telling you that one of their systems has been breached.

For organisations operating in the UK Defence supply chain, the question is not simply:

“Can we stop every incident?”

No organisation can guarantee that.

The more important question is:

“If something happens, can we detect it, contain it, make the right decisions, recover safely and demonstrate what we did?”

That is why incident response is such an important part of cyber resilience.

The Ministry of Defence’s Cyber Security Model Version 4 places the emphasis on organisational security and resilience, with the specific controls required depending on the Cyber Risk Profile assigned to the contract. Defence Standard 05-138 Issue 4 defines those controls across Levels 0–3. GOV.UK

For Defence suppliers, a credible incident-response capability therefore needs to be more than a document sitting in SharePoint.

It needs to work.

What is an incident response plan?

An incident response plan is the organisation’s agreed approach to dealing with a cyber-security incident.

It should answer practical questions such as:

• Who takes control?

• Who needs to be contacted?

• How do we determine how serious the incident is?

• What systems need to be isolated?

• How do we communicate internally?

• When do we involve customers, the MOD, regulators, insurers or law enforcement?

• How do we preserve evidence?

• How do we recover safely?

• What do we learn afterwards?

The NCSC recommends planning incident response in advance, exercising the response and reviewing capabilities, including those provided by third parties. It stresses that successful response depends on people, process and technology working together. National Cyber Security Centre

That is particularly important for SMEs.

During a real incident, people are under pressure.

Decisions that appear obvious on a normal working day can become difficult when email is unavailable, files are encrypted and customers are calling.

A good plan removes some of that uncertainty.

1. Clearly define who is responsible

The first requirement is ownership.

Someone needs to be responsible for coordinating the response.

For a smaller organisation, the incident-response team may include only a few people:

• Managing Director or senior decision-maker;

• internal IT lead or MSP;

• security provider or SOC;

• legal adviser;

• data-protection lead;

• communications or customer lead.

For larger suppliers, the structure may be more formal.

The NCSC recommends maintaining key contacts for IT, incident-response providers, senior management, legal, PR, HR and insurers, with alternative contact methods in case normal communications are unavailable. National Cyber Security Centre

The crucial point is:

Everyone should know who can make decisions when something goes wrong.

2. Define what counts as an incident

Not every security event should trigger a full crisis response.

Organisations need criteria for distinguishing:

• routine security alerts;

• suspected incidents;

• confirmed incidents;

• major or business-disrupting incidents.

Examples might include:

Lower severity

• isolated phishing email;

• blocked malware;

• unsuccessful suspicious login.

Higher severity

• compromised privileged account;

• ransomware;

• confirmed data exfiltration;

• loss of Defence-related information;

• compromise of critical systems;

• widespread endpoint infection;

• malicious activity affecting suppliers;

• extended outage caused by a cyber attack.

A documented severity model helps prevent both under-reaction and panic.

3. Build clear escalation criteria

Once an incident is identified, staff need to know when to escalate it.

Escalation criteria might consider:

• systems affected;

• data involved;

• classification or sensitivity of information;

• number of users affected;

• whether privileged accounts are involved;

• operational disruption;

• evidence of data theft;

• impact on Defence-related services;

• whether subcontractors are affected;

• contractual notification requirements.

The NCSC specifically recommends defining escalation criteria and a process for making critical decisions in advance. National Cyber Security Centre

Without this, escalation can depend on who happens to notice the incident first.

4. Know how to communicate if normal systems fail

This is frequently overlooked.

If Microsoft 365 has been compromised, should the response team continue coordinating everything through Teams and Exchange?

Possibly not.

If identities are compromised, the attacker may be able to read those communications.

An incident-response plan should therefore include out-of-band communication arrangements.

That might include:

• alternative telephone numbers;

• dedicated emergency conference facility;

• secure external messaging;

• printed contact details;

• an alternative email platform;

• emergency access procedures.

The NCSC recommends including at least one always-available conference mechanism in the response plan. National Cyber Security Centre

The point is simple:

Your response plan should still work when your normal IT does not.

5. Contain the incident without destroying evidence

The immediate instinct during a cyber incident is often:

Turn everything off.

Sometimes that may be appropriate.

Sometimes it can destroy evidence or make investigation more difficult.

Containment actions need to be proportionate.

Examples could include:

• disabling compromised accounts;

• revoking sessions;

• isolating endpoints;

• blocking malicious IP addresses or domains;

• resetting credentials;

• restricting administrator access;

• segmenting systems;

• temporarily disabling external sharing.

But these decisions should ideally be made with consideration for forensic evidence and recovery requirements.

The NCSC's latest guidance for highly disruptive attacks separates response into immediate activity, recovery and investigation, followed by rebuilding. National Cyber Security Centre

That structured approach is far safer than making improvised changes under pressure.

6. Preserve evidence

For Defence suppliers, being able to establish what happened may be commercially and contractually important.

Useful evidence might include:

• authentication logs;

• security alerts;

• endpoint telemetry;

• firewall records;

• Defender or SIEM incidents;

• email traces;

• administrator activity;

• affected files;

• timestamps;

• screenshots;

• user reports;

• copies of malicious emails.

Organisations should understand:

• which logs are available;

• how long they are retained;

• who can access them;

• how evidence will be protected;

• when specialist forensic support should be engaged.

This is another reason logging needs to be configured before an incident.

You cannot retrospectively collect logs that were never retained.

7. Understand notification obligations

This is particularly important in Defence.

Notification requirements can come from several places:

• MOD contracts;

• Defence security conditions;

• Security Aspects Letters;

• customer agreements;

• UK GDPR;

• ICO requirements;

• insurers;

• other regulators.

There are also Defence-specific reporting expectations.

The MOD's Industry Security Notice catalogue includes specific guidance requiring suppliers to report security incidents affecting Defence-related classified material to the MOD. GOV.UK

The exact requirement depends on the information involved and contractual context.

That means a supplier should establish its reporting obligations before an incident occurs.

The incident-response plan should clearly record:

who needs to be told, under what circumstances, by whom, and within what timeframe.

8. Include specific incident playbooks

A generic incident-response document is useful.

Specific playbooks are better.

The NCSC recommends creating guidance for particular incident types alongside the main response plan. National Cyber Security Centre

For example:

Business Email Compromise

Actions might include:

• disable or secure the account;

• revoke sessions;

• reset credentials;

• review MFA changes;

• inspect forwarding rules;

• check sent items;

• identify affected external parties.

Ransomware

Actions might include:

• isolate affected devices;

• identify spread;

• preserve logs;

• protect backups;

• invoke business-continuity arrangements;

• begin forensic investigation.

Lost or stolen device

Actions could include:

• remotely lock or wipe;

• revoke tokens;

• verify encryption;

• assess information stored locally;

• determine notification obligations.

Data leakage

Actions may include:

• stop further exposure;

• determine what information was accessed;

• identify affected parties;

• preserve evidence;

• assess legal and contractual reporting.

Playbooks reduce decision-making time when an incident actually occurs.

9. Link incident response to business continuity and disaster recovery

Incident response should not sit in isolation.

The NCSC recommends linking incident-response planning with:

• business continuity;

• disaster recovery; and

• communications planning. National Cyber Security Centre

These plans answer different questions.

Incident response:
How do we contain and investigate the attack?

Business continuity:
How do we keep critical business functions operating?

Disaster recovery:
How do we restore systems and data?

Those activities need to work together.

For example, an organisation may successfully remove ransomware but still be unable to operate because its ERP system cannot be restored.

That is not a successful recovery.

10. Decide what minimum viable operations look like

The NCSC's July 2026 guidance on disruptive cyber attacks highlights the importance of restoring organisations to minimum viable operations during recovery. National Cyber Security Centre

For a Defence supplier, this means identifying:

• which services absolutely must operate;

• which systems support those services;

• which people need access;

• which suppliers are critical;

• what manual workarounds exist.

For example:

Critical

• customer communications;

• manufacturing system;

• identity;

• email;

• payroll;

• secure document access.

Lower priority

• marketing systems;

• non-critical reporting;

• internal collaboration tools.

The priorities should be agreed before the crisis.

11. Test the plan

An incident-response plan that has never been tested is largely theoretical.

Testing can be simple.

A tabletop exercise could present the leadership team with a scenario such as:

A privileged Microsoft 365 administrator account has been compromised. An attacker has accessed SharePoint and created external forwarding rules. Defender has identified suspicious activity, but you do not yet know whether information has been stolen.

Then ask:

• Who takes control?

• Who gets called?

• What happens first?

• Do we disable the account?

• What logs do we need?

• Who talks to customers?

• Do we notify the MOD?

• Can staff communicate securely?

• How would we recover?

The purpose is not to catch people out.

It is to discover weaknesses before a real attacker discovers them for you.

12. Record what happened

During an incident, maintain a clear chronology.

Record:

• what was discovered;

• when;

• decisions made;

• who approved them;

• actions taken;

• evidence collected;

• communications sent;

• systems affected;

• recovery milestones.

This helps with:

• investigation;

• regulatory reporting;

• contractual assurance;

• insurance claims;

• post-incident reviews.

It also creates valuable evidence that the organisation has an operational incident-management process.

13. Conduct a post-incident review

Once systems are restored, the incident should not simply be closed.

Review:

What happened?

Why was it possible?

What worked well?

What failed?

What needs to change?

Actions might include:

• modifying Conditional Access;

• increasing log retention;

• removing administrator rights;

• improving monitoring;

• changing backup processes;

• updating training;

• strengthening supplier controls.

This is how an incident improves the organisation rather than simply disrupting it.

Where does this fit with CSMv4 and DCC?

Under CSMv4, the Cyber Risk Profile assigned to a Defence requirement determines the controls the supplier must satisfy under Defence Standard 05-138 Issue 4. GOV.UK

As the Cyber Risk Profile increases, the expectations around organisational resilience and the ability to evidence security controls also increase.

Incident-response capability therefore needs to be viewed as part of the wider assurance environment alongside:

• identity security;

• endpoint management;

• vulnerability management;

• monitoring;

• backup and recovery;

• governance;

• supply-chain security.

A mature supplier should also be able to produce evidence that incident processes are actually in operation.

That could include:

• incident-response policy;

• contact lists;

• playbooks;

• exercise records;

• actual incident tickets;

• post-incident reviews;

• remediation records.

This links directly to the evidence-readiness principles covered elsewhere in our DCC guidance.

What should your plan contain?

At minimum, I would expect a Defence supplier's incident-response plan to clearly cover:

• incident ownership;

• emergency contacts;

• incident classification;

• escalation criteria;

• alternative communications;

• technical containment;

• evidence preservation;

• legal and contractual reporting;

• MOD/customer notification requirements;

• specific incident playbooks;

• business continuity;

• recovery;

• documentation;

• post-incident review.

And perhaps most importantly:

people should actually know the plan exists.

How Symposium IT can help

Symposium IT helps UK Defence suppliers strengthen the technology and operating processes behind cyber resilience.

Through Symposium Defence, that includes reviewing areas such as:

• Microsoft 365;

• Entra ID;

• Intune;

• Defender;

• Azure;

• endpoint management;

• security monitoring;

• backup and recovery;

• identity;

• incident response;

• policies and evidence;

• wider CSMv4 and DCC readiness.

An incident-response review can help answer a simple but important question:

If something happened tomorrow, would your organisation know what to do?

For businesses operating in Defence, that should not be left to chance.

Explore Symposium Defence to learn more about cyber readiness and incident-response capability.