How to Create a Commercial Security Incident Response Plan

A security incident rarely arrives neatly labelled. It may begin with a forced door, an unreachable server, a suspicious contractor, or a member of staff reporting that their access card no longer works.

A security incident response plan gives people clear authority before pressure, confusion and competing priorities take over. It should work at 3am, during a busy trading period, and when the person who normally makes decisions is unavailable.

The aim is not a decorative policy document, but a practical set of decisions, contacts and actions. These support situational awareness during physical, technical or operational disruption, while protecting people, preserving evidence and keeping the organisation operating safely.

Key takeaways

• Put life safety first. A cyber security incident can affect alarms, access control, CCTV, building systems and communications.
• Give named people authority to declare an incident, approve containment and contact emergency services.
• Set severity levels using actual operational impact, not technical jargon alone, to maintain situational awareness as facts develop.
• Preserve forensic evidence before cleaning systems, deleting accounts or allowing automatic logs to overwrite.
• Build UK GDPR reporting decisions into the plan, including the 72-hour ICO deadline where the legal threshold is met.
• Test the plan through realistic tabletop exercises, then assign owners and dates to every improvement.

Start with decisions, not a generic template

A basic plan needs more than a list of steps. It needs decision rules that tell staff what counts as an incident, who must be called, and what may happen without waiting for senior approval.

An incident response plan template is only a starting point. Adapt it to your organisation’s sites, systems and authority structure.

Define the incidents that matter to your operation

Include a cyber security incident, physical security failures and events that cross both areas. Examples include ransomware affecting warehouse scanners, stolen credentials used to enter a data room, CCTV loss during a break-in, or a compromised supplier with remote access to your systems.

Set a clear threshold for activation, giving security operations staff shared situational awareness as an event develops. An information security incident may be based on a credible suspicion of unauthorised access, a loss of security control, a safety risk, or disruption that threatens trading, client commitments or regulated data.

Treat early reports as intelligence, not proof. The first duty is to record, assess and protect, not to guess what happened.

Set severity levels and escalation criteria

Use a small number of severity levels. Four is usually enough. Each should describe business impact, not merely the number of affected devices.

Link each severity level to the information available to decision-makers, so situational awareness improves as the incident develops. Document the incident escalation route, including who is notified at each level and when authority passes to the next decision-maker.

A Grade 4 incident should always trigger a life-safety check. If an intruder is present, a fire system is affected, or staff may be at risk, call 999 first. Physical security, emergency response and cyber containment may need different priorities during an incident. Cyber containment can wait a few minutes. People cannot.

Build a response structure people can use

The incident response team should be small enough to act quickly and broad enough to make sound decisions. Avoid a contact tree that depends on one security manager carrying every answer.

Assign roles before the incident starts

Name a primary and deputy for every role. The incident lead manages the response record, sets incident objectives and calls the next review. IT or cyber leads assess systems, accounts, networks and cloud services. Facilities and security leads protect the site, access points, CCTV, alarms and staff.

The executive response team should not run the technical investigation. Its role is to approve high-impact decisions, such as closing a site, pausing customer service, making a public statement or authorising external specialists.

The wider incident management team coordinates decisions across the business. Legal, privacy, HR, communications, procurement and business continuity leads should be on the wider call-out list. Their involvement depends on the facts, so they don’t all need to join the first call.

Create a contact tree and a single record

Keep contact details offline as well as in a secure digital location. Include emergency communication arrangements for emergency services, site contacts, alarm and access-control providers, cyber insurers, legal advisers, digital forensics support, key suppliers and client contacts.

Use one incident log, one communication plan and one person responsible for updates. The plan should define the channel, update owner, approval route and fallback method. Teams can work in parallel, but their decisions need a single time-stamped record that maintains shared situational awareness.

The executive response team approves high-impact actions, including site closure, public statements, customer-service pauses and external support. The plan should make those approval points clear before an incident occurs.

A practical first-hour checklist should require the incident lead to:

• confirm immediate safety and call emergency services where needed;
• open an incident ticket and record the first known facts;
• assign a severity level and notify the correct response group;
• protect relevant systems, locations, recordings and access records;
• schedule the next update to maintain situational awareness, even when the available information is incomplete.

Structure the security incident response plan around the lifecycle

A commercial response plan should follow a recognisable incident response lifecycle, whilst fitting your buildings, staff and technology. It should move from preparation and detection through response, recovery and learning. NIST SP 800-61 Revision 3 groups the work around detecting, responding to and recovering from incidents. Many organisations also retain the familiar four-stage model from earlier guidance: preparation, detection and analysis, containment and recovery, then post-incident activity.

Prepare for the incidents you can reasonably expect

Start with a current asset and dependency list. Record critical doors, CCTV systems, alarm panels, servers, cloud platforms, visitor-management systems, payment terminals and third parties with privileged access. Use it to create shared situational awareness of critical services and their dependencies.

A small office may rely on a managed IT provider and one building manager. A multi-site logistics operation may need site-by-site call trees, alternate control rooms and different procedures for depots that operate through the night. The risk profile should decide the detail.

Plan for accessibility too. If a building must be evacuated or access routes restricted, identify how staff and visitors with mobility, hearing, visual or communication needs receive assistance and updates.

Detect, analyse and triage without delay

Give control-room staff, reception teams and employees a simple route to report concerns. Record the source, time, system or location affected, people involved and any action already taken. These details support rapid situational awareness during the initial assessment.

Incident triage asks practical questions: Is anyone at risk? Is the event ongoing? Which services are unavailable? Does the incident involve personal data, client data, money, keys, access credentials or public safety? It may indicate a cyber security issue, physical security incident or operational impact. Triage and containment decisions should not wait for completed root cause analysis.

Contain the threat without losing the evidence

Containment and eradication are often treated as one hurried task. They are not. A decision that stops an attacker may also destroy the evidence needed to understand the incident, support an insurance claim or respond to regulatory scrutiny.

Isolate first, then document the choice

Isolation may mean disabling a user account, blocking remote access, separating a network segment, securing a room or suspending a supplier connection. Record who approved the action, when it happened and which business service it affected.

Keep an incident log showing decisions, timestamps and system state. This supports situational awareness while helping investigators reconstruct what happened.

Don’t casually restart devices, reimage laptops, delete emails or allow camera footage to overwrite. Where safe and appropriate, preserve volatile information first, then retain relevant logs from identity platforms, firewalls, VPNs, email, cloud services, EDR tools and access-control systems.

Maintain chain of custody and recover carefully

For physical and digital forensic evidence, record who collected it, when, where it was stored and every transfer of control. Note how it was protected for investigation, insurance and regulatory scrutiny. Include time zones, clock differences and the system time shown in logs. Those ordinary details can become important later.

Recovery should be controlled. Treat containment and eradication as separate gates before returning systems to normal. Test restored systems, reset compromised credentials, verify alarms and access controls, and monitor for repeat activity. Business continuity and disaster recovery arrangements should state which services can run manually, which must remain offline, and who can approve a return to normal operations.

For a live cyber incident, specialist assistance may be needed, but don’t delay life-safety action. The NCSC response and recovery guidance says organisations can call 0300 123 2040 immediately. Keep that number in the offline contact pack.

Build legal, privacy and reporting decisions into the plan

A response plan isn’t legal advice. It should map legal and regulatory requirements to owners, deadlines, evidence and approval routes. This makes it harder to miss a reporting deadline or lose facts advisers need.

Apply the UK GDPR decision process

A personal data breach can involve loss, alteration, unauthorised disclosure of, or access to personal data. Where it is likely to risk individuals’ rights and freedoms, the controller must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.

The ICO’s breach reporting guidance explains the reporting threshold and timing. The 72-hour period does not start after a lengthy internal investigation. The plan should require the privacy lead and legal advisers to assess reportability as soon as credible facts emerge.

Gather facts for partial reporting

An early report may be incomplete. The ICO allows organisations to provide available information and submit updates as the investigation develops. Keep a pre-prepared facts sheet covering what happened, when it was found, data categories, affected people, likely consequences, containment action and notifications already made.

The ICO’s 72-hour response guidance notes that its online form cannot be saved for later completion. That is a small operational detail with a real consequence.

Inform affected individuals where required, agreeing wording with qualified legal and privacy professionals. Decide on partial reporting, later updates, client notifications, insurer notifications and police contact according to the circumstances and applicable obligations. Don’t send broad assurances before the incident is understood.

Turn the plan into playbooks and runbooks

The core plan sets authority. Playbooks and runbooks turn it into short procedures for recurring incident types. A ransomware attack playbook, for example, shouldn’t be a twelve-page technical manual. It should tell the first responder how to isolate devices, protect backups, preserve evidence, call the right people and keep operations safe.

Write playbooks around decisions and handovers

Create separate playbooks for ransomware, endpoint malware infection, phishing and account compromise, lost keys or cards, CCTV failure, unauthorised entry, supplier compromise and loss of a critical building system.

Each playbook should answer five questions: what triggers it, what must happen in the first hour, how containment and eradication should be managed, what evidence must be preserved, and who needs an update. The phishing and account-compromise guidance should explain when to isolate a device or account after a suspected malware infection. Add a short template for the first internal update:

“We are investigating a security incident affecting [service or location]. The current priority is [safety, containment or continuity]. Do not delete records, restart affected equipment or discuss the incident externally. The next update is due at [time].”

Connect actions to ticketing and approvals

A plan sitting in a shared drive is not enough. Link it to your incident ticketing process, access-control records, CCTV retention settings, asset register and business continuity procedures. Together, these links give responders situational awareness, support security operations and help protect evidence during a live incident.

Use mandatory fields for severity, incident owner, affected service, evidence location and next review time. This also helps teams align response decisions with business continuity requirements.

This is where generic templates often fail. They list responsibilities but don’t show who records the decision to disconnect a site, close a loading bay or suspend a supplier account. Build those approvals into the workflow, so security operations, evidence preservation and continuity decisions are recorded clearly.

Test the plan before an incident tests it for you

A tabletop exercise shows whether the plan works across departments. It also exposes gaps that normal meetings miss, such as an outdated emergency number, unclear authority to close a building or a backup that cannot be restored.

Use realistic commercial scenarios

Run a tabletop exercise involving security and operations. A useful example is a ransomware attack disrupting a distribution site’s access control and dispatch systems during a peak delivery period. Add incomplete information, an anxious client and an unreachable supplier to test the group’s situational awareness.

Ask participants what they would do to maintain situational awareness in the first 15 minutes, first hour and first day. Include facilities, IT, HR, communications, the executive response team and a senior decision-maker. If public emergency services might be involved, test how information would be handed over.

Turn findings into accountable changes

Record the exercise timeline, disagreements, missing evidence and decisions that took too long. A post-incident review should capture exercise findings and real-event lessons, assign each corrective action to a named owner and set a due date and completion check.

Review the plan after major changes to systems, sites, suppliers, contracts or legal obligations. A plan that hasn’t been updated since a new access-control platform was installed is not an incident response plan. It is an old document.

Frequently asked questions

What should a commercial incident response plan include?

It should provide situational awareness, giving responders a shared view of safety, systems, evidence, communications and continuity priorities. Include incident definitions, severity levels, named roles and deputies, 24/7 contacts, escalation rules, evidence handling, legal and privacy assessment, recovery procedures, playbooks and a test schedule.

Who should lead the executive response team?

A senior leader with authority to make operational and financial decisions should chair it. The security or IT incident lead manages the working response. Keeping those duties separate prevents senior discussions from slowing containment.

How often should the plan be tested?

Test after a significant operational change and at regular intervals that suit the organisation’s risk profile. High-risk, multi-site or heavily regulated operations need more frequent exercises than a small, low-complexity office.

A plan is only useful when it can be used

A good commercial security incident response plan makes the first hour less chaotic. It tells people who decides, what must be protected, who needs to know and when external support is required.

Keep it practical, current and tested. Clear authority and reliable records matter more than a long document full of vague promises.