Incident Response Policy template (SOC 2)

1. Purpose

This policy establishes how Northwind Cloud Inc prepares for, detects, responds to and recovers from security incidents affecting Northwind, its infrastructure and the information entrusted to Northwind Cloud Inc by customers, personnel and partners, so as to limit harm, restore normal operations quickly, meet notification obligations, preserve evidence, and turn every incident into a documented improvement.

2. Scope

This policy applies to all Northwind Cloud Inc personnel, including contractors and interns, and to every system and data set Northwind Cloud Inc owns or operates: production in AWS and Vercel, code and pipelines in GitHub and GitHub Actions, corporate SaaS, endpoints, and vendor services holding Northwind Cloud Inc data. It applies wherever personnel work, including home offices and travel.

A security event is any observable occurrence relevant to security. A security incident is an event that has, or is reasonably likely to have, compromised the confidentiality, integrity or availability of Northwind Cloud Inc systems or data. A data breach is an incident resulting in unauthorised access to, disclosure, alteration or loss of personal or customer data. Every incident is assigned one of these severity levels.

3. Roles and Responsibilities

• Executive Management approves this policy, is notified of SEV1 and SEV2 incidents, decides on customer and regulatory notification, engages outside counsel and insurers, and attends incident exercises.
• Security Owner (Dana Whitfield, CTO) owns this policy and the runbook, monitors security@northwindcloud.example, triages reports, appoints the Incident Commander, maintains the incident log, leads post-incident reviews and reports metrics.
• Incident Commander directs a given SEV1 or SEV2 response as the single decision-maker, setting priorities, assigning tasks, deciding containment actions and controlling the update cadence. The Security Owner fills the role unless someone else is appointed.
• Engineering staffs the on-call rotation, executes containment, eradication and recovery in AWS and Vercel, GitHub and related systems, preserves evidence, and implements corrective actions.
• People Operations supports incidents involving personnel, such as insider misuse or lost devices, runs any disciplinary process, and ensures incident-reporting training at onboarding and annually.
• All Personnel report suspected incidents to security@northwindcloud.example, cooperate with responders, preserve rather than delete potential evidence, and do not discuss incidents outside the response team.

4. Policy Statements

• 4.1 Anyone who observes or suspects a security incident must report it to security@northwindcloud.example within one hour of discovery. Good-faith reports are never penalised, even where the reporter caused the incident.
• 4.2 Every report is triaged and assigned a Section 2 severity within the acknowledgement target for that level; severity may be raised by any responder and lowered only by the Incident Commander with a written rationale.
• 4.3 Every SEV1 and SEV2 incident has a named Incident Commander with authority to take systems offline, revoke credentials, block traffic and engage vendors without prior approval; Executive Management is informed of containment decisions, not consulted first.
• 4.4 Every incident has a record in the incident log with a unique identifier, timestamped timeline, decisions, participants, affected systems and data, evidence and closure criteria, retained for seven years under the Data Retention and Disposal Policy.
• 4.5 Evidence, including logs in Datadog, cloud audit trails, snapshots and access records, is preserved before any remediation that could destroy it; evidence that may be needed in a dispute is kept in a restricted location with a chain-of-custody note.
• 4.6 Containment prioritises protecting customer data and people over restoring availability. Compromised credentials are rotated and sessions revoked in Okta as a first action; compromised hosts are isolated, not rebuilt, until evidence is captured.
• 4.7 Only Executive Management, or their designate for the incident, communicates about it with customers, the press, regulators, law enforcement or the public; personnel must not confirm, deny or speculate about incidents with third parties.
• 4.8 Affected customers are notified without undue delay, within any contractual timeframe, and in every case within 72 hours of Northwind Cloud Inc confirming their data was affected, stating what happened, what Northwind Cloud Inc has done and what the customer should do.
• 4.9 Legal, regulatory and contractual notification obligations are assessed for every SEV1 and SEV2 incident, with outside counsel where the analysis is unclear. Where personal data is involved, supervisory authorities are notified within 72 hours where the GDPR or UK GDPR applies, affected individuals and state attorneys general where US state breach-notification laws require it, and customers acting as data controllers in time to meet their own deadlines.
• 4.10 Incidents at vendors, including Supabase, Stripe, Datadog and Slack, that affect Northwind Cloud Inc data or Northwind are handled under this policy, and vendor contracts must require notification to Northwind Cloud Inc within 72 hours under the Vendor and Third-Party Risk Management Policy.
• 4.11 Every SEV1 and SEV2 incident receives a blameless post-incident review within five business days of closure that produces a root cause, impact statement and corrective actions with owners and due dates, tracked to closure and reported to Executive Management.
• 4.12 The plan is exercised at least annually with Executive Management, Engineering and the Security Owner, and all personnel complete incident-reporting training at onboarding and annually; exercise findings are entered in the risk register.
• 4.13 Where an incident threatens the availability of Northwind, the Incident Commander may invoke the Business Continuity and Disaster Recovery Policy; the incident and recovery records reference each other so that one timeline exists.

5. Procedures

• 5.1 Detection and reporting. Incidents arrive from Datadog alerts, AWS and Vercel security notifications, secret-scanning and dependency alerts from GitHub, vendor notices, customer reports and personnel reports to security@northwindcloud.example. The on-call responder acknowledges each within the target for the suspected severity.
• 5.2 Triage. Within the acknowledgement target, the Security Owner or on-call responder confirms whether the event is an incident, assigns a severity (choosing the higher when facts are uncertain), opens a record with an identifier in the form INC-YYYY-NNN and, for SEV1 and SEV2, appoints the Incident Commander.
• 5.3 Mobilisation. The Incident Commander opens a channel named after the incident identifier, designates a scribe and, for SEV1 and SEV2, a communications lead, and sets the update cadence.
• 5.4 Containment. Responders first disable accounts and revoke sessions in Okta, rotate exposed keys and secrets, block malicious addresses, isolate affected hosts or containers in AWS and Vercel and remotely lock or wipe endpoints through Kandji. Longer-term containment, such as rebuilding hosts, is planned once spread is stopped, and each action and its time are recorded.
• 5.5 Evidence collection. Before eradication, responders snapshot affected volumes, export logs and cloud audit trails covering at least 30 days before the first indicator, capture attacker activity and preserve related messages and tickets in a restricted, access-logged location; large artefacts are hashed.
• 5.6 Eradication and recovery. Engineering removes the root cause, rebuilds compromised systems from known-good images or infrastructure code in GitHub, restores data where needed from backups in AWS Backup under the Backup and Recovery Policy, verifies integrity and returns systems to service through an expedited change approval, with heightened monitoring for 14 days.
• 5.7 Notification. Within 24 hours of confirming that customer or personal data was affected, the Security Owner prepares a notification assessment listing who must be told and by when; Executive Management approves it and the messages, counsel reviews regulatory notices, and copies of every notice are attached to the incident record.
• 5.8 Post-incident review. Within five business days of closing a SEV1 or SEV2 incident, the Incident Commander convenes a blameless review covering the timeline, root cause, response timings, impact, what went well and badly, and corrective actions with owners and due dates; the Security Owner approves it and presents SEV1 reviews to Executive Management.
• 5.9 Metrics. Each quarter the Security Owner reports to Executive Management the number of incidents by severity, mean time to acknowledge, contain and resolve, notifications made, overdue corrective actions and trends.
• 5.10 Exercise and plan maintenance. Each year the Security Owner runs a scenario exercise (a leaked token for GitHub, ransomware on a laptop, or a compromised administrator account in AWS and Vercel) and documents decisions and gaps, and each quarter reviews the runbook and contact roster covering security@northwindcloud.example, on-call rotations, Executive Management, counsel, the insurer and support at AWS and Vercel, plus vendor contacts at Supabase, Stripe, Datadog and Slack.

6. Exceptions

Exceptions require the written approval of the Security Owner, a compensating control and an expiry date no more than 12 months away, and are reviewed at each annual policy review. No exception is available to the reporting obligation in 4.1, the communication restriction in 4.7, or any notification required by law or contract.

7. Enforcement

Failing to report a suspected incident, concealing one, destroying evidence, making unauthorised external statements or obstructing responders is a violation of this policy and may result in disciplinary action up to and including termination of employment or contract; unlawful conduct may be referred to law enforcement. Vendors that miss notification obligations face the remedies in their contract.

8. Review Cadence

The Security Owner reviews this policy on a annual basis and after every SEV1 incident, any exercise revealing a material gap, significant changes to Northwind Cloud Inc's infrastructure or reporting channels, and changes in breach-notification law; each review is approved by Priya Natarajan, CEO and recorded in Section 9.

9. Revision History