Incident Management & Breach Disclosure Policy

Owner: Daniel Sanchez (Director of Engineering) Version: 1.0 Effective date: January 1, 2026 Review cadence: Annual

1. Purpose & Scope

This policy defines how Nodus identifies, responds to, and discloses information security incidents and personal-data breaches. It applies to all employees, contractors, and systems that process Nodus or customer data, including our AWS production environment.

2. Definitions

• Security event — an observable occurrence in a system or network.
• Security incident — an event that compromises, or threatens to compromise, the confidentiality, integrity, or availability of systems or data.
• Personal-data breach — a security incident leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to, personal data.
• Discovery — the point at which Nodus confirms, with reasonable certainty, that an incident has occurred and is reportable.

3. Severity Classification

Level	Definition	Examples
SEV-1 (Critical)	Confirmed breach of customer/personal data or full service compromise	Exfiltration of customer PII; production database compromise
SEV-2 (High)	Significant impact, contained, no confirmed data loss	Compromised internal credential; isolated host intrusion
SEV-3 (Medium)	Limited impact, no sensitive data exposure	Malware on a single endpoint, contained
SEV-4 (Low)	Minimal/no impact	Failed intrusion attempt, blocked by controls

4. Roles & Responsibilities

• Incident Commander (IC) — owns coordination and decision-making for the incident.
• Security Team — detection, triage, containment, forensics.
• Engineering / On-call — remediation and recovery.
• Legal / DPO — regulatory and contractual notification obligations.
• Communications — internal and customer/external messaging.
• Executive Sponsor — Daniel Sanchez (Director of Engineering) for SEV-1 escalation.

5. Incident Response Lifecycle

1. Detection & Reporting — Alerts from monitoring (e.g., GuardDuty, WAF, CloudTrail), customer reports, or staff. All suspected incidents are reported to the dedicated internal Slack channel immediately and logged in the incident register.
2. Triage & Classification — Security Team assigns severity within 1 hour of report and assigns an IC for SEV-1/SEV-2.
3. Containment — Isolate affected systems, revoke credentials, block malicious traffic; preserve evidence (snapshots, logs) for forensics.
4. Eradication — Remove the root cause (malware, vulnerability, unauthorized access).
5. Recovery — Restore services from known-good state; monitor for recurrence before declaring resolution.
6. Post-Incident Review — A blameless retrospective within 5 business days of closure, documenting root cause, timeline, and corrective actions tracked to completion.

6. Breach Disclosure & Notification

6.1 Internal escalation

SEV-1 incidents are escalated to Legal/DPO and the Executive Sponsor immediately upon discovery.

6.2 Regulatory notification

Where a personal-data breach is likely to result in a risk to individuals, Nodus will notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of discovery, consistent with GDPR Art. 33 and applicable state/sector breach-notification laws. Legal/DPO determines the controlling jurisdiction(s) and requirements.

6.3 Customer notification

Nodus will notify affected customers directly and without undue delay once a breach affecting their data is confirmed, targeting notification within 72 hours of discovery unless a law-enforcement or regulatory hold requires delay. Notification will be made via email to the account's registered contact and will include, to the extent known:

• the nature of the breach and categories of data involved;
• the likely consequences;
• measures taken or proposed to address it;
• recommended steps for the customer; and
• a contact point for further information.

If full details are not yet available, Nodus will issue an initial notice and provide updates as the investigation progresses, rather than delaying the initial notification.

6.4 Contractual obligations

Where a customer contract or DPA specifies a shorter notification window, the contractual timeline governs for that customer.

7. Documentation & Record-Keeping

All incidents, regardless of severity, are recorded in the incident register with timeline, actions taken, and notification decisions.

7.1 The incident register

The incident register is the authoritative system of record for every reported incident. Each entry captures, at minimum:

• a unique incident identifier and the assigned severity level;
• the date and time of detection, discovery, containment, and resolution;
• the reporting source (monitoring alert, customer report, or staff) and the assigned IC;
• the systems, data categories, and customers affected;
• a chronological timeline of actions taken, including containment, eradication, and recovery steps;
• all notification decisions (regulatory, customer, contractual) with the rationale and timestamps; and
• a link to the post-incident review and any corrective-action tracking items.

7.2 Evidence preservation & chain of custody

Forensic artifacts — snapshots, logs, memory captures, and exported alerts — are stored in a restricted, access-controlled location separate from production. Access is logged, and a documented chain of custody is maintained for any evidence that may be used in legal or regulatory proceedings. Evidence is preserved in a manner that protects its integrity (e.g., write-once storage or hashing where feasible).

7.3 Retention & confidentiality

Incident records and supporting evidence are stored indefinitely unless legal counsel directs otherwise, and are retained at least as long as required by applicable law, contracts, and regulatory obligations. Records may contain sensitive security and personal data; access is restricted to authorized personnel on a need-to-know basis. Where personal data appears in records, it is minimized and handled consistently with Nodus's Privacy Policy.

8. Testing & Training

This plan is tested at least twice a year (biannually) via tabletop exercise. All staff receive incident-reporting training at onboarding and annually.

8.1 Tabletop exercises

Each biannual exercise simulates a realistic scenario (e.g., a SEV-1 data exfiltration or a compromised production credential) and exercises detection, escalation, the decision to notify, and cross-functional coordination among Security, Engineering, Legal/DPO, and Communications. Exercises are scheduled by the Security Team, and at least one per year includes the Executive Sponsor. Findings — gaps, unclear ownership, slow steps — are documented and tracked to closure as corrective actions, and material gaps trigger a policy review under Section 9.

8.2 Training & awareness

• Onboarding — All new employees and contractors complete incident-reporting training before being granted production or data access, covering how to recognize and report a suspected incident and the dedicated internal Slack channel.
• Annual refresher — All staff complete a refresher annually; completion is tracked, and outstanding completions are escalated to managers.
• Role-specific training — Members of the Security Team, on-call engineers, and ICs receive additional training on containment, forensics, evidence handling, and the notification decision process.

8.3 Measuring readiness

The Security Team tracks readiness indicators across exercises and real incidents — time to triage, time to containment, and timeliness of required notifications — and reviews trends with the Executive Sponsor to drive improvements to controls, tooling, and this plan.

9. Policy Review

Reviewed at least annually and after any SEV-1 incident or material change to systems or regulations.

9.1 Review triggers

A review is initiated by any of the following:

• the annual review cadence;
• closure of any SEV-1 incident;
• a material change to systems, architecture, or the production environment;
• a change in applicable laws, regulations, or contractual obligations (e.g., new breach-notification requirements); or
• corrective actions or findings from a tabletop exercise that indicate a gap in this policy.

9.2 Review process & ownership

The policy Owner is accountable for the review, conducted with Legal/DPO and the Security Team. Each review confirms that roles, severity definitions, notification timelines, and contact points remain accurate, and that the policy reflects the current regulatory landscape and system footprint.

9.3 Approval & versioning

Material changes are approved by the Owner and, where required, by Legal/DPO before taking effect. Each approved revision increments the version number and updates the effective date in the document header. A change history is maintained, and staff are notified of material changes, which may trigger updated training under Section 8.