Data Protection in Australia: Laws and Business Requirements

Data protection laws Australia-wide require businesses to know what personal information they collect, why they need it, where it goes, who can access it, and when it should be deleted.

Australian data protection laws combine federal privacy rules with state, territory, industry, and contractual duties. Compliance requires clear controls, accountable owners, and reliable evidence.

This article explains the main requirements and practical steps for managing data privacy Australia-wide. It provides general information and does not constitute legal advice.

What Does Data Protection Mean in Australia?

It covers the complete information lifecycle. Businesses must control how personal information is collected, stored, accessed, used, disclosed, retained, and destroyed.

A complete program should also define how the business detects, contains, assesses, records, and reports suspected data breaches.

Cybersecurity supports data protection by defending systems against malware, unauthorised access, data theft, and operational disruption.

Data protection has a wider scope. It asks whether information was necessary, whether its use is permitted, who may receive it, and whether the business has retained it for too long.

A business can have strong cybersecurity but weak privacy controls. Encrypted data can still create risk if it was collected without a clear purpose or retained indefinitely.

Effective data protection combines privacy governance with practical controls, including:

• Data minimisation at collection
• Clear purposes and collection notices
• Role-based access permissions
• Approval and disclosure controls
• Retention and deletion rules
• Vendor and overseas-recipient oversight
• Incident assessment and breach response
• Documented reviews and audit evidence

Which Australian Data Protection Laws Apply to Businesses?

Privacy laws Australia-wide are not contained in one statute. The applicable framework depends on the business, its activities, the people it serves, and the information it handles.

Requirements may come from federal legislation, state or territory rules, sector-specific laws, employment duties, commercial contracts, and overseas privacy regimes.

A business should map every applicable requirement before designing controls. Using only the federal turnover test can overlook duties created by its services, contracts, or data categories.

1. Privacy Act 1988

The Privacy Act 1988 is Australia’s main federal law governing personal information.

It regulates how covered private-sector entities and Australian Government agencies collect, hold, use, disclose, protect, access, and correct personal information.

Covered businesses are commonly called APP entities because they must comply with the Australian Privacy Principles.

The Act also contains rules covering credit reporting, tax file numbers, direct marketing, overseas disclosure, health information, and eligible data breaches.

Compliance requires more than publishing a privacy policy. A business must maintain practices, procedures, and vital enterprise systems that support compliance in daily operations.

Actual workflows should match public statements. If a policy promises limited access or scheduled deletion, system permissions and retention processes must support that promise.

Businesses should use the current authorised version of the Act. The Federal Register of Legislation records amendments and commencement dates.

2. Australian Privacy Principles

The Australian Privacy Principles, or APPs, are 13 principles contained in the Privacy Act.

They establish standards, rights, and duties across the personal information lifecycle. Their scope includes:

• Open and transparent privacy management
• Anonymity and pseudonymity where practicable
• Collection of solicited personal information
• Handling unsolicited personal information
• Notification of collection
• Use and disclosure
• Direct marketing
• Cross-border disclosure
• Government-related identifiers
• Data quality and security
• Access and correction

The APPs are principles-based. They do not prescribe one control set, so each APP entity must apply them according to its systems, risks, and information practices.

Reasonable security for basic contact details may differ from the safeguards required for identity documents, health records, financial data, or biometric information.

Businesses using cloud platforms should also understand how cloud ERP security supports access control, data protection, backups, and operational continuity.

From 10 December 2026, APP entities will face added privacy-policy transparency duties for certain substantially automated decisions.

The duties apply when personal information supports decisions that could significantly affect a person’s rights or interests.

Businesses using automated pricing, eligibility, recruitment, allocation, or approval should document the data inputs, decision types, accountable owners, and review controls.

The OAIC explains the incoming APP 1 requirements and their scope.

3. Notifiable Data Breaches Scheme

The Notifiable Data Breaches scheme applies to entities covered by the Privacy Act.

An eligible data breach can arise when personal information is lost, accessed without authorisation, or disclosed without authorisation.

Notification is generally required when the incident is likely to cause serious harm and effective remedial action has not removed that likelihood.

Serious harm may include identity theft, financial loss, physical harm, significant psychological harm, or serious reputational damage.

Not every security incident is an eligible data breach. However, every suspected eligible breach should enter a documented assessment process promptly.

Covered entities must take reasonable steps to complete an assessment within 30 calendar days. The OAIC treats this period as a maximum, not a standard response time.

If an eligible breach is confirmed, the business generally must notify affected individuals and the OAIC as soon as practicable.

The OAIC eligibility criteria explain serious harm, remedial action, and notification duties.

A defensible response records the affected data, possible harm, remedial action, decision-maker, outcome, and reasons for notifying or not notifying.

4. State, Territory, and Industry-Specific Requirements

Federal privacy law is only one part of the Australian framework. Separate regimes may apply to state and territory public-sector bodies and their service providers.

Additional requirements may affect health services, credit reporting bodies, telecommunications providers, financial firms, schools, employers, and government contractors.

Other laws may govern workplace surveillance, health information, identity documents, electronic marketing, tax records, consumer data, or professional confidentiality.

Contracts may impose duties beyond the statutory minimum. These can include Australian data storage, short incident deadlines, encryption standards, audit rights, and deletion certificates.

A business operating nationally should not assume one policy satisfies every jurisdiction. It should map each legal and contractual duty to the relevant information and activity.

5. Australian Privacy Law vs GDPR

The Privacy Act and the European Union’s General Data Protection Regulation both regulate personal information, but their requirements are not interchangeable.

They differ in coverage, processing grounds, consent, individual rights, breach notification, international transfers, governance duties, penalties, and enforcement.

The GDPR may apply to an Australian business that offers goods or services to people in the European Union or monitors their behaviour there.

The European Commission explains the GDPR’s territorial scope for businesses outside the European Union.

A business subject to both regimes can use one data inventory, but it should assess every processing activity against each legal framework separately.

Privacy Act compliance does not prove GDPR compliance. A GDPR program may also fail to address Australian exemptions, identifier restrictions, or breach tests.

Does the Privacy Act Apply to Your Business?

The Australian Bureau of Statistics recorded 2,729,648 actively trading businesses at 30 June 2025.

This market includes businesses with very different data risks. Coverage must be tested against actual operations rather than business size alone.

1. The Annual Turnover Test

Most private-sector businesses with annual turnover above $3 million are covered by the Privacy Act.

For this test, turnover generally includes income from all sources. It does not simply mean profit, taxable income, assets held, or proceeds from capital sales.

A business close to the threshold should review its calculation when revenue, ownership, corporate structure, or activities change.

Related companies may require closer assessment. A small entity can be affected by its relationship with a covered entity, even when its own turnover falls below the threshold.

The business should record its coverage decision, supporting facts, responsible reviewer, and next review date.

2. Businesses Covered Regardless of Turnover

Some businesses with annual turnover of $3 million or less must comply because of what they do or the information they handle.

Coverage can include certain:

• Private health service providers
• Businesses that trade in personal information
• Commonwealth contracted service providers
• Credit reporting bodies
• Residential tenancy database operators
• Businesses related to covered entities
• Entities that voluntarily opt into coverage

The precise tests and exceptions matter. A business should assess the substance of its activities rather than relying on its industry label or registered description.

A service may qualify as a health service because of the activity performed, even when healthcare is not the business’s primary industry.

3. Small Business Exemptions

Many businesses with turnover of $3 million or less are exempt from the Privacy Act, but the exemption is not universal.

The OAIC small business information outlines activities that can remove the exemption.

An exemption from the Privacy Act does not remove every duty involving personal information.

A small business may still face contractual confidentiality, consumer law, employment, surveillance, health, tax, professional, or state-based requirements.

Customers and commercial partners may also require controls aligned with the APPs, regardless of statutory coverage.

Weak information handling can cause fraud, service disruption, disputes, complaints, and reputational damage even when no Privacy Act breach occurs.

A business relying on an exemption should document its legal basis and reassess coverage whenever its turnover, services, contracts, ownership, or data practices change.

4. Privacy Act Applicability Checklist

A practical coverage assessment should ask whether the business:

• Has annual turnover above $3 million
• Provides a health service
• Trades in personal information
• Handles credit reporting information
• Performs work under a Commonwealth contract
• Operates a residential tenancy database
• Is related to a covered entity
• Has opted into Privacy Act coverage
• Has contracts requiring APP compliance
• Operates in countries with other privacy laws

The assessment should identify which legal entity performs each activity. A corporate group may contain both covered and exempt entities using shared systems or data.

Where the result remains uncertain, the business should obtain legal advice before treating itself as exempt.

What Information Must Australian Businesses Protect?

Data protection begins with identifying records that relate to an identified person or someone who is reasonably identifiable.

The assessment should consider context and combined data. A record may become personal information when linked with another dataset, even if it contains no name.

Businesses should inventory structured records and unstructured content, including documents, messages, images, recordings, logs, backups, analytics, and exported files.

1. Personal Information

Personal information is information or an opinion about an identified individual or an individual who is reasonably identifiable.

It can be true or false, recorded or unrecorded, and may include objective facts, opinions, inferences, or assessments.

Common examples include:

• Names and contact details
• Dates of birth
• Customer and account numbers
• Payment and transaction histories
• Photographs and voice recordings
• Locations and travel records
• Complaint and support histories
• Online and device identifiers

A name is not always required. A combination of role, location, transaction details, device data, or behaviour may make a person reasonably identifiable.

2. Sensitive Information

Sensitive information is a protected category of personal information that can create greater harm if misused or disclosed.

It may include information about:

• Health and medical history
• Race or ethnic origin
• Political opinions or associations
• Religious or philosophical beliefs
• Sexual orientation or practices
• Trade union or professional membership
• Criminal records
• Biometric templates
• Genetic information

APP entities generally need consent to collect sensitive information unless an exception applies.

The collection must also be reasonably necessary for the entity’s functions or activities.

Consent should be informed, voluntary, current, and specific enough for the proposed handling. A broad privacy policy does not automatically establish valid consent.

Tighter access, disclosure, monitoring, and retention controls may be needed where misuse could expose a person to discrimination, fraud, stigma, or physical harm.

3. Government-Related Identifiers

Government-related identifiers include numbers, letters, symbols, or combinations assigned by government bodies to identify individuals.

Examples include tax file numbers, Medicare numbers, passport numbers, and driver licence numbers.

APP 9 restricts when an APP entity may adopt, use, or disclose these identifiers.

A business should not use a government identifier as its own customer, supplier, or employee number unless a legal exception permits it.

Identifier records should have a documented purpose, restricted access, secure transmission method, retention rule, and disposal process.

Some identifiers have separate legal requirements. Tax file numbers, for example, are subject to dedicated rules in addition to the APPs.

4. Employee, Customer, and Supplier Records

Customer and supplier records often contain contact details, bank information, transaction histories, correspondence, contracts, and identity documents.

Access should reflect business duties. Sales staff may need customer contacts, while finance staff may require billing data, but neither role automatically needs every record.

Private-sector employers have a limited exemption for certain employee records when the handling directly relates to a current or former employment relationship.

The exemption does not cover every employment-related record or activity.

It may not apply to unsuccessful applicants, independent contractors, or service providers processing employee information for another business.

Employment records may also be affected by workplace, surveillance, tax, health, discrimination, and confidentiality requirements.

5. Digital Records, Metadata, and System Logs

Personal information can appear in records that businesses treat as purely technical.

Examples include:

• Login and authentication histories
• IP addresses and device identifiers
• Access and audit logs
• Email metadata
• Support tickets and chat records
• Location and behavioural analytics
• Fraud and risk scores
• Automated decision records

These records may reveal identity, behaviour, relationships, work patterns, locations, or decisions affecting an individual.

Technical logs should appear in the data inventory with defined access, monitoring, retention, deletion, and incident-response requirements.

Logs should support accountability without collecting unnecessary personal information or retaining high-risk records indefinitely.

Businesses should also inventory exports, cached copies, test data, local downloads, and backups. These copies can bypass controls applied to the primary system.

How to Build a Personal Data Register

A personal data register records what personal information the business holds and how it moves through systems, departments, vendors, and storage locations.

It should cover ERP and CRM platforms, payroll software, email, cloud storage, local devices, paper files, backups, integrations, and third-party applications.

For each data category, the register should record:

• The collection source and purpose
• The legal or operational reason for holding it
• Its storage location
• Users and roles with access
• Internal uses and external recipients
• Overseas disclosures
• Retention and deletion requirements
• The accountable business owner

The register should describe current practices, not intended practices. Differences between documented and actual handling should become remediation actions.

1. Identify Where Personal Information is Collected

Start by listing every channel through which the business receives personal information.

Collection points may include websites, online forms, mobile applications, sales conversations, customer support, recruitment, supplier onboarding, email, and paper documents.

Indirect collection should also be recorded. Information may arrive through referrals, commercial partners, public databases, integrations, analytics tools, or related businesses.

For each collection point, document the information requested, the purpose, the responsible department, and the collection notice shown to the individual.

The business should confirm that each field is reasonably necessary. Removing unused fields reduces privacy exposure, storage costs, and the impact of a future breach.

2. Record Where the Information is Stored

Record every system, device, repository, and physical location where personal information is held.

Storage locations may include:

• ERP and CRM platforms
• Accounting and payroll systems
• Email inboxes and archives
• Cloud drives and collaboration tools
• Employee laptops and mobile devices
• Paper files and off-site archives
• Backups and disaster recovery environments
• Vendor-hosted applications

The register should distinguish the primary record from copies, exports, attachments, cached data, and backups.

Duplicate repositories make information harder to correct, secure, retain, and delete. Unnecessary copies should be removed through a controlled process.

Storage records should also identify the hosting country, backup location, encryption status, and whether a vendor or overseas recipient can access the information.

Centralised document management tools can help businesses control access, versions, retention, and disposal across operational records.

3. Identify Who Can Access the Information

Access should be assigned according to job responsibilities, not convenience, seniority, or historic permissions.

The register should identify business roles rather than relying only on employee names. This makes access requirements easier to maintain when staff change positions.

Reviews should cover:

• Standard users
• System administrators
• Shared and service accounts
• Contractors and temporary workers
• External vendors
• Former employees
• Dormant accounts
• Connected applications and API integrations

High-risk permissions should require approval from the data owner and system administrator. The business should record who approved access, why it was needed, and when it expires.

Access should be removed promptly when employment, duties, contracts, or vendor relationships end.

4. Document How the Information is Used and Disclosed

The register should record the original collection purpose and every significant internal use or external disclosure.

Internal uses may include service delivery, billing, recruitment, payroll, reporting, fraud prevention, analytics, marketing, or automated decision-making.

External recipients may include banks, payment processors, cloud providers, insurers, professional advisers, government bodies, contractors, and related companies.

The business should compare these activities with its privacy policy, collection notices, contracts, consent records, and legal authority.

Secondary uses should be reviewed carefully. Information collected for service delivery should not automatically be reused for unrelated marketing, profiling, or analytics.

For overseas recipients, the register should identify the country, recipient, purpose, safeguards, subprocessors, and applicable APP 8 assessment.

5. Assign Retention and Deletion Requirements

Each information category should have a defined retention period based on legal, contractual, regulatory, and operational needs.

The rule should state when the retention period begins. It may start when a transaction closes, employment ends, a contract expires, or an account becomes inactive.

The register should also record:

• The legal or business basis for the period
• The event that triggers disposal
• Any required archive period
• Whether backups are included
• The deletion or anonymisation method
• The person authorised to approve disposal
• The evidence retained after disposal

Keeping information indefinitely increases exposure without necessarily creating value.

Deletion should cover working files, local exports, shared drives, archived emails, test environments, and vendor-held copies where applicable.

6. Record the Accountable Business Owner

Every information category should have an accountable business owner with authority over its purpose, quality, use, disclosure, and retention.

Human resources may own employee records, finance may own payment data, sales may own customer information, and procurement may own supplier contacts.

IT may administer the system, but technical administration does not automatically make IT responsible for every business decision involving the information.

The owner should approve material access, resolve data-quality issues, assess new uses, review retention rules, and confirm that controls remain appropriate.

Shared ownership should be avoided where possible. If several departments are involved, the register should name one accountable owner and identify supporting roles.

How to Operationalise Data Protection Across the Data Lifecycle

Privacy requirements become effective when they are embedded into everyday processes rather than managed only through policies and annual reviews.

At collection, businesses should request only necessary information, explain the purpose, provide an appropriate notice, and record consent where required.

During storage, information should be protected through role-based access, secure configuration, backups, monitoring, and encryption where appropriate.

When information is viewed, changed, or exported, workflows should restrict unauthorised activity and retain a reliable history of approvals and user actions.

Before disclosure, the business should confirm the purpose, recipient, legal authority, contract terms, security controls, and overseas privacy implications.

The OAIC APP 8 guidance explains cross-border disclosure and accountability requirements.

Retention schedules should determine how long information remains available. Records that are no longer required should be securely deleted or properly anonymised.

A suspected breach should trigger containment, fact gathering, harm assessment, remedial action, escalation, and notification analysis.

Every major control should produce evidence. Examples include access reviews, approval records, audit histories, consent records, deletion logs, vendor assessments, and breach decisions.

Integrated systems can support these controls through centralised records, permissions, approval workflows, user histories, and faster removal of access.

HashMicro can support operational control across relevant ERP processes by connecting records, roles, approvals, and audit histories.

However, software cannot determine legal coverage or guarantee compliance. Results still depend on configuration, employee conduct, vendor management, security, and ongoing governance.

Privacy Documents Every Australian Business Should Distinguish

Privacy documents serve different audiences and purposes. Combining them into one generic policy can leave employees without procedures and managers without control evidence.

Each document should have an owner, approval date, review cycle, version history, and links to the processes or systems it governs.

1. External Privacy Policy

An external privacy policy explains how the business manages personal information and how individuals can exercise relevant rights.

It should reflect actual practices involving collection, use, disclosure, security, access, correction, complaints, and overseas recipients.

The policy should be clear enough for its intended audience. Legal accuracy should not depend on vague statements that hide material practices.

From 10 December 2026, certain APP entities must add information about substantially automated decisions that may significantly affect individual rights or interests.

2. Privacy Collection Notice

A collection notice gives information at or before the point where personal information is collected, or as soon as practicable afterwards.

It should explain why the information is requested, whether collection is required, the consequences of not providing it, and who may receive it.

The notice should also direct individuals to the privacy policy and explain how they can request access, correction, or make a complaint.

Notices should be tailored to the collection context. A recruitment form, customer application, and supplier onboarding process may require different information.

3. Internal Privacy Manual

An internal privacy manual converts legal and policy requirements into procedures employees can follow.

It may cover:

• Access requests and identity verification
• Correction of inaccurate records
• Direct marketing and opt-out handling
• Access approvals and periodic reviews
• Vendor assessments
• Overseas disclosure checks
• Retention and secure disposal
• Incident reporting and escalation

The manual should assign responsibilities and escalation paths. Employees should know who can approve exceptions and where to report suspected privacy incidents.

4. Personal Data Register

The personal data register maps the information held by the business and connects each category to its purpose, location, users, disclosures, retention rule, and owner.

It provides the operational foundation for privacy reviews, access management, breach assessments, vendor checks, and responses to individual requests.

The register should be updated when systems, forms, integrations, vendors, data categories, or processing purposes change.

5. Data Retention Schedule

A data retention schedule defines how long each record category should be kept and what happens when the period ends.

It should distinguish active storage, restricted archives, legal holds, secure deletion, and anonymisation.

The schedule should connect each period to a legal, contractual, regulatory, or documented operational basis.

It should also explain how the business handles backups, duplicates, paper records, exported files, and data held by vendors.

6. Third-Party and Vendor Register

A vendor register identifies external providers that store, access, receive, or process personal information.

A structured vendor risk control process helps businesses assess external access, security controls, subprocessors, incident duties, and termination arrangements.

For each provider, it should record:

• The service and business owner
• The information categories involved
• Access permissions
• Storage and processing locations
• Overseas recipients and subprocessors
• Contract and security-review status
• Incident-reporting requirements
• Retention and termination arrangements

Contracts should address confidentiality, security, data ownership, access control, incident reporting, audit rights, retention, and deletion after termination.

Vendor reviews should continue after onboarding. Changes to services, locations, subprocessors, ownership, or security controls can alter the risk profile.

7. Data Breach Response Plan

A data breach response plan defines how suspected incidents are reported, contained, assessed, escalated, documented, and notified.

It should name the response team, decision-makers, legal advisers, technical contacts, communications owners, and alternates for key roles.

The plan should establish procedures to:

• Stop further unauthorised access or disclosure
• Preserve relevant evidence
• Identify affected information and individuals
• Assess likely serious harm
• Evaluate remedial action
• Notify individuals and the OAIC when required
• Review causes and corrective actions

Templates can improve response speed, but every incident requires its own factual and harm assessment.

Exercises should test whether employees can recognise an incident, contact the response team, access required records, and make decisions within the required timeframe.

Conclusion

Data protection requires more than a privacy policy or an isolated security control. A defensible program maps legal duties to processes, assigns owners, and enforces retention rules.

ERP systems can support permissions, approvals, records, and audit histories, strengthening governance, but they cannot replace legal advice, secure configuration, or ongoing oversight.

To learn further about data protection for your business, you can consult a free consultation with our experts today.

Keep your workforce aligned, productive, and compliant across every department.

Schedule a Consultation

Frequently Asked Questions