AU Notifiable Data Breach Plan
Effective Date: 10 February 2026 Last Updated: 10 February 2026
This document sets out DiscoverWorthy's procedures for identifying, assessing, and responding to data breaches under Australia's Notifiable Data Breaches (NDB) scheme, as established by Part IIIC of the Privacy Act 1988 (Cth).
1. Purpose
This plan ensures that DiscoverWorthy can:
- Quickly detect and contain data breaches
- Assess whether a breach is likely to result in serious harm
- Notify the Office of the Australian Information Commissioner (OAIC) and affected individuals as required
- Document and learn from incidents to prevent future breaches
2. What Is an Eligible Data Breach?
Under the NDB scheme, an eligible data breach occurs when:
- There is unauthorized access to, unauthorized disclosure of, or loss of personal information held by DiscoverWorthy, AND
- The breach is likely to result in serious harm to any of the individuals whose information is involved
2.1. Our Data at Risk
In the event of a breach, the following personal information could be compromised:
| Category | Data | Risk Level |
|---|---|---|
| Account credentials | Email addresses, session tokens | High — enables account takeover |
| Billing data | Card last 4/brand/expiry, billing history, Stripe IDs | Medium — limited card data, but financial |
| Google OAuth tokens | Access and refresh tokens | Critical — enables access to user's Google accounts |
| Customer story data | Names, emails, companies, full conversation transcripts, photos | High — personal and business data |
| Referral data | Names, emails, titles, companies, LinkedIn URLs, recommendations | High — professional information |
| Team member data | Names, roles, emails, phone numbers, photos | Medium — professional information |
| Freelancer/client data | Stripe Connect IDs, client emails, pricing, invoice data | High — financial and business data |
| Analytics data | Hashed visitor IDs, IP-derived location, page views | Low — pseudonymized |
| Content data | Blog posts, brand voice, products/services, competitor info | Medium — business intelligence |
3. Breach Detection
3.1. How Breaches May Be Detected
- Automated monitoring: Azure security alerts, unusual login patterns, rate limiting triggers
- User reports: Users or customers reporting suspicious activity
- Internal discovery: Team members identifying unauthorized access or data exposure
- Third-party notification: Azure, Stripe, Google, or other processors notifying us of a breach in their systems
- External reports: Security researchers, media reports, or regulatory notifications
3.2. Reporting Internally
Any person who suspects a breach must immediately report it to:
- Primary contact: [Security Contact Name] — security@discoverworthy.com
- Escalation: the Data Protection Officer — legal@discoverworthy.com
4. Assessment Process
4.1. Timeline
Upon becoming aware of a suspected breach, we must complete our assessment within 30 calendar days.
4.2. Assessment Steps
Step 1: Contain
- Isolate affected systems
- Revoke compromised credentials or tokens
- Block unauthorized access
- Preserve evidence for investigation
Step 2: Assess
Evaluate the following factors:
| Factor | Assessment |
|---|---|
| What data was involved? | Identify specific data types and records |
| How many individuals are affected? | Determine scope |
| Nature and sensitivity of data | Is it credentials, financial, health, or other sensitive data? |
| Security protections in place | Was data encrypted? Were access controls effective? |
| Who gained access? | Known threat actor, unknown, accidental internal exposure? |
| Has data been recovered? | Can we confirm containment? |
| Likelihood of serious harm | Considering all factors, is serious harm likely? |
Step 3: Determine Notifiability
A breach is notifiable if a reasonable person would conclude that the breach is likely to result in serious harm to any affected individual.
Factors indicating serious harm:
- Financial data that could enable fraud
- Authentication credentials that could enable account access
- Google OAuth tokens that could provide access to external accounts
- Combined data that could enable identity theft
- Sensitive personal information (conversation transcripts with personal details)
Step 4: Decide
| Assessment Outcome | Action |
|---|---|
| Breach is likely to cause serious harm | Notify OAIC + affected individuals |
| Remedial action prevents serious harm | No notification required (document remediation) |
| Not an eligible breach | Document assessment; no notification |
5. Notification to the OAIC
5.1. When to Notify
Notify the OAIC as soon as practicable after completing the assessment (and no later than 30 days after becoming aware of the breach).
5.2. How to Notify
Submit via the OAIC's Notifiable Data Breach form.
5.3. What to Include
The notification must contain:
| Required Information | Details |
|---|---|
| Organization identity | DiscoverWorthy, 140 Keller Road, ESSENDON NORTH, VIC 3041, dpo@discoverworthy.com |
| Description of the breach | What happened, when, how it was discovered |
| Kind of information involved | Specific data types (e.g., email addresses, billing data, OAuth tokens) |
| Recommendations for individuals | Actions they should take (e.g., change passwords, monitor accounts, revoke Google access) |
6. Notification to Affected Individuals
6.1. When to Notify
Notify affected individuals as soon as practicable after the assessment determines the breach is eligible.
6.2. Method of Notification
| Method | When Used |
|---|---|
| Direct email | Preferred method — sent to the individual's email address on file |
| Published statement | If direct notification is not practicable (e.g., we don't have contact details, or the scale is too large for individual emails) |
6.3. What to Include
| Required Information | Details |
|---|---|
| Organization identity | DiscoverWorthy, contact details |
| Description of the breach | Plain-language explanation of what happened |
| Kind of THEIR information involved | Specific to the individual |
| Recommendations | Steps they should take |
6.4. Recommended Actions by Data Type
| Data Compromised | Recommended Action |
|---|---|
| Email + session tokens | Log out all sessions, verify no unauthorized changes |
| Billing data (card last4/expiry) | Monitor bank statements, consider card replacement |
| Google OAuth tokens | Revoke DiscoverWorthy access in Google Account settings, review Google activity |
| Customer story transcripts | Monitor for misuse of personal information |
| Referral data (name, LinkedIn) | Monitor for impersonation or phishing |
| Phone numbers | Watch for suspicious SMS/calls |
7. Exceptions
7.1. Remedial Action Exception
A breach is not notifiable if we take remedial action before serious harm occurs, such that a reasonable person would conclude serious harm is no longer likely. Examples:
- Immediately revoking compromised session tokens
- Forcing password resets (email re-verification)
- Revoking and rotating Google OAuth tokens
- Confirming data was encrypted and encryption keys were not compromised
Document all remedial actions taken.
7.2. Law Enforcement Exception
If a law enforcement agency requests that we delay notification because it would prejudice an investigation, we may delay notification for a reasonable period.
8. Third-Party Breach Coordination
If a breach originates at a third-party processor:
| Processor | Our Response |
|---|---|
| Azure / Microsoft | Review Microsoft security advisory, assess impact on our data, coordinate response |
| Stripe | Check if our customer payment data was affected, notify affected clients |
| Assess if OAuth tokens or user Google data was compromised | |
| Twilio | Check if phone numbers or SMS data was exposed |
| Brave Search | Assess if keyword or search data was compromised (low risk) |
We maintain data processing agreements with all processors that require them to notify us of breaches promptly.
9. Record Keeping
We maintain records of all suspected and confirmed breaches, including:
| Record | Details |
|---|---|
| Date breach identified | When we became aware |
| Date assessment completed | Within 30-day window |
| Assessment outcome | Notifiable / not notifiable / remediated |
| Data types involved | Specific categories |
| Individuals affected | Number and categories |
| Remedial actions taken | Steps to contain and prevent |
| Notifications sent | OAIC and individual notifications |
| Lessons learned | Changes made to prevent recurrence |
These records are retained for a minimum of 5 years and are available for inspection by the OAIC.
10. Prevention Measures
10.1. Technical Controls
- Encryption at rest: Azure SQL Transparent Data Encryption (TDE)
- Encryption in transit: HTTPS/TLS for all data transmission
- Session management: httpOnly, Secure cookies with 30-day expiry
- Rate limiting: On authentication endpoints, API routes, and analytics
- Input validation: Parameterized SQL queries to prevent injection
- Access controls: Role-based access, principle of least privilege
- Monitoring: Azure security monitoring and alerting
10.2. Organizational Controls
- Regular security reviews and updates
- Incident response procedures (this document)
- Prompt patching of security vulnerabilities
- Review of third-party processor security practices
11. Review
This plan is reviewed and updated:
- At least annually
- After any data breach or near-miss
- When there are significant changes to our data processing activities or systems
12. Contact
For data breach reports or questions:
- Security Email: security@discoverworthy.com
- DPO Email: dpo@discoverworthy.com
- Address: 140 Keller Road, ESSENDON NORTH, VIC 3041
OAIC:
- Website: oaic.gov.au
- Phone: 1300 363 992
- Breach reporting: oaic.gov.au/privacy/notifiable-data-breaches