You can move from no incident plan to SaaS incident response playbook readiness in 30 days by documenting accountable roles, defining a repeatable incident workflow, configuring communications and evidence locations, testing one realistic scenario, and retaining proof that the process works. For ISO 27001 control 5.24, the goal is not a large policy binder: it is a communicated process showing how your company prepares for, manages, escalates, records, and improves information security incident handling.
What is the current-state assessment before you build an incident plan?
Start by treating the enterprise security questionnaire as a gap-assessment tool. If a customer asks whether you have an incident response plan, a 24-hour notification process, named incident owners, and annual testing, do not answer from memory. Create a short evidence inventory that separates what exists from what is merely understood by the founders or engineering team.
ISO/IEC 27001:2022 control 5.24, Information Security Incident Management Planning and Preparation, requires the organization to plan and prepare for managing information security incidents by defining, establishing, and communicating incident management processes, roles, and responsibilities. Your initial assessment should determine whether each of those verbs has evidence behind it.
| Assessment area | Question to answer | Acceptable starting evidence | Common gap |
|---|---|---|---|
| Ownership | Who declares an incident and who leads response? | Named primary and backup incident commander in an internal directory | “The CTO handles it” with no backup or authority defined |
| Detection | Where do security signals arrive? | PagerDuty, Sentry, AWS GuardDuty, Microsoft 365 alerts, or ticketing queues | Alerts go to an individual inbox or an unmonitored Slack channel |
| Response workflow | What happens from report through closure? | Severity matrix, ticket template, and incident timeline procedure | No agreed criteria for escalating a customer report |
| Communications | Who approves customer, regulator, and public statements? | Contact list and pre-approved notification decision path | Sales promises notification timelines that engineering cannot support |
| Testing and learning | Has the team exercised the process? | Dated tabletop record and improvement actions | A policy exists but no one knows how to use it |
Interview the founder, engineering lead, customer support lead, and whoever administers cloud identity and production infrastructure. Ask for artifacts, not assurances: a recent security alert, a Jira ticket, an AWS CloudTrail event, a customer support escalation, and the current on-call schedule. This gives you the actual response path that the playbook must formalize.
For example, Northbridge Managed Services, a 42-person provider supporting 180 client tenants, found that security events could enter through HaloPSA tickets, Microsoft Defender alerts, Huntress notifications, or a client phone call. Its technical director was informally expected to coordinate every serious event. The assessment showed that the company had capable responders but no declaration authority, no unified incident record, and no reliable way to show an enterprise prospect that client notification decisions were controlled.
How do you move from no incident plan to SaaS incident response playbook target state?
Design the target state around the decisions your team must make under pressure. A practical 30-day playbook should be short enough to use during an outage or suspected breach, but specific enough to produce consistent records. Keep the policy-level statement separate from operational runbooks: the policy states commitments and accountability; the runbook tells responders exactly where to work and what to record.
Which roles and responsibilities should be defined?
- Incident Commander: declares the incident, sets severity, coordinates decisions, and authorizes closure.
- Technical Lead: investigates, contains, eradicates, and restores affected systems.
- Communications Lead: manages internal updates, customer communications, and approved status messaging.
- Executive Sponsor: approves material business decisions, legal engagement, and contractual notification decisions.
- Recorder: maintains the timeline, evidence references, decisions, and action items.
For a small SaaS company, one person can hold more than one role, but every critical role needs a named backup. Define authority explicitly. The Incident Commander may declare a Sev-1 without waiting for the CEO; the executive sponsor may approve customer notice after legal review; only the communications lead may send broad external updates.
What should the operating workflow include?
- Receive and log the report or alert.
- Triage scope, credibility, affected assets, and potential data exposure.
- Assign a severity and declare an incident when criteria are met.
- Contain the threat while preserving useful evidence.
- Investigate, eradicate, and restore services safely.
- Notify required internal and external parties according to contracts and legal advice.
- Close only after recording root cause, residual risk, and corrective actions.
Use a severity model that your team can apply in minutes. For example, Sev-1 can mean confirmed unauthorized access to production customer data, active ransomware, or an outage affecting all customers; Sev-2 can mean suspected compromise with limited evidence or a material outage affecting one service; Sev-3 can mean a contained event with no confirmed customer impact. Do not promise a fixed legal notification period in the playbook unless counsel has confirmed the applicable obligations and customer contract terms.
What is the 30-day phased migration plan?
| Phase and timing | Work performed | Milestone evidence |
|---|---|---|
| Phase 1: Days 1–3 — Baseline | Complete gap assessment; inventory alert sources, data stores, customer commitments, and responder contacts. | Signed gap log and current-state workflow diagram |
| Phase 2: Days 4–8 — Governance | Assign primary and backup roles; approve severity definitions; establish declaration and escalation authority. | RACI matrix, contact roster, and executive approval record |
| Phase 3: Days 9–15 — Build | Create incident policy, operational runbook, ticket template, communications templates, and evidence repository. | Version-controlled documents and accessible responder links |
| Phase 4: Days 16–21 — Integrate | Route alerts to on-call staff; configure incident channels; connect Jira, PagerDuty, Slack, and cloud logging procedures. | Test alerts, sample incident ticket, and access validation |
| Phase 5: Days 22–26 — Exercise | Run a tabletop for a realistic account compromise or exposed API key scenario. | Attendance record, timeline, decisions, and corrective-action register |
| Phase 6: Days 27–30 — Approve and communicate | Correct gaps, obtain management approval, train staff, and package questionnaire evidence. | Approved playbook, training acknowledgement, and evidence index |
In Phase 3, build the working record in the tools your team already uses. A lean SaaS team may use Jira Service Management for the incident ticket, PagerDuty for on-call escalation, Slack for a restricted incident channel, Google Drive or Confluence for controlled documentation, and AWS CloudTrail plus GuardDuty for investigation evidence. Restrict incident channels and folders because early reports may contain customer data, credentials, or legal advice.
Use a standardized ticket format so every incident produces the same minimum record:
Incident ID: INC-2026-014 Severity: Sev-2 Incident Commander: Priya Shah Declared: 2026-07-16 14:22 UTC Affected service/data: API token service; no confirmed customer data access Detection source: AWS GuardDuty finding + PagerDuty alert Containment action: Disabled IAM access key; revoked active sessions Customer notification decision: Not required; no confirmed exposure Evidence locations: CloudTrail query export; Jira attachments; Slack channel archive Corrective actions: Enforce short-lived credentials; add GuardDuty escalation rule
How should the cutover runbook and rollback work?
Cutover means moving from informal handling to the approved playbook as the source of truth. Schedule it during a normal business week, not during a major release, and announce the exact effective time to employees, contractors, and outsourced support partners. From that time forward, all suspected security incidents must use the new intake route and incident record.
- Publish the approved policy and runbook in the controlled knowledge base.
- Verify that Incident Commander and backup contacts can receive PagerDuty alerts.
- Create the restricted Slack channel naming convention, such as
#inc-sev1-2026-014. - Confirm access to AWS logs, identity-provider audit logs, Jira incident projects, and the evidence folder.
- Send a company-wide instruction explaining how to report suspected incidents and prohibiting unapproved external statements.
- Run a live alert-routing test and record the outcome in the first incident-test ticket.
The rollback plan should be narrow: do not revert to undocumented incident handling. If PagerDuty routing fails, use the approved backup phone tree and open the incident in Jira manually. If the new documentation repository is unavailable, use the pre-approved encrypted emergency copy with read access for named responders. Log the failure, use the fallback, and restore the primary workflow as a corrective action.
At Northbridge Managed Services, the cutover test exposed that its after-hours PagerDuty escalation reached the service desk but not the technical director’s backup. The team used its existing HaloPSA urgent-ticket call tree for the test, corrected the PagerDuty escalation policy, and retained both the failed test result and the successful retest. That is stronger questionnaire evidence than claiming a process is operational without having tested it.
How do you validate the playbook after migration?
Post-migration validation proves that the new process is established and communicated, which is central to ISO 27001 control 5.24. Validate both usability and evidence: can responders execute the steps, and can you show an assessor or enterprise buyer the resulting records?
- Run a tabletop involving a plausible SaaS scenario, such as a compromised administrator account with access to production support tools.
- Measure acknowledgement time, time to declare, time to assign roles, and time to produce an executive update.
- Review whether severity was applied consistently and whether evidence remained accessible and protected.
- Confirm that customer notification decisions followed contract, privacy, and legal escalation paths.
- Assign owners and due dates for every exercise finding, then verify closure.
- Review the playbook at least annually and after significant incidents, architectural changes, or new customer obligations.
Your enterprise questionnaire response can now be precise: state that you maintain a documented incident management process aligned to ISO 27001 control 5.24, identify the owner, describe testing frequency, and offer controlled evidence such as the policy revision history, redacted tabletop report, training record, and corrective-action log.
Next step: schedule a 60-minute working session with your engineering and customer-facing leads this week to complete the Day 1–3 assessment and identify the person who can approve your incident roles.
