Incident Response Plan Guide (No SOC)

TL;DR — An incident response (IR) plan is the documented, rehearsed, decision-ready playbook your organisation follows when a security event hits — before you know the scope, before leadership is briefed, and before anyone remembers what to do under pressure. It is anchored on NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide), ISO/IEC 27035 (Information Security Incident Management), the SANS Incident Handling Process, and MITRE ATT&CK for adversary-behaviour mapping. It covers six phases: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. This guide walks through each phase in depth, explains how to build an IR capability when you do not have a dedicated Security Operations Centre, provides playbook templates, communication protocols, evidence-preservation procedures, regulatory notification timelines (GDPR 72 hours, India DPDP Act, CERT-In 6 hours), retainer models, and tabletop exercises. Written for founders, CTOs, and heads-of-engineering at organisations that know they need a plan but have neither a SOC nor a CISO on staff.

Why you need an IR plan before you need a SOC#

Most organisations that suffer a breach do not fail because their defences were weak. They fail because no one knew what to do in the first ninety minutes. An IR plan is not a luxury reserved for enterprises with 24/7 SOC teams. It is the minimum viable response capability — the difference between a contained security event and a front-page data breach.

The economics are straightforward. Industry analyses consistently demonstrate that organisations with a tested IR plan reduce both the duration and the financial impact of breaches. The plan itself costs nothing but time. The absence of one costs everything else.

If you have a product in production, customer data in a database, and regulatory obligations in any jurisdiction — you need an IR plan. The SOC can come later. The plan cannot wait.

Framework foundations#

Four frameworks anchor a rigorous IR plan. Every procedure, every playbook, and every post-incident report should trace back to at least one.

NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide. The most widely referenced IR framework globally. Defines four phases (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity). Published by the US National Institute of Standards and Technology. Free, publicly available, and the de facto baseline that auditors expect.

ISO/IEC 27035:2023 — Information Security Incident Management. The international standard, published in three parts: principles, planning & preparation, and operations. If your organisation is ISO 27001-certified or pursuing certification, your IR plan must align here. The standard expects documented procedures, defined roles, evidence-handling rules, and a post-incident review cycle.

SANS Incident Handling Process. The six-phase model (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) taught in SANS SEC504 and GCIH. More granular than NIST's four phases. This guide uses the SANS six-phase structure because it separates containment, eradication, and recovery into distinct decision points — which matters when you are operating without a SOC and need clear stage gates.

MITRE ATT&CK. Not an IR framework per se, but the adversary-behaviour taxonomy your IR team uses to classify what the attacker did, map lateral movement, and communicate findings in a language that threat intelligence, detection engineering, and external responders all understand.

The six phases of incident response#

Phase 1: Preparation#

Preparation is everything you do before an incident occurs. It is the phase most organisations skip and the phase that determines whether the remaining five work.

What preparation actually requires:

IR plan document — written, version-controlled, accessible offline (printed copies stored separately from the network). Not a wiki page no one has read.
IR team roster with contact details — names, roles, mobile numbers, personal email addresses (not corporate, which may be compromised). Include alternates for every role.
Communication channels — a pre-agreed out-of-band channel (Signal group, personal mobile chain, dedicated Slack workspace on a separate account) that does not depend on the infrastructure you are investigating.
Tooling baseline — forensic imaging tools, log aggregation access, endpoint detection and response (EDR) console access, network capture capability. Confirm that at least two people know how to operate each tool.
Legal and regulatory contacts — outside counsel (ideally with cyber-incident experience), your Data Protection Officer or privacy lead, insurance broker (if you carry cyber insurance), and regulatory notification contacts for every jurisdiction you operate in.
Retainer agreements — if you do not have in-house forensics capability, a pre-signed retainer with an IR services firm means they answer your call on day zero, not day five. Negotiate scope and rates before the incident, not during it.
Asset inventory — you cannot defend what you do not know you have. At minimum: a list of internet-facing services, critical internal systems, data stores containing personal or sensitive data, and the network segments they sit on.
Baseline documentation — known-good configurations, network diagrams, DNS records, firewall rules, access-control lists. You need a reference point to identify what changed.
Tabletop exercises — at least twice per year, run a scenario-based exercise with the full IR team. More on this below.

Phase 2: Identification#

Identification is the phase where you determine whether a security event is actually a security incident — and begin scoping its extent.

The identification challenge without a SOC: A SOC monitors alerts in real time. Without one, your identification sources are narrower — but they still exist:

Alerts from managed services — if you use a managed detection and response (MDR) provider, a cloud security posture management (CSPM) tool, or even basic alerting from your cloud provider (AWS GuardDuty, Azure Defender, GCP Security Command Centre), these are your first-line detection.
Employee reports — a user noticing unusual account activity, a developer seeing unexpected database queries, a customer reporting suspicious emails from your domain.
External notification — a security researcher, a CERT, a law enforcement contact, or (worst case) a journalist telling you about your own breach.
Automated log monitoring — even basic log-shipping to a SIEM or log aggregator with threshold-based alerts gives you detection capability.

Identification checklist:

Confirm the event is real (not a false positive, not a test, not an operational error)
Assign an initial severity level (use a simple scale: Critical / High / Medium / Low)
Assign an incident ID and open an incident log (timestamped, append-only)
Identify the initial scope: which systems, which data, which users
Activate the IR team or the relevant subset
Begin evidence preservation immediately (see evidence-preservation section below)

Mapping to MITRE ATT&CK: During identification, begin classifying observed attacker behaviour against ATT&CK tactics. Did you observe initial access (T1190 Exploit Public-Facing Application, T1566 Phishing)? Execution (T1059 Command and Scripting Interpreter)? Discovery (T1087 Account Discovery)? Even a rough mapping at this stage helps your containment decisions and helps any external responders you bring in later.

Phase 3: Containment#

Containment stops the bleeding. The goal is to limit the attacker's access and prevent further damage — without destroying evidence or causing more harm than the attacker did.

Short-term containment — immediate actions to stop active damage:

Isolate affected systems from the network (disable the NIC, move to a quarantine VLAN, revoke cloud-instance network access — do not power off, which destroys volatile memory)
Revoke compromised credentials (passwords, API keys, tokens, certificates)
Block known attacker IPs or domains at the perimeter
Disable compromised user accounts

Long-term containment — stabilise the environment while you prepare for eradication:

Deploy temporary monitoring on the affected segment
Patch the exploited vulnerability if it can be done without disrupting evidence collection
Stand up clean replacement systems if the affected ones must remain isolated for forensics
Implement additional access controls on sensitive data stores the attacker may have targeted

Critical containment decisions:

Isolate vs. monitor. Sometimes you learn more by watching the attacker than by cutting them off. This is a judgement call that depends on your risk tolerance, the sensitivity of the data at stake, and your monitoring capability. Without a SOC, err on the side of isolation — you are unlikely to have the real-time monitoring depth to safely observe an active attacker.
Preserve evidence vs. restore service. Forensic imaging takes time. Business operations need the system back. This tension is real. The general rule: image first, restore second. If you must restore immediately, take a full disk snapshot (cloud providers make this trivial) and a volatile-memory dump before doing anything else.

Phase 4: Eradication#

Eradication removes the attacker's presence from your environment entirely. Containment stops the immediate threat; eradication ensures the attacker cannot return through the same path.

Eradication activities:

Identify the root cause — how did the attacker get in? Unpatched vulnerability, compromised credential, phishing, supply-chain compromise, misconfigured access control?
Remove all attacker artefacts — malware, web shells, backdoor accounts, persistence mechanisms (scheduled tasks, cron jobs, startup scripts, registry keys), rogue SSH keys
Patch the exploited vulnerability across all affected systems, not just the compromised one
Rotate all credentials that were exposed or potentially exposed — including service accounts, API keys, database passwords, and TLS certificates if private keys were on the compromised host
Verify eradication — scan for indicators of compromise (IOCs) across the full environment, not just the systems you already know about
Update detection rules — add the attacker's TTPs (tactics, techniques, and procedures) to your monitoring so you detect a return

Common eradication failure: Rotating the compromised user's password but not the service-account credentials on the same host. Attackers who gain access to a server routinely harvest every credential on it. If you rotate selectively, you leave the back door open.

Phase 5: Recovery#

Recovery returns affected systems and services to normal operation with confidence that the environment is clean.

Recovery steps:

Restore systems from known-good backups or rebuild from clean images — never restore from a backup taken after the compromise began
Verify system integrity before reconnecting to the production network (file-integrity checks, configuration audits against your baseline documentation)
Monitor recovered systems intensively for a defined period (7-30 days, depending on severity) — watch for signs of re-compromise
Re-enable user access in a controlled sequence — critical systems first, with additional monitoring
Confirm business operations are functioning normally
Communicate recovery status to stakeholders (see communication protocols below)

Recovery validation: Before declaring the incident resolved, confirm:

The exploited vulnerability is patched across the environment
All compromised credentials have been rotated
No attacker artefacts remain (verified by scan, not assumption)
Monitoring is in place to detect a return
Affected users and customers have been notified as required

Phase 6: Lessons learned#

Lessons learned is the phase that transforms a painful incident into a permanent improvement. It is also the phase most organisations skip because everyone is exhausted and wants to move on. Do not skip it.

Conduct a post-incident review within 5-10 business days. Not three months later. Not "when things calm down." While the details are fresh.

The review must answer:

What happened? (Timeline of events, from initial compromise to full recovery)
How was the incident detected? (And how long was the attacker present before detection — the dwell time)
What worked well in the response?
What did not work? (Be specific: "We could not reach the CTO for four hours because the contact list had an old number" is a useful finding)
What will we change? (Each change must have an owner and a deadline)

Document everything. The post-incident report is a formal deliverable. It feeds into your risk register, your IR plan updates, your detection-rule improvements, and your next tabletop exercise scenario.

Building an IR team without a full SOC#

You do not need a 24/7 SOC to have an effective IR team. You need named people with defined roles who have practised those roles before an incident occurs.

Minimum viable IR team roles:

Role	Responsibility	Typical owner (no SOC)
Incident Commander	Owns the response. Makes containment and escalation decisions. Single point of authority.	CTO, VP Engineering, or most senior technical leader
Technical Lead	Directs technical investigation. Coordinates forensics, containment, eradication.	Senior engineer or DevOps/SRE lead
Communications Lead	Manages internal and external communications. Coordinates with legal, PR, and regulators.	CEO, COO, or Head of Operations
Evidence Custodian	Maintains chain of custody for all forensic evidence. Logs every action taken on evidence.	Designated engineer with forensic training
Scribe	Documents every decision, action, and timestamp in the incident log. Real-time, append-only.	Any team member not in a decision-making role

Key principles for small teams:

Every role has a primary and an alternate. People take holidays, fall ill, and sometimes are the compromised account.
Roles, not people, make decisions. The Incident Commander decides to isolate a system — not "whoever is loudest on the call."
Escalation paths are pre-defined. At what severity does the CEO get woken up? At what point do you engage outside counsel? At what point do you call your IR retainer firm? Write these thresholds down.
Out-of-band communication is mandatory. If your corporate email or Slack is compromised, your incident-response coordination channel cannot live there.

Playbook templates#

A playbook is a specific, repeatable procedure for a specific incident type. Your IR plan is the strategy; playbooks are the tactics.

Every organisation should have playbooks for at minimum these scenarios:

Playbook: Ransomware#

Identify — confirm ransomware (encryption activity, ransom note, file-extension changes). Determine variant if possible.
Contain — isolate affected systems immediately. Disconnect from network. Do NOT power off (preserve memory for potential decryption-key recovery).
Scope — determine which systems are affected, which backups are intact, whether data was exfiltrated before encryption (double extortion).
Communicate — notify Incident Commander, legal counsel, insurance carrier (if cyber policy exists), law enforcement.
Eradicate — identify the entry vector. Remove attacker access. Patch the exploited vulnerability.
Recover — restore from clean backups. Rebuild systems that cannot be restored. Verify integrity.
Report — file regulatory notifications as required. Document for lessons learned.

Playbook: Credential compromise / account takeover#

Identify — confirm unauthorised access (unusual login locations, impossible travel, anomalous API calls).
Contain — disable the compromised account. Revoke all active sessions and tokens. Reset credentials.
Scope — audit what the compromised account accessed. Check for lateral movement, data access, privilege escalation.
Eradicate — determine how credentials were compromised (phishing, credential stuffing, malware, reuse). Address the root cause.
Recover — re-enable the account with new credentials and MFA. Monitor for re-compromise.

Playbook: Data exfiltration / data breach#

Identify — confirm data left the environment (unusual outbound traffic, large data transfers, external notification).
Contain — block the exfiltration channel. Isolate the affected system.
Scope — determine what data was taken, how much, whose data, and what classification. This drives your regulatory notification obligations.
Communicate — engage legal counsel immediately. Begin regulatory notification timeline assessment.
Eradicate — identify and close the exfiltration path. Remove attacker access.
Recover — restore affected systems. Implement additional data-loss prevention controls.

Playbook: Phishing / business email compromise#

Identify — confirm the phishing email or BEC attempt. Determine how many recipients were targeted and who clicked.
Contain — quarantine the email across all mailboxes. Block the sender domain and any malicious URLs/attachments. Reset credentials for anyone who interacted with the email.
Scope — determine whether any credentials were harvested, whether any malware was deployed, whether any financial transactions were initiated.
Eradicate — remove all instances of the email. Scan endpoints of users who interacted with it.
Recover — re-enable accounts. Monitor for follow-up attacks.

Playbook structure template you can adapt:

PLAYBOOK: [Incident Type]
Version: [x.x]
Last reviewed: [Date]
Owner: [Role]

TRIGGER CONDITIONS:
- [What activates this playbook]

SEVERITY CLASSIFICATION:
- Critical: [criteria]
- High: [criteria]
- Medium: [criteria]

PHASE 1 — IDENTIFICATION:
- [ ] [Step with specific action]
- [ ] [Step with specific action]

PHASE 2 — CONTAINMENT:
- [ ] [Step with specific action]
- [ ] [Step with specific action]

PHASE 3 — ERADICATION:
- [ ] [Step with specific action]

PHASE 4 — RECOVERY:
- [ ] [Step with specific action]

COMMUNICATION REQUIREMENTS:
- Internal: [who, when, how]
- External: [regulators, customers, public — with timelines]

EVIDENCE REQUIREMENTS:
- [ ] [What to capture and preserve]

Communication protocols#

Poor communication during an incident causes more organisational damage than the incident itself. Define your communication protocol before you need it.

Internal communication tiers:

Tier	Audience	Trigger	Channel
Tier 1	IR team	All confirmed incidents	Out-of-band (Signal, dedicated Slack workspace)
Tier 2	Executive leadership	High/Critical severity	Phone call from Incident Commander
Tier 3	Broader engineering team	When containment requires their systems	Direct message from Technical Lead
Tier 4	Full organisation	When the incident affects operations or will become externally visible	All-hands from Communications Lead

External communication principles:

Legal counsel reviews all external communications before release. No exceptions.
Do not speculate. Say what you know, say what you are doing, say when you will update next. Do not guess at scope, cause, or impact before the investigation confirms them.
Do not blame. Not the employee who clicked the link, not the vendor whose software was exploited, not the team that missed the patch. Blame is for the post-incident review, not the public statement.
Communicate early and often. Silence breeds speculation. Even "we are investigating and will update by [time]" is better than nothing.

Evidence preservation#

Evidence preservation is not optional. It is what separates a recoverable incident from a lawsuit you lose.

Evidence preservation checklist:

Do not modify the affected system until a forensic image is captured. No patching, no rebooting, no "let me just check something."
Capture volatile evidence first — RAM dump, running processes, network connections, logged-in users, clipboard contents. These disappear on reboot.
Take a full disk image — bit-for-bit forensic image, not a file-level backup. In cloud environments, take a full volume snapshot.
Capture relevant logs — system logs, application logs, authentication logs, network-flow data, firewall logs, DNS query logs, cloud-provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Log).
Photograph physical evidence if applicable — screen contents, hardware connections, physical access points.
Establish chain of custody — every piece of evidence gets a log entry recording: what it is, when it was collected, who collected it, where it is stored, who has accessed it since. This is not bureaucracy. It is what makes evidence admissible.
Store evidence securely — write-protected media, access-restricted storage, cryptographic hashes (SHA-256) recorded at collection time so integrity can be verified later.

The golden rule: If you cannot prove the evidence has not been tampered with, it has no value in legal or regulatory proceedings.

Regulatory notification timelines#

Different jurisdictions impose different notification deadlines. Your IR plan must include a jurisdiction-specific notification matrix.

Key timelines as of 2026:

Jurisdiction / Regulation	Notification deadline	To whom	Notes
EU GDPR (Art. 33/34)	72 hours from awareness	Supervisory authority + affected individuals (if high risk)	"Awareness" means when you have reasonable certainty a breach occurred, not when forensics is complete
India — CERT-In Directions (2022)	6 hours from awareness	CERT-In (Indian Computer Emergency Response Team)	Applies to cyber incidents affecting Indian entities. Six hours is one of the shortest mandatory timelines globally. Report via cert-in.org.in
India — DPDP Act 2023	"Without delay" / as prescribed by rules	Data Protection Board of India + affected Data Principals	Subordinate rules will define specific timelines. Expect alignment with CERT-In's urgency posture. Prepare for 72-hour or shorter windows
US — State breach notification laws	Varies by state (30-90 days typical)	State Attorney General + affected individuals	No single federal standard. California, New York, and Texas are the most consequential
US — SEC (public companies)	4 business days (material incidents)	SEC via Form 8-K	Applies to material cybersecurity incidents at public companies
Australia — NDB Scheme	30 days (assessment) + "as soon as practicable"	OAIC + affected individuals	Eligible data breaches involving personal information

Practical guidance:

Your legal counsel, not your engineering team, determines when "awareness" starts for regulatory-clock purposes. Engage counsel immediately.
CERT-In's 6-hour window is extraordinarily tight. If your organisation has any Indian nexus, your IR plan must include a pre-drafted CERT-In notification template that can be completed and submitted within hours, not days.
Multiple jurisdictions may apply simultaneously. A breach affecting EU and Indian customers triggers both GDPR and CERT-In/DPDP timelines concurrently.
Document your notification decisions. If you determine a breach is not notifiable, document why — the reasoning may be scrutinised later.

Retainer models: bridging the SOC gap#

If you do not have in-house forensic and IR capability (and most organisations without a SOC do not), a retainer with an IR services firm is the single most valuable preparation investment.

What a retainer provides:

Guaranteed response time — typically 2-4 hours for initial triage, with on-site or remote response within 24 hours.
Pre-negotiated rates — hourly rates for forensic analysts, incident commanders, and legal support agreed before the crisis, not negotiated under duress.
Pre-established access — the retainer firm already has your architecture documentation, your network diagrams, your cloud-environment details. They do not start from zero on day one.
Surge capacity — they provide the depth of expertise your team does not carry: memory forensics, malware reverse engineering, threat intelligence, legal-grade evidence handling.

Retainer structure options:

Hours-bank retainer — you pre-purchase a block of hours (typically 40-100 per year). Unused hours may or may not roll over. Used for ad-hoc incident support, threat-intelligence briefings, and tabletop facilitation.
Zero-cost retainer — no upfront fee, but guaranteed response at pre-negotiated rates. The firm prioritises retainer clients over walk-ins. You pay only when you use it.
Managed detection and response (MDR) + IR retainer — the MDR provider handles continuous monitoring and includes IR response as part of the contract. This is the closest thing to a SOC-without-a-SOC.

When to engage the retainer:

Any incident classified as High or Critical severity
Any incident involving confirmed data exfiltration
Any incident with regulatory notification implications
Any incident where the attacker's TTPs exceed your team's investigative capability
When in doubt — engage early. The cost of a false alarm is trivial compared to the cost of delayed response.

Tabletop exercises#

A plan that has never been tested is a plan that does not work. Tabletop exercises are the lowest-cost, highest-value method for testing your IR plan.

What a tabletop exercise is: A facilitated, scenario-based discussion where the IR team walks through a simulated incident from detection to resolution. No systems are touched. No code is deployed. The team sits around a table (or a video call) and talks through decisions, handoffs, and communications as the facilitator introduces escalating scenario details.

Running a tabletop exercise:

Select a scenario. Choose a realistic incident type relevant to your organisation. Ransomware affecting your primary database. A compromised admin credential on your cloud provider. A supply-chain attack through a third-party dependency. A phishing campaign targeting your finance team.
Prepare injects. An inject is a new piece of information introduced during the exercise that forces a decision. Examples:
- "The attacker has moved laterally to your backup server."
- "A journalist has emailed asking about a data breach at your company."
- "CERT-In has contacted you requesting incident details within their 6-hour window."
- "Your CEO is about to post on social media that 'everything is fine.'"
Assign roles. Every participant plays their actual IR role. The Incident Commander commands. The Technical Lead investigates. The Communications Lead communicates. If someone is absent, their alternate plays.
Facilitate, do not lecture. The facilitator introduces the scenario and injects, asks questions ("What do you do next?", "Who makes that call?", "Where is that documented?"), and records decisions and gaps. The facilitator does not provide answers.
Debrief immediately. What worked? What broke? Which procedures were unclear? Which contact information was wrong? Which decisions took too long?
Update the plan. Every gap identified in the tabletop becomes an action item with an owner and a deadline.

Suggested exercise cadence:

Minimum: twice per year
After any significant infrastructure change
After any actual incident (using the real incident as the scenario baseline, with variations)
After onboarding new IR team members

Sample tabletop scenario — ransomware without a SOC:

08:00 — Your monitoring alerts fire: CPU usage on three production servers has spiked to 100%. A developer investigating finds encrypted files and a ransom note demanding payment in cryptocurrency. Your most recent backup is 18 hours old. You have 47 employees, no SOC, and an IR retainer you signed six months ago but have never used. Your CERT-In notification clock started when the developer reported the finding. Go.

Putting it all together: your IR plan document structure#

Your IR plan should be a single, version-controlled document with the following structure:

1. PURPOSE AND SCOPE
   - What this plan covers
   - What constitutes an "incident" (definition)
   - Applicable regulations and frameworks

2. IR TEAM
   - Roster (primary + alternate for each role)
   - Contact details (out-of-band)
   - Escalation matrix (severity → who gets notified)

3. SEVERITY CLASSIFICATION
   - Critical / High / Medium / Low definitions
   - Examples for each level

4. PHASES
   - Preparation (standing activities)
   - Identification (detection + triage procedures)
   - Containment (short-term + long-term)
   - Eradication (root-cause removal)
   - Recovery (restoration + validation)
   - Lessons Learned (post-incident review process)

5. COMMUNICATION PROTOCOLS
   - Internal tiers
   - External communication templates
   - Media-handling procedures

6. EVIDENCE PRESERVATION
   - Collection procedures
   - Chain-of-custody requirements
   - Storage and integrity verification

7. REGULATORY NOTIFICATION
   - Jurisdiction matrix with timelines
   - Pre-drafted notification templates
   - Legal counsel engagement trigger

8. PLAYBOOKS (appendices)
   - Ransomware
   - Credential compromise
   - Data exfiltration
   - Phishing / BEC
   - [Additional scenario-specific playbooks]

9. RETAINER AND EXTERNAL RESOURCES
   - IR retainer firm details
   - Law enforcement contacts
   - Insurance carrier details
   - Regulatory body contacts

10. DOCUMENT CONTROL
    - Version history
    - Review schedule (minimum annual)
    - Distribution list

The 72-hour test#

Here is a practical test of your IR readiness. Ask yourself: if a breach were confirmed right now — at this moment — could your organisation do all of the following within 72 hours?

If the answer to any of those is "no" or "I'm not sure" — that is your preparation gap. Close it before the incident closes it for you.

Where to start if you have nothing today#

If you are reading this and your organisation has no IR plan, no playbooks, and no retainer — do not try to build everything at once. Start with these five actions, in order:

Name your IR team. Assign the five roles above to real people. Get their personal mobile numbers and personal email addresses. Put them in a document that exists outside your corporate infrastructure.
Write a one-page severity matrix. Define what Critical, High, Medium, and Low mean for your organisation. Include examples. Distribute it to the IR team.
Sign an IR retainer. Even a zero-cost retainer gives you a phone number to call on day zero. Do this before you need it.
Write one playbook. Pick your most likely incident type (for most organisations: ransomware or credential compromise) and write the playbook using the template above.
Run one tabletop. Use the ransomware scenario above or adapt it. Ninety minutes. The gaps it reveals will write the rest of your plan for you.

An imperfect plan that has been rehearsed will outperform a perfect plan that lives in a drawer. Start now.

Building an Incident Response Plan: Complete Guide for Organisations Without a SOC (2026)