An incident response plan works under pressure when it settles the hard decisions in advance: who leads, how serious the incident is, who may act and who speaks. This guide gives six steps for an IT head or manager at a firm in India or the GCC. The firm has a small team and no dedicated incident team, and each step ends in a decision you write down. The incident response process on the day should be short enough to follow late at night, with email down. It covers building and testing your own plan, starts once you declare an incident, and is general information, not legal advice. If you want the detection side, see our page on improving threat detection and response.
Last reviewed 2026-11-01 by Manish Sharma.
How to Build an Incident Response Plan, and Where NIST Stands
Build the plan in six steps. Know what the business depends on, decide who decides and set severity levels. Then write the first-hour sequence, decide what you will say and over which channel, and test and review. Each step ends in a decision. Unlike a published standard, the order, the table rows, the severity layout and the first-hour sequence are Signisys’ own explanation.
As of November 2026, NIST SP 800-61 Rev. 3, published in April 2025, is the current NIST guidance on incident response. It supersedes Rev. 2 (August 2012) and organises its recommendations around the six functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. NIST maps Rev. 2’s Preparation phase to Govern, Identify and Protect, and shows incident response itself as Detect, Respond and Recover. Rev. 2 used four phases, and that is the previous model. NIST also advises organisations to use the incident response life cycle model that suits them best, and to base each cybersecurity plan on the organisation’s own requirements, mission, size, structure and functions.
CISA’s undated IRP Basics guide, read November 2026, describes a plan that senior leadership approves. NIST describes incident response plans as providing the roadmap for implementing incident response. If you need the definition, read what incident response is. On the day, the incident response process is the sequence you follow. In our suggestion it fits on one page.
Key Takeaway Decide in advance what you would otherwise argue about during the incident.
Incident Response Plan Step 1: Know What the Business Depends On
Make a short list of the systems and data whose loss would stop the business, including one owner for each. If you have no such list, our guide to ranking your cyber risks is a way to make one. The Canadian Centre for Cyber Security’s ITSAP.40.003 (January 2026) places a “Before creating an incident response plan” section ahead of its life-cycle stages. Those run from preparation to post-incident activities and lessons learned. The list itself, however, is a Signisys step, not taken from that page.
NIST also recommends synchronising business continuity plans with incident response plans, since incidents can undermine business resilience. In our words, the response plan stops an active incident, while the continuity plan keeps the business running.
Decision to write down: the list itself, with an owner and a backup owner for each system. Perhaps five to ten systems fit, such as the finance system, email, the customer database and the main authentication service.
Step 2: Decide Who Decides
Name each role, and give each a backup you can reach if email is down. CISA’s guide describes three roles. An incident manager runs the response, tasks and communication and does no technical work. A technical manager is the expert, and a communications manager deals with outside parties. The Canadian Centre lists team roles including security practitioners, IT specialists, legal and management. The six rows below are Signisys’ own set, with roles, not names.
| Decision | Who decides | Write down in the incident response plan |
|---|---|---|
| When to declare an incident | The incident manager decides, or the technical manager if absent. | The plan states the test, for example a confirmed unauthorised sign-in to a listed system. |
| Whether to isolate a system from the network | The technical manager decides, or the incident manager if absent. | If the system is on the Step 1 list, the plan names who to tell first. |
| Whether to bring in outside help or a forensic firm | The executive sponsor decides, or the incident manager if absent. | The plan holds the contact details and the manager’s approval limit. |
| Speak to staff and customers | The communications manager drafts, and the executive sponsor approves. | The incident response plan names the channel and a backup approver. |
| Whether to contact police, insurers or a regulator | The executive sponsor decides, when the legal adviser has given advice. | The plan lists the legal adviser’s out-of-band number. |
| When to return a system to normal use | The technical manager proposes, and the incident manager signs off. | The plan states the checks to finish before sign-off. |
CISA advises reviewing the plan with an attorney. CISA is a US agency, so in India and the GCC, ask your own legal adviser.
Incident Response Plan Step 3: Set Severity Levels in Advance
When you write three or four severity levels, say for each level who to tell, who may act alone and what needs approval. The number of levels is a Signisys suggestion; pick the number your team can tell apart in a hurry. Keep the levels in a format such as a small table that anyone can read at a glance.
For categorising and prioritising incidents, NIST gives examples of possible risk evaluation factors: asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability. You can use them to define each level, while keeping the wording your own. This guide sets no response times, because they depend on your systems and staff.
NIST sets no severity labels. Some firms use P1 to P4, but the labels are your choice.
NIST lists definitions of events and cybersecurity incidents among the key elements of an incident response policy. Write down what counts as each in your firm; deciding in advance which alerts are only events is a Signisys suggestion.
Decision to write down: the levels, the label for each, and the three facts per level (who to tell, who may act alone, what needs approval).
Step 4: Write the Incident Response Process for the First Hour
The first hour needs one short sequence, which the incident manager can read aloud when the team is under pressure. This one is a Signisys sequence, and it is deliberately not a list of phases:
Confirm the incident and declare it.
Open a time-stamped log before anything else.
Use the out-of-band contact list if email is down.
Choose the severity level from Step 3, and change it later if the facts change.
Decide the first containment step, such as isolating one system.
Do this before you wipe anything.
Start the communication timeline while the response is under way.
NIST advises considering documented procedures for common types of incident, as well as procedures for urgent processes such as redeploying the organization’s primary authentication platform. It notes that some organisations write playbooks for this, and points to CISA’s playbooks as examples. Keeping each playbook to one page is a Signisys suggestion. Choose three scenarios that match the Step 1 list, and write one page for each. While ransomware is one example scenario, this guide does not cover it; ransomware protection and recovery has its own guide. Our article on what goes wrong when you restore follows one such attack through to recovery.
Print the first-hour page, and keep it with the contact list in case email is down.
Step 5: Decide What You Will Say, and Over Which Channel
A response only works if people can reach each other. CISA advises printing the plan and the contact list for everyone expected to play a role, as internal email, chat and document storage may be down during an incident. The Canadian Centre says each team member should have a backup contact, and mentions alternate means of contact such as mobile phones or out-of-band email. Decision to write down: where you keep the printed copy, and who holds it.
Also write down who speaks. In CISA’s roles, the communications manager deals with outside parties. In our suggestion, that person drafts, and the executive sponsor or the legal adviser approves. CISA advises preparing press responses in advance and mentions a “holding statement”. The layout is a Signisys suggestion. It is a short statement saying what you know, what you are doing and when the next update will come.
Reporting duties differ by sector and country. In India, CERT-In issues reporting directions; ask your legal adviser which apply to you. To see how reporting fits into one illustrative incident, read the last step of a device compromise.
Incident Response Plan Step 6: Test It, Then Keep It Current
A tabletop exercise has a facilitator present a scenario to the team while people play their roles. CISA describes it this way. Bring away a list of edits to the plan, including an owner and a date for each; that is a Signisys suggestion. Test the contact list out of band at the same time. For a quick audit check that the plan has been rehearsed, read check 18 of the network audit list.
The sources differ on rhythm. CISA suggests a quarterly review, the Canadian Centre says to test, revisit and revise annually, and NIST says to review and update plans periodically or when a need for significant improvements is identified. Choose a rhythm, and write it into the plan.
When a real incident is over, hold a blameless retrospective. CISA says it should update policies and procedures and tell staff the lessons from it. NIST says lessons learned can be shared as soon as they are identified, not delayed until after recovery concludes. A review after each real incident keeps the plan honest.
Decision to write down: the date of the next exercise, the facilitator, and the owner of the plan.
Key Takeaway A plan counts as built when each step has its written decision and a named owner.
What This Guide Does Not Cover
This guide leaves out four things. Why attacks go unnoticed is the subject of our detection guide. Scoring how ready you are belongs in a readiness checklist, which is a separate guide. Our threat hunting guide covers tool choices, while legal advice on reporting is for your own adviser. The scope is a how-to for building and testing your own plan from a small team’s point of view, unlike a readiness checklist.
Signisys provides cybersecurity services for growing firms, including help with planning and exercises, and we can talk through your draft with you.
Incident Response Plan FAQ
What is the difference between an incident response plan and a playbook?
Who leads the response after you declare an incident?
Does NIST still use four phases for incident response?
Which severity levels does an incident response plan need?
Can a small IT team write its own incident response plan?
When should you review and test the plan?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.