Personal information sits in almost every South Australian ICT estate: citizen and customer records, staff files, case notes, telemetry and vendor portals. When that information is lost, accessed without authority or disclosed in the wrong place, the Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme can turn a technical incident into a regulatory one. This guide is for ICT leaders in SA agencies, councils, not-for-profits, SMEs and the suppliers who serve them. It explains who is covered, what APP 11 expects in practical terms, how the NDB assessment and notification clocks work, and how those clocks sit beside CPS 230, CPS 234, SOCI and ransomware reporting. It is general guidance, not legal advice. Confirm your position with the OAIC, current legislation and your advisers.
Who is covered
The Australian Privacy Principles (APPs) and the NDB scheme apply to APP entities: Australian Government agencies and organisations that must protect personal information under APP 11. In the private and not-for-profit sectors that usually means organisations with annual turnover above $3 million. A small business at or below that threshold is generally exempt, but common exceptions still bring many smaller operators into coverage, including health service providers that hold health information, businesses that trade in personal information, credit reporting bodies, certain Commonwealth contractors, and others listed in OAIC guidance. Check the current OAIC small business guidance before assuming you are out of scope.
South Australian state agencies and councils are generally covered by South Australian privacy arrangements rather than the APPs. Many still face equivalent expectations through contracts, board policy and community trust, and their suppliers are often APP entities in their own right. If you process personal information for a regulated customer, expect APP 11-style security, breach notice and audit terms even when the statute that binds you is different. Do not invent coverage: map which regime applies to you and which applies to each customer.
Security of personal information (APP 11) in ICT terms
APP 11 requires an APP entity to take reasonable steps to protect personal information it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure. When the information is no longer needed for any purpose permitted under the APPs, the entity must take reasonable steps to destroy it or de-identify it. “Reasonable steps” scale with the sensitivity of the data, the harm that could follow a breach, and the entity's size and resources, but ICT leaders should treat the following as baseline:
- Know what you hold. An inventory of systems, data stores and vendors that hold personal information, with classification and residency.
- Limit access. Least privilege, MFA, joiner-mover-leaver processes and regular access reviews.
- Protect in transit and at rest. Encryption, key management and segregation of customer or citizen data.
- Hardening and patching. Secure configuration and timely remediation aligned with the ACSC Essential Eight.
- Logging and detection. Audit trails that show who accessed what, and monitoring that can start an investigation quickly.
- Lifecycle control. Retention rules, tested deletion or de-identification, and careful handling of backups and archives.
- Vendor control. Contracts and assurance for every party that stores or processes personal information on your behalf. See Australian data residency and provider due diligence.
APP 11 is principles-based. Certifications such as ISO/IEC 27001 help demonstrate a management system, but they do not replace an entity's own assessment of whether its steps are reasonable for the information it holds.
The Notifiable Data Breaches scheme
Part IIIC of the Privacy Act requires APP entities to notify the OAIC and affected individuals of an eligible data breach. In summary, an eligible data breach is unauthorised access to, unauthorised disclosure of, or loss of, personal information that is likely to result in serious harm to one or more individuals, where remedial action has not prevented that likely risk. Serious harm is assessed objectively and can include psychological, emotional, physical, reputational or other harm. Effective containment and remediation can mean notification is not required; document that judgement carefully.
Assessment clock
If you suspect an eligible data breach, you must carry out a reasonable and expeditious assessment of whether the circumstances amount to one. The Privacy Act requires you to take all reasonable steps to complete that assessment within 30 calendar days after the day you became aware of the grounds for suspicion. The OAIC treats 30 days as a maximum, not a target: complete the assessment sooner wherever possible, because the risk of serious harm often rises with time. If you cannot reasonably finish within 30 days, document why, what steps you took, and why the assessment remained reasonable and expeditious. Current OAIC guidance on assessing a suspected data breach is the reference to follow.
Notify as soon as practicable
Once there are reasonable grounds to believe an eligible data breach has occurred, notify the OAIC and the individuals at risk as soon as practicable. Notification content should help people understand what happened and what they can do. Coordinate with legal, communications and, where relevant, customers or regulators who share the same facts. A rehearsed playbook matters more than a perfect template on the day.
How NDB clocks sit beside other regimes
The same ransomware event or misconfigured bucket can trigger several obligations at once. The clocks differ, so design one incident record that starts each applicable timer from awareness. Our compliance standards map and incident notification architecture set out the relationships in detail. In short:
| Obligation | Typical clock |
|---|---|
| NDB assessment of a suspected eligible breach | All reasonable steps within 30 calendar days; sooner wherever possible |
| NDB notification once an eligible breach is confirmed | As soon as practicable to the OAIC and individuals |
| CPS 230 / CPS 234 material incident (APRA-regulated entities) | Often within 72 hours of awareness; tolerance breaches under CPS 230 can be 24 hours |
| SOCI critical cyber security incident | Report to ASD's ACSC within 12 hours (with written follow-up rules) |
| Ransomware or extortion payment (in-scope entities) | Report within 72 hours |
APRA-regulated entities (including insurers, superannuation trustees and authorised deposit-taking institutions) may need to notify APRA under CPS 230 or CPS 234 while also running an NDB assessment. SOCI reporting and ransomware payment reporting can apply in parallel. Do not wait for the NDB assessment to finish before meeting a shorter regulator clock. See also CPS 234 for suppliers, backup and disaster recovery and Zero Trust Conditional Access.
A practical ICT checklist
- Inventory and classify. List systems, SaaS products and vendors that hold personal information. Tag sensitivity, residency and owners.
- Access and identity. Enforce MFA, least privilege and timely offboarding. Review privileged access on a schedule.
- Logging that supports investigation. Retain audit logs long enough to reconstruct access during an assessment window, and protect logs from tampering.
- Breach playbook. Name roles, decision criteria for “serious harm”, OAIC and individual notification steps, counsel contacts and out-of-hours paths. Rehearse with a tabletop that includes a supplier breach.
- Containment and remediation. Practise isolation, credential rotation, restore from immutable backups and evidence preservation. Remedial action can change whether a breach is eligible; record what you did and when.
- Vendor contracts. Require prompt notice, cooperation on assessments, audit access and clear data return or deletion at exit.
- Evidence pack. Keep policies, diagrams, test results and prior exercise records where responders can reach them if the primary environment is down.
These steps also strengthen Essential Eight maturity and the security evidence APRA-regulated customers ask for under CPS 234.
How EITSAA helps
EITSAA is a technology consultancy based in Adelaide. We are not a law firm, privacy assessor or accredited certification body, and we do not determine whether a breach is eligible or notify the OAIC on your behalf. What we do is help you design and evidence the technical side: personal information inventories, access and logging controls, breach detection and playbooks that line up with other regulator clocks, and the architecture patterns in our Learn library. Legal decisions stay with your counsel and accountable executives.
This article reflects published Privacy Act settings and OAIC guidance patterns as at October 2026. Thresholds, forms and guidance change. Confirm current requirements on the OAIC website and with your advisers before relying on them.
Talk to an Adelaide team
If you want a privacy-ready ICT baseline, a rehearsed breach playbook or clearer vendor terms for personal information, talk to us about a managed IT and cyber security review or call 0402 401 584. See also our managed IT and cyber security service and the incident detection and regulator reporting architecture.