How Stackle responds when incidents threaten personal data

1. Purpose and Scope

This policy describes how Stackle Pty Ltd will prevent, detect, respond to, and learn from data breaches in adherence with the Privacy Act 1988 (Cth), the Australian Notifiable Data Breaches Scheme, the UK and EU GDPR, ISO 27001:2022, and SOC 2 Trust Services Criteria.

It sets out the steps Stackle will take to contain, assess, notify, and review any breach, and explains how Stackle will meet its obligations under the NDB Scheme, GDPR, and relevant contractual commitments.

The policy applies to all Stackle employees, contractors, and third parties with access to Stackle data or systems; all personal information, confidential data, and intellectual property held by Stackle in any format; and all systems and services operated by or on behalf of Stackle, including AWS-hosted infrastructure in ap-southeast-2, third-party platforms, and remotely accessed systems.

2. Definitions and Data Breach Sources

3. Roles, Responsibilities, and Reporting

Stackle does not maintain a standing breach response team. Instead, it assembles a virtual, cross-functional team per incident in line with the Incident Response Plan.

Any employee, contractor, or third party who becomes aware of, is informed of, or suspects a breach must report it immediately by emailing admin@stacklehq.com or contacting the Head of Technology or Senior Management directly when the situation is severe or time-critical.

Reports should include as much detail as possible, including the date, time, affected systems or data, and what was observed. Staff must not attempt to investigate or remediate independently.

4. Severity and Response Plan

Confirmed breaches are assigned a severity level during triage and are then handled through a defined contain, assess, preserve, notify, recover, and review sequence.

5. Regulatory and Legal Notification Obligations

Under the Australian NDB Scheme, Stackle must assess suspected eligible breaches expeditiously with a target of completion within 72 hours of becoming aware of the suspected breach.

If an eligible breach is confirmed, the policy requires notification to the OAIC within 72 hours of forming a reasonable belief that the eligible breach has occurred, plus notification to affected individuals as soon as practicable where serious harm is likely.

Where a breach affects users of a specific organisation, Stackle uses the organisation's admin contact as the primary notification channel, with website publication as a fallback where direct notification is not practicable.

For UK and EU users, Legal must assess whether the breach is likely to result in a risk to rights and freedoms and, where reportable, notify the ICO or relevant EU supervisory authority within 72 hours of awareness. A reportable personal data breach to UK or EU regulators is automatically classified as an S1 incident.

The policy also acknowledges contractual breach-notification obligations and states that Legal must review all current and future material contracts so those obligations are documented in the Incident Response Plan.

6. Breach Register, Monitoring, and Related Plans

Stackle maintains a Breach Register as a centralised, auditable record of all data breach events. The source policy states that it is maintained as a controlled Google Sheet in Stackle's secure Google Workspace environment with access restricted to the Head of Technology, Legal, and Senior Management.

The register must be updated for every confirmed breach, retained for a minimum of 7 years, and made available to auditors and regulators on request. The active Incident Manager receives access only for the duration of an incident.

The policy also sets out a detection and monitoring layer spanning AWS, application monitoring, Discord alerting, and email escalation. Any alert that indicates potential unauthorised access to personal data must be treated as a suspected breach and reported immediately.

This policy operates alongside the Incident Response Policy, Incident Response Plan, Business Continuity Plan, GDPR Policy, Data Classification and Handling Policy, and Supplier Management Policy. In the event of conflict, it is subordinate to the Incident Response Policy.

7. Review, Acknowledgement, and Compliance

The data-breach response procedures must be tested at least annually through a tabletop exercise or equivalent simulation, coordinated with the annual Incident Response Plan test. Outcomes must be documented and reviewed by the Head of Technology.

The policy must also be reviewed at least annually and after significant incidents, material changes to systems or personnel, relevant changes in law, or significant updates to the Incident Response Policy or Plan. The Head of Technology and Head of Product jointly initiate reviews, and updates go to the Executive Board for approval.

Compliance with the policy is a condition of employment and engagement. New employees and contractors must acknowledge it before receiving system or data access, annual re-acknowledgement is required, and material out-of-cycle updates require re-acknowledgement within 30 days. Records must be retained for at least 3 years.

The policy reserves Stackle's right to monitor employees' use of company data and to investigate where conduct appears to breach policy. Employees or third parties who cause or contribute to a breach may face disciplinary or contractual consequences, up to and including termination or revocation of access.