Incident Response Plan

​

Purpose

This document establishes the plan for managing information-security incidents and events, and offers guidance for employees or incident responders who believe they have discovered, or are responding to, a security incident.

​

Scope

All information-security or data-privacy events or incidents.

​

Definitions

• Security event — an observable occurrence relevant to the confidentiality, availability, integrity, or privacy of company-controlled data, systems, or networks.
• Security incident — a security event that results in loss or damage to confidentiality, availability, integrity, or privacy.

​

Reporting

If a Neuroscale employee, contractor, user, or customer becomes aware of an information-security event or incident, possible incident, imminent incident, unauthorized access, policy violation, security weakness, or suspicious activity, they immediately report it via:

• Email security@neuroscale.ai
• Slack #security-incidents
• For active emergencies: page on-call via our Better Stack on-call schedule

Reporters should act as a good witness — include specific details about what was observed or discovered. See Report a security issue for the user-facing guide.

​

Severity

The Security team monitors incident reports and assigns severity:

​

P2 / P3 — Low and Medium

Suspicions or odd behaviors. Not verified; require further investigation. No clear indicator of tangible risk; no emergency response. Examples: lost/stolen laptop with disk encryption, suspicious emails, outages, strange activity on a laptop.

​

P1 — High

An adversary or active exploitation hasn’t been proven yet but is likely. Examples: lost/stolen laptop without encryption, vulnerabilities with direct exploitation risk, threats with risk of adversarial persistence (backdoors, malware), malicious access of business data (passwords, vulnerability data, payment information).

​

P0 — Critical

Actively exploited risks, or threats that put any individual at risk of physical harm. Identification of active exploitation is required to meet this severity.

​

Escalation

Escalation contacts are listed in Key contacts & on-call.

​

Documentation

All reported security events, incidents, and response activities are documented and adequately protected in our Linear “Security Incidents” project. A root-cause analysis (RCA) is performed on all verified P0 security incidents. The RCA is documented and referenced in the incident ticket and reviewed by the CISO who decide if a post-mortem meeting will be called.

​

Incident response process

For critical issues, the response team follows an iterative process to investigate, contain exploitation, eradicate the threat, recover services, remediate vulnerabilities, and document a post-mortem.

​

Summary

1. Event reported.
2. Triage and analysis.
3. Investigation.
4. Containment & neutralization (short-term / triage).
5. Recovery & vulnerability remediation.
6. Hardening & detection improvements (lessons learned, long-term response).

​

Detail

• The Incident Manager — typically the CISO or, when the incident is operational, the on-call IRT lead — manages the response effort.
• A central “war room” is designated — physical or virtual (Slack channel).
• A recurring Incident Response Meeting occurs at regular intervals until the incident is resolved.
• Legal and executive staff are informed as required.

​

Incident response meeting agenda

• Update incident ticket and timelines.
• Document new Indicators of Compromise (IOCs).
• Investigative Q&A.
• Apply emergency mitigations.
• External / breach reporting.
• Plan long-term mitigations.
• Document Root Cause Analysis (RCA).

​

Special considerations

​

Internal issues

Issues where the malicious actor is an internal employee, contractor, vendor, or partner require sensitive handling. The incident manager contacts the CEO directly and does not discuss with other employees.

​

Compromised communications

Incident responders must have a communication channel arranged before joining the incident. If there are IT communication risks, an out-of-band channel is chosen and communicated via cell phone.

​

Cloud root / master account compromise

If an AWS root account compromise is known or expected, refer to the AWS Root Account Compromise Playbook. If a Vultr master / root account compromise is known or expected, refer to the Vultr Root Account Compromise Playbook. Both playbooks treat root/master compromise as P0 by default.

​

Ransomware

A confirmed or suspected ransomware event is treated as P0 by default and triggers the following decision points in addition to the standard incident-response process:

1. Containment-first. Isolate affected hosts and accounts from the network; preserve forensic state where feasible (memory and disk images) before any reimage. The AWS Root and Vultr Root playbooks govern blast-radius containment for cloud accounts.
2. No payment without legal review. No ransom payment may be considered, communicated about, or made without (a) written CEO approval, (b) outside-counsel review, and (c) an OFAC sanctions check against the named threat actor and any payment instrument. Most ransomware payments to sanctioned entities are prohibited; the OFAC advisory on facilitating ransomware payments applies.
3. Reporting. File reports with FBI IC3 (https://www.ic3.gov) and, where applicable, CISA. Customer notification is governed by the breach-notification timing matrix and contractual commitments.
4. Recovery from clean backups. Recovery proceeds from validated clean backups per the Operations Security Policy → Information backup and the Business Continuity & Disaster Recovery Policy; never restore from suspect backups, and rotate all credentials that may have been exposed.
5. Communications. External communications are coordinated by the CEO and General Counsel only; internal communications are limited to a need-to-know channel.
6. Post-incident. A privileged legal analysis and a separate operational post-mortem are produced per the Privilege and work-product protection section above.

​

Additional requirements

• Suspected and reported events and incidents are documented.
• Suspected incidents are assessed and classified as either an event or an incident.
• Incident response is performed per this plan and any associated procedures.
• All incidents are formally documented; a documented RCA is performed.
• Incident responders collect, store, and preserve evidence per industry guidance and best practices such as NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response.
• Suspected and confirmed unauthorized-access events are reviewed by the IRT. Breach determinations are made only by the CEO and legal counsel in coordination with executive management.
• Neuroscale promptly notifies customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches per Neuroscale policies, contractual commitments, and regulatory requirements, as determined by the CEO and Legal.
• This Incident Response Plan is reviewed and formally tested at least annually. Tests are conducted as facilitated tabletop exercises with the IRT and at least one participant from Legal and one from executive management; the test scenario varies year over year and includes at least one ransomware or data-exfiltration scenario across the rolling three-year cycle. Results, findings, lessons learned, and the dated tabletop after-action report are filed in the SharePoint evidence library used for SOC 2 / ISO 27001 audits.

​

External communications and breach reporting

Legal and executive staff confer with technical teams in the event of unauthorized access to company or customer systems, networks, or data. Legal and the CEO determine if breach reporting or external communications are required. Breaches are reported to customers, consumers, data subjects, and regulators without undue delay and per all contractual commitments and applicable legislation. No personnel may disclose information regarding incidents or potential breaches to any third party or unauthorized person without the approval of Legal or executive management.

​

Privilege and work-product protection

For any incident with potential legal, regulatory, or contractual exposure, the General Counsel (or outside counsel engaged for that purpose) directs the post-containment investigation, and incident-response work product is generated at the direction of, and to enable legal advice from, counsel. The intent is to qualify the investigation report and counsel-directed forensic analyses for attorney-client privilege and work-product protection under U.S. federal common law and analogous state and foreign doctrines. Operational facts (system logs, runbook output, infrastructure telemetry) generated in the ordinary course of business are not privileged on that basis alone. To preserve privilege:

• The General Counsel issues a written engagement memo at the start of any P0 / P1 incident with potential legal exposure, scoping outside-counsel engagement and identifying the privileged investigative workstream. Forensic vendors (incident-response firms, e-discovery providers) are engaged through outside counsel under a Kovel-style engagement letter where appropriate.
• Privileged communications — including counsel-directed RCAs, draft notification analyses, legal-risk assessments, and forensic reports prepared for counsel — are labeled “Privileged & Confidential — Attorney-Client Communication / Attorney Work Product” and stored in the restricted SharePoint legal site. Distribution is on a strict need-to-know basis.
• Operational vs. privileged streams are kept separate. Two report tracks may be produced for the same incident: an operational post-mortem (non-privileged, used for engineering improvement and customer communication) and a privileged legal analysis. The operational track must not contain counsel’s legal conclusions or strategy.
• Slack and chat channels used for the privileged stream are dedicated, access-restricted, and labeled accordingly. Operational war-room channels are separate.
• Lessons from federal and state precedent on incident-investigation privilege — including In re Capital One Consumer Data Security Breach Litig., 2020 WL 2731238 (E.D. Va. May 26, 2020); Wengui v. Clark Hill, PLC, 2021 WL 106417 (D.D.C. Jan. 12, 2021); and the broader privilege-and-work-product line of cases — inform this approach: investigations performed in the ordinary course of business rather than for the purpose of obtaining legal advice are not privileged, and operational reports widely distributed within the company are typically discoverable. Neuroscale’s framework is designed to keep the privileged stream focused on legal advice and limited in distribution.

This framework does not impede any person’s right to make protected disclosures to government authorities; see the Whistleblower Policy.

​

Breach notification timing matrix

Notification timelines vary by regime. The matrix below is indicative; the authoritative deadlines for any given incident are determined by Legal in consultation with outside counsel and the customer contracts in scope. Where a contractual deadline is shorter than the regulatory deadline, the contractual deadline governs. When in doubt, the shortest applicable clock starts at the moment of discovery / awareness / confirmation as defined by that regime, not at internal escalation.

​

Mitigation and remediation

Legal and executive staff determine any immediate or long-term mitigations or remedial actions to take as a result of an incident or breach. Executive staff direct personnel on planning, communicating, and executing those activities.

​

Cooperation with customers, data controllers, and authorities

As needed and determined by Legal and executive staff, Neuroscale cooperates with customers, data controllers, and regulators to fulfill all of its obligations in the event of an incident or breach.

​

Roles & responsibilities

The CEO makes the final breach determination if consensus cannot be reached.

​

Management commitment

Neuroscale management has approved this policy and commits to providing the resources, tools, and training needed to reasonably respond to identified security events and incidents.

​

Exceptions

Requests for exceptions must be submitted to the CISO for approval. Exceptions are documented.

​

Violations & enforcement

Report violations to the CISO or, where escalation is required, the CEO. Violations may result in suspension of system and network privileges and disciplinary action up to and including termination.

​

Appendices

• Appendix A — Contact information. See Key contacts & on-call.
• Appendix B — Incident collection form. Reports are submitted via the Security Incident intake form, which files into the Security Incidents project in Linear. Post-incident root-cause analysis is captured via the RCA intake form.
• Appendix C — AWS root account compromise playbook. See the AWS Root Account Compromise Playbook.
• Appendix D — Vultr root account compromise playbook. See the Vultr Root Account Compromise Playbook.

​

Version history