Incident response plan

1. Purpose

This Incident Response Plan (IRP) describes how Purde Software detects, triages, contains, and recovers from security and privacy incidents affecting its products, services, or customer data, and how it communicates with customers and authorities.

2. Scope

The IRP covers any event or series of events that:

• compromises (or is reasonably suspected to compromise) the confidentiality, integrity, or availability of customer data, Purde Software data, or Purde Software systems;

• affects the operation of a Purde Software Cloud app or service;

• involves a confirmed personal-data breach within the meaning of Art. 4(12) GDPR.

It complements Cybersecurity Policy §11, Business Continuity Plan §9, and Privacy Policy §10.

3. Roles

External support may be engaged where the incident exceeds our internal capacity (forensic specialist, legal counsel, Atlassian support).

4. Severity classification

5. Phases

5.1 Detect

Sources include: Snyk and dependency alerts; Atlassian/Marketplace notifications; customer reports via the Service Desk or email; reports under the Vulnerability Disclosure Policy; the Owner's or second contributor's own observation; provider security advisories (AWS, Heroku, Atlassian Forge).

5.2 Triage

Within 2 business hours of detection during business hours (or by start of the next business day otherwise), the Incident Commander:

• confirms whether the event meets the IRP scope;

• assigns a preliminary severity (§4);

• opens an incident record (private Confluence page or Jira issue) with timestamps, observed facts, actions taken, and decisions;

• decides whether to activate the Business Continuity Plan in parallel.

5.3 Contain

Immediate actions, scaled to severity:

• isolate affected systems and accounts;

• rotate or revoke exposed credentials, tokens, and keys;

• disable affected app versions on the Marketplace where required;

• take a forensic snapshot of relevant logs before they reach their retention limit (Cybersecurity Policy §9).

5.4 Eradicate

Remove the root cause: deploy a fix, remove the vulnerable dependency, sanitize compromised systems, replace credentials. For app-level vulnerabilities, follow the SLA remediation timelines for the assigned CVSS severity.

5.5 Recover

Restore services from backups or by redeployment per Cybersecurity Policy §10 and Business Continuity Plan §4 (RTO/RPO). Validate that the issue is no longer reproducible. Resume normal operations.

5.6 Learn

Within 10 business days of stand-down, the Incident Commander records a post-incident note covering: timeline, root cause, response, what worked, what did not, corrective actions, and target dates. The note is reviewed at the next BCP/security review.

6. Notification

6.1 Customers

For confirmed personal-data breaches, customers acting as controllers are notified without undue delay and in any event within 72 hours of our becoming aware (Art. 33 GDPR; Privacy Policy §10). The notification includes, to the extent known: nature of the breach, categories and approximate number of data subjects and records, likely consequences, and measures taken or proposed.

6.2 Authorities

We do not notify supervisory authorities directly for personal-data breaches affecting customer data — that is the controlling customer's responsibility. We provide the customer with the information required for them to do so. Where Purde Software is itself the controller (for example, breach of our own service-desk records), we notify the BayLDA within 72 hours.

6.3 Atlassian

For incidents involving a Marketplace app, we notify Atlassian via the AMS project using the app vulnerability notification template.

6.4 Reporter (for externally reported incidents)

The reporter (researcher or customer) receives status updates per the Vulnerability Disclosure Policy §4 for reports falling under that policy.

7. Communication templates

Short templates for first customer notification, status update, and resolution note are maintained in our private Confluence space and reviewed at each annual exercise.

8. Exercises and review

• An IRP tabletop exercise is conducted at least once per year, covering at least one Critical and one High scenario. Results are recorded.

• This IRP is reviewed at least annually and after any incident in the Critical or High severity classes.

9. Related documents

• Cybersecurity Policy

• Business Continuity Plan

• Privacy Policy

• Service Level Agreement

• Vulnerability disclosure policy

• Acceptable Use Policy

10. Version history