CTF: Customer Data Is Leaking — How Long Before You're Legally Liable?

Difficulty: Intermediate | Time: 20–30 min | Linked product: IRP Template ($47)​‌‌​‌​​‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​​‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌​​​​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌​‌‌‌‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌‌​​‌​‍​‌‌​​‌​‌‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​​‌‌​

---

The Setup

Your e-commerce platform sells specialty outdoor gear to about 12,000 customers across Australia and New Zealand. On a Wednesday afternoon, one of your developers is doing routine log review and notices something odd: your PostgreSQL database is receiving SELECT queries from an internal service account that hasn't been active in four months. The queries are pulling full customer records — name, email, phone, hashed password, and shipping address — in batches of 500.

The service account (svc_legacy_import) belongs to an old data migration tool that was deprecated last year. Nobody should be using it. You check your access logs: the queries have been running every six hours for the past 11 days.​‌‌​‌​​‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​​‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌​​​​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌​‌‌‌‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌‌​​‌​‍​‌‌​​‌​‌‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​​‌‌​

Quick maths: 4 pulls per day × 11 days × 500 records per pull = approximately 22,000 customer records exfiltrated. Your database has 12,000 active customers. The extra 10,000 are historical — some going back to 2019.

The source IP is a VPS hosted on a provider in Frankfurt. No geo-restriction was in place.

The Privacy Act clock may already be running. What do you do?

---

The Challenge

---

Question 1 — When did the "breach" legally begin?

Under Australia's Notifiable Data Breach (NDB) scheme (Privacy Act 1988, Part IIIC), the 30-day assessment clock starts when your organisation becomes aware of "reasonable grounds to believe" an eligible data breach has occurred — not when it's confirmed.

• At what point today does the clock start: when your developer noticed the anomaly, when you confirmed the service account was compromised, or only when you've determined which customers are affected?
• What constitutes "reasonable grounds" vs "reasonable grounds to suspect"?
• What are the consequences of missing the 30-day assessment deadline?

---

Question 2 — Does this trigger mandatory

notification?

Not every data breach is a Notifiable Data Breach. The NDB scheme requires notification only if the breach "is likely to result in serious harm" to affected individuals.

• Do hashed passwords constitute personal information under the Act?
• Is shipping address + email + phone sufficient to constitute "serious harm" risk?
• The historical records from 2019 include customers who have since closed their accounts. Are you still obligated to notify them?
• Your NZ customers: does Australia's Privacy Act cover them, or does the NZ Privacy Act 2020 apply?

---

Question 3 — The investigation: What do you preserve?

Before you disable the service account and patch the access vector, your legal counsel says: "Don't touch anything until we've documented the evidence trail."

List the five artefacts you must preserve before any remediation action, in order of volatility (most volatile first). For each, describe how you'd preserve it without destroying the evidence.

---

Question 4 — Notification content

You've determined this is an eligible NDB and you must notify both the Office of the Australian Information Commissioner (OAIC) and affected individuals.

Draft the key elements of the individual notification. What must legally be included? What's the most common mistake businesses make in the notification that turns a manageable breach into a regulatory enforcement action?

---

Question 5 — Root cause: The service account problem

The service account svc_legacy_import had database READ access that was never revoked when the migration tool was decommissioned. The password was found in a plaintext config file on a deprecated internal wiki.

Name the three security controls that, if they had been in place, would have prevented this breach entirely. For each, describe what "good" looks like for an SMB without a dedicated security team.

---

Hints

Hint 1 (Q1): The OAIC has published guidance specifically on when the 30-day clock starts. "Reasonable grounds to suspect" a breach triggers the assessment obligation — the confirmation comes during the assessment. Many businesses miss the deadline because they think the clock starts at confirmation. It doesn't.

Hint 2 (Q2): The OAIC's NDB guidance lists factors for assessing "serious harm": sensitivity of the information, who has accessed it, what they could do with it. A name + email + phone + shipping address in the hands of an unknown threat actor is considered medium-to-high risk. The hashed password question turns on the strength of the hashing algorithm (bcrypt? MD5?). Historical records of closed accounts are still covered — the Privacy Act obligation doesn't expire when the customer relationship ends.

Hint 3 (Q3): Volatility order matters in forensics: network connections and process memory disappear first; disk logs next; then application logs; then database query logs; then the service account audit trail in your IAM system. Preservation means making a hash-verified copy, not just a screenshot.

Hint 4 (Q4): The most common mistake: vague notification language that says "some data may have been accessed" when you actually know it was. The OAIC has taken enforcement action specifically for this. Be specific about what data, when, and what you're doing about it. Plain English, no legalese.

Hint 5 (Q5): Think about service account lifecycle management, least-privilege access, and secrets management. "Good enough" for an SMB doesn't require enterprise tooling — it requires a documented process and a quarterly review.

---

Reveal: Full Answer to Question 3

Five artefacts to preserve, in order of volatility:

1. Live database connection state (most volatile) Before killing any connections, capture the current active sessions in your database: SELECT * FROM pg_stat_activity; (PostgreSQL). Export to a timestamped CSV. This shows you exactly what the compromised account was doing at the moment of discovery. This disappears the instant you restart the service or revoke the credential.

2. Network connection table on the database host Run netstat -antp or ss -antp and export the output with a timestamp. This captures the live connection from the Frankfurt IP. Once the connection drops or the session is killed, this evidence is gone from memory. Capture it now.

3. Application and database query logs Export the full PostgreSQL query log covering the 11-day window. Don't rotate or truncate. Copy the raw log files to an isolated evidence store with SHA-256 hashes documented. In PostgreSQL, logs typically live in /var/log/postgresql/. Ensure your log_statement setting was capturing SELECT queries (many SMB deployments have this off by default — if so, document that gap).

4. Service account authentication logs Pull the authentication log for svc_legacy_import from your identity provider or, if using database-native auth, from pg_log. Document every login timestamp, source IP, and query executed. This becomes your evidence of the breach timeline for the OAIC notification.

5. The deprecated wiki/config file (least volatile, but critical) Locate the plaintext config file where the service account password was stored. Preserve it as-is (don't edit or delete it). Hash it. This is your root cause evidence. It's less volatile than memory artefacts but equally important — it explains how the credential was obtained and supports your root cause analysis.

After preservation: Take all five artefacts offline to an isolated, hash-verified evidence store. Only then proceed with remediation (revoke the credential, block the source IP, patch the access vector).

---

Get the Full Answer Key

You've seen one answer in detail. The remaining questions — covering the exact NDB assessment timeline, notification drafting, and the three controls that would have stopped this breach — are documented in the Incident Response Plan Template for SMBs.

The template includes:

• NDB scheme decision flowchart (is this an eligible breach? who do I notify? in what order?)
• OAIC notification template with legally-required elements pre-filled
• Evidence preservation checklist with hash verification steps
• Service account audit checklist for post-incident hardening
• 30/72-hour response timeline with decision gates

Built for Australian SMBs who don't have a legal team on speed dial.

Get the IRP Template for $47 → lil.business/products/incident-response-plan-template

Or buy via Polar: https://buy.polar.sh/polar_cl_G95ZMX6xnZpa7JuXj1AROgffKr1aL0JDmJ2KU1rHJ84

---

Scenario based on composite real-world NDB reports published by the OAIC. Company details are fictionalised.