Resources / Information Security and Data Privacy / Data Privacy in Practice

Introduction

Data privacy law has matured significantly over the past decade. The EU's General Data Protection Regulation (GDPR) set a global benchmark when it came into effect in 2018, triggering legislative reform across many jurisdictions.

New Zealand modernised its framework with the Privacy Act 2020 and is extending its transparency requirements through IPP 3A from 1 May 2026. Australia is undertaking its most significant overhaul since the Privacy Act 1988, with reforms in force since December 2024 and further changes still in flight. The UK retained and adapted its GDPR framework after leaving the EU and has made targeted amendments through the Data (Use and Access) Act 2025.

What has not kept pace in most organisations is practical implementation. Policies have been updated. Privacy notices have been published. But the operational discipline required to run a genuinely compliant privacy function is still missing in many regulated businesses. Data mapping, DPIAs, breach response, staff training, vendor oversight. These are the controls that stand up when something goes wrong.

This guide is for practitioners. Compliance professionals, privacy officers, risk managers, and senior leaders who need a clear picture of what a functioning privacy programme looks like. It focuses on the controls that are actually used when the regulator calls, a breach occurs, or a rights request lands.

The guide focuses primarily on the GDPR as the dominant global framework, with specific reference to the New Zealand Privacy Act 2020 (as amended) and Australia's Privacy Act 1988 (as reformed). Where obligations differ in ways that change what you need to do, those differences are called out.

It does not cover every jurisdiction. Use it as a practical guide, then validate the specifics for your sector and country.

The legal framework

Privacy frameworks across jurisdictions share a common architecture. They differ in detail. Understanding the architecture first makes the detail easier to apply.

Controllers and processors

A controller determines the purposes and means of processing personal data. A processor handles data on the controller's behalf. The distinction matters because the obligations differ, and controllers bear the primary compliance burden.

In outsourced environments, the same dataset can involve multiple controllers and processors, each with distinct duties. Article 28 of the GDPR requires a written agreement between the controller and the processor. Missing or inadequate agreements are among the most common and avoidable gaps.

The six GDPR principles

The GDPR's six principles are the clearest statement of what compliant data handling looks like. They apply whether you are processing customer, employee, or third-party data.

Lawful, fair and transparent. Processing must have a valid legal basis. It must not be used to harm individuals. Individuals must be told how their data is being used.

Purpose limitation. Data collected for one purpose cannot be used for an incompatible purpose without a fresh legal basis or the individual's consent.

Data minimisation. Only collect what you actually need. This is one of the most consistently breached principles in practice, usually because organisations have historically collected data in case it is useful.

Accuracy. Personal data must be accurate and kept up to date where necessary.

Storage limitation. Data must not be held longer than necessary for the original purpose. This requires a documented retention schedule and a reliable process for deletion or anonymisation.

Integrity and confidentiality. Data must be protected against unauthorised access, accidental loss, and unlawful processing. This is where privacy and information security overlap directly.

Special categories

Some data is treated as more sensitive: health information, biometric data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation, and information about criminal convictions.

Special categories cannot usually be processed unless a specific condition applies, such as explicit consent, employment law requirements, vital interests, legal claims, or substantial public interest. If you hold health or biometric data, treat this as a design constraint, not a footnote.

New Zealand and Australia

The New Zealand Privacy Act 2020 is built around 13 Information Privacy Principles covering collection, storage, use, disclosure, and access. From 1 May 2026, IPP 3A requires agencies to take reasonable steps to notify individuals when their personal information is collected indirectly, from a source other than the individual, unless an exception applies. The obligation applies to personal information collected indirectly on and from that date.

Australia's Privacy Act 1988 sets out 13 Australian Privacy Principles covering broadly similar ground. The Privacy and Other Legislation Amendment Act 2024 introduced a wide range of reforms, most of which have been in effect since December 2024. Two changes with longer lead times are worth flagging. First, a statutory tort for serious invasions of privacy has been in effect since 10 June 2025. Second, new transparency requirements for automated decision-making will require updates to privacy policies by 10 December 2026, where computer programs use personal information to make, or materially support, decisions that could significantly affect an individual's rights or interests. Further reforms are expected, but the scope and timetable will depend on the next legislative tranche.

New Zealand's EU adequacy status is practically significant. It means that EU and UK organisations can transfer personal data to New Zealand without needing additional safeguards such as standard contractual clauses. Australia does not have this status. Organisations moving data between Australia and the EU need a lawful transfer mechanism in place.

Lawful bases for processing

One of the questions that trips up practitioners most frequently is not whether data can be processed, but on what basis. The GDPR requires a documented legal basis for every processing activity. Collecting data and worrying about the legal basis later is not a compliance approach. It is a liability.

The six lawful bases

The GDPR provides six lawful bases for processing personal data. Only one needs to apply to any given processing activity, but you must identify it before processing begins, document it, and reflect it in your privacy notice.

Consent. The individual has given clear, specific, informed and unambiguous consent to the processing. Consent must be freely given. Pre-ticked boxes do not constitute consent. Individuals must be able to withdraw consent as easily as they gave it. Consent is often the wrong choice for regulated financial services organisations because it creates dependencies on individual behaviour and can be withdrawn at any time. Many organisations default to consent when a different basis would be more appropriate and more stable.

Contract. Processing is necessary for the performance of a contract with the individual or for taking steps at their request before entering into a contract. This is the most straightforward basis for processing core customer data in banking and financial services.

Legal obligation. Processing is necessary to comply with a legal obligation. This applies to AML, tax reporting, and other statutory requirements. The obligation must be specific and identifiable.

Vital interests. Processing is necessary to protect someone's life. Rarely relevant outside healthcare.

Public task. Processing is necessary for the performance of a public function carried out in the public interest. Relevant to public bodies and some regulated activities.

Legitimate interests. Processing is necessary for the legitimate interests of the controller or a third party, unless those interests are overridden by the data subject's rights and interests. This is the most flexible basis but also requires a documented three-part test: identify the legitimate interest, demonstrate that processing is necessary, and balance against the individual's rights. The ICO publishes guidance on conducting a legitimate interests assessment. For financial crime prevention, fraud detection, and network security, legitimate interests are usually the correct basis.

Practical implications

Most regulated organisations need to maintain a lawful basis for each processing category they carry out. The practical task is to map your processing activities, identify the appropriate basis for each, and document that analysis.

Where consent is your basis, you need a reliable mechanism for capturing, recording and managing it. Where legitimate interests are your basis, you need a documented assessment. Both must be made visible to the supervisory authority upon request.

Switching lawful basis after the fact is not permissible. If you collected data with consent and later want to process it for a different purpose, consent must be obtained for that new purpose, or a different applicable basis must be identified and documented.

Individual rights

Modern privacy frameworks are built around the rights of the individual. For regulated organisations, those rights generate operational obligations that need to be embedded into processes and systems, not just reflected in policy.

The rights under GDPR

The GDPR establishes eight individual rights. The practical burden of each varies significantly.

Right to be informed. Individuals must be told who is collecting their data, why, on what legal basis, how long it will be retained, with whom it will be shared, and what their rights are. This is delivered primarily through privacy notices, which must be concise, transparent, and written in plain language.

Right of access (Article 15). Individuals can request a copy of the personal data you hold about them. This is the Subject Access Request. You have one calendar month to respond. There is no fee. In the UK, complaints about SAR handling make up a larger proportion of ICO complaints than any other issue. The volume of SAR requests has increased significantly as awareness of the right has grown. Organisations that lack a documented, tested process for handling SARs will struggle.

Right to rectification (Article 16). Individuals can request correction of inaccurate or incomplete data. One month to respond. Document the request and the outcome.

Right to erasure (Article 17). Sometimes described as the right to be forgotten. Individuals can request deletion of their data where it is no longer needed for the original purpose, consent has been withdrawn, or processing was unlawful. Not absolute. Financial services organisations have legitimate grounds to retain data for AML record-keeping, legal claims, and other purposes. But the decision to decline must be documented and communicated.

Right to restrict processing (Article 18). Individuals can request a pause on processing while a dispute about accuracy or lawfulness is resolved. The data is retained but not used.

Right to data portability (Article 20). Applies where processing is based on consent or contract and carried out by automated means. Individuals can request their data in a machine-readable format for transfer to another organisation. Open banking frameworks have built on this concept.

Right to object (Article 21). An absolute right to stop direct marketing. In other cases, such as processing based on legitimate interests, individuals can object, but the organisation may continue if it can demonstrate compelling legitimate grounds.

Rights related to automated decision-making (Article 22). Individuals have the right not to be subject to a decision based solely on automated processing that has a significant effect on them. This covers credit scoring, insurance decisions, and employment screening.

Equivalent rights in New Zealand and Australia

The New Zealand Privacy Act and the Australian Privacy Act both grant rights of access and correction (IPP 6 and 7 in New Zealand; APP 12 and 13 in Australia) and place limits on use and disclosure. They do not include the full GDPR list, but the same operational logic applies: individuals have rights, and the organisation needs a documented process for handling them within the required timeframes.

Data Protection Impact Assessments

A Data Protection Impact Assessment is a structured process for identifying and addressing the privacy risks of a new project or change. Under Article 35 of the GDPR, a DPIA is mandatory for processing that is likely to result in a high risk to individuals' rights and freedoms. In practice, the mandatory threshold is lower than many organisations appreciate.

When a DPIA is required

The GDPR specifies that a DPIA is required, at a minimum, for three categories of processing: systematic and extensive evaluation of personal aspects based on automated processing (including profiling) where decisions produce legal or similarly significant effects; large-scale processing of special categories of data or data relating to criminal convictions; and systematic monitoring of a publicly accessible area on a large scale.

Supervisory authorities, including the ICO, have published lists of processing types for which they consider a DPIA mandatory. These typically include biometric identification systems, processing by public bodies affecting large numbers of individuals, and innovative use of technology where the privacy impact is not well understood.

Beyond mandatory cases, it is good practice to conduct a DPIA for any significant new processing activity. The cost of doing so is modest. The cost of launching a privacy-invasive system without a DPIA is potentially high.

What a DPIA involves

A DPIA is not a form-filling exercise. Done properly, it is a substantive analysis of how a proposed processing activity works, the risks it creates, and the controls needed.

A well-structured DPIA covers a description of the proposed processing (what data is collected, from whom, on what basis, how it is stored, who has access, and how long it is retained); an assessment of the necessity and proportionality of the processing; identification of the risks to individuals (what could go wrong, and how likely and severe the impact would be); the controls proposed to mitigate those risks, and a residual risk assessment after controls are applied.

The DPIA should be completed before the processing starts, not after the system is built. In practice, this means embedding DPIA requirements into the project governance of any significant change initiative. Privacy by design is not a slogan. It is the requirement that privacy controls are built into systems from the outset, not retrofitted.

DPIAs in New Zealand and Australia

Neither the New Zealand Privacy Act nor the Australian Privacy Act mandates a formal DPIA process for the private sector. However, Privacy Impact Assessments are strongly recommended by the Office of the Privacy Commissioner in New Zealand and considered good practice in Australia. The Australian Government Agencies Privacy Code requires Privacy Impact Assessments for some government projects, and the 2024 reforms strengthened the expectation of proactive risk assessment more generally. Organisations operating across jurisdictions are best served by adopting a single DPIA process based on the GDPR standard.

Data breach management

Data breaches happen to organisations of all sizes, in all sectors, at all levels of maturity. The question is not whether your organisation will experience a breach, but whether it can detect it, respond to it, and manage the consequences.

What constitutes a data breach

A personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The definition is wide. It includes not just external cyberattacks but internal errors: sending data to the wrong recipient, losing an unencrypted device, inadvertently publishing personal data on a public website.

Many breaches are never reported to regulators because organisations do not recognise them as breaches in the first place. A robust breach management framework starts with a culture in which staff feel safe reporting incidents, not with the formal response process.

Notification obligations

The GDPR requires controllers to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. The 72-hour clock starts when the organisation becomes aware of the breach, not when it is confirmed or fully investigated.

Notification to the supervisory authority must include a description of the nature of the breach, the approximate number of individuals and records affected, the likely consequences, and the measures taken or proposed. Where notification cannot be made within 72 hours, the reasons for the delay must be included.

Notification to the affected individuals is also required where the breach is likely to result in a high risk to their rights and freedoms. The threshold for individual notification is higher than the threshold for regulatory notification. But where it applies, it must be delivered without undue delay and must explain, in plain language, what happened and what the individual should do.

Under the New Zealand Privacy Act 2020, notifiable privacy breaches must be reported to the Privacy Commissioner and the affected individuals as soon as practicable. The threshold is a breach that has caused, or is likely to cause, serious harm. In Australia, the Notifiable Data Breaches scheme under the Privacy Act 1988 requires notification to the OAIC and affected individuals of eligible data breaches.

Building a breach response capability

Effective breach response is not something you can build in the middle of a crisis. It requires preparation. The components of a breach response capability are straightforward: a clear definition of what constitutes a breach and how it is reported internally; a documented response process with named responsibility for each step (triage, assessment, escalation, forensics, notification, remediation); a breach register that records every incident and the rationale for notification decisions; and regular testing, so that you are not learning the process under pressure.

Not all breaches require notification. The test under the GDPR is whether the breach is unlikely to result in a risk to the rights and freedoms of individuals. If it is unlikely to result in that risk, notification to the supervisory authority is not required. However, all breaches must be documented internally, regardless of whether notification is required. The breach register is the evidence that the organisation has assessed each incident and made a reasoned decision.

The privacy programme

Compliance with data privacy law is not a project. It has no end date. It is an ongoing operational discipline that needs to be embedded into how the organisation works, managed by people with sufficient authority and resources, and reviewed and updated as the regulatory environment evolves.

The Data Protection Officer

Under Article 37 of the GDPR, a Data Protection Officer is mandatory for public authorities, organisations that carry out large-scale systematic monitoring of individuals, and organisations that process special categories of data on a large scale. Many financial services organisations will meet at least one of these criteria.

The DPO must have expert knowledge of data protection law and practice. They must be able to operate independently, without being told what conclusions to reach. They must not be placed in a role that creates a conflict of interest, meaning they cannot be the person who decides the purposes and means of the processing they are meant to oversee. In practice, that often rules out combining the DPO role with senior operational, IT, security, HR, or marketing roles. Whether it rules out legal or compliance roles depends on the organisation's structure and decision-making, but the conflict point needs to be tested properly, not assumed away.

Organisations not required to appoint a DPO should nonetheless ensure that someone is clearly responsible for privacy compliance, has the expertise to discharge that responsibility, and has access to senior management when needed.

In New Zealand, the Privacy Act 2020 does not mandate a Privacy Officer, but Section 201 allows organisations to appoint one, and doing so is considered good practice. In Australia, the Australian Government Agencies Privacy Code requires public sector agencies to appoint a Privacy Officer.

Data mapping

You cannot manage what you cannot see. Data mapping is the process of identifying and documenting the personal data your organisation holds, where it comes from, how it is processed, where it is stored, who has access to it, how long it is retained, and where it is transferred.

A data map is not a one-time exercise. It needs to be maintained as systems, processes, and organisational structures change. In practice, the organisations that have the most difficulty with data breaches, SAR responses, and regulatory inquiries are the ones whose data map is out of date or non-existent.

Article 30 of the GDPR requires controllers to maintain a record of processing activities. This is a legal obligation, not guidance. The record must be available to the supervisory authority on request. For organisations with more than 250 employees, or those whose processing carries risk, this obligation applies regardless of the size threshold.

Third party and vendor management

Most regulated organisations share personal data with third parties, including service providers, technology vendors, outsourced functions, and group entities. Each of those relationships creates a risk exposure that the controller is responsible for managing.

Article 28 of the GDPR requires a written Data Processing Agreement with any processor. The agreement must specify the nature and purpose of the processing, the type of data involved, the controller's instructions, and the processor's obligations regarding security, confidentiality, assistance with rights requests, breach notification, and the return or deletion of data at the end of the engagement.

In practice, many organisations have DPAs in place for their major technology vendors but not for all their data processors. A vendor management review that maps all third-party data sharing and confirms adequate contractual protections are in place is one of the most commonly deferred and most necessary elements of a privacy programme.

Due diligence on new vendors should include an assessment of their privacy and security practices before onboarding, not after. A vendor that cannot demonstrate how they protect personal data should not be given access to yours.

Privacy and information security

Privacy and information security are not the same discipline, but they are closely connected. The confidentiality principle in GDPR directly requires appropriate technical and organisational security measures. Inadequate security is a privacy failure.

Article 32 of the GDPR sets out the general standard. It does not specify particular technologies or controls. What it requires is a risk-based approach: understand the risks to the data you hold, and implement controls proportionate to those risks. The controls that satisfy Article 32 substantially overlap with those that satisfy information security frameworks such as ISO 27001 and the NIST Cybersecurity Framework. Organisations that have invested in ISO 27001 certification or equivalent have typically addressed a significant portion of their Article 32 obligations. However, certification is not a substitute for the privacy-specific obligations: legal basis, individual rights, DPIA, breach notification, and vendor management are not covered by information security frameworks.

Article 25 of the GDPR introduces the principle of privacy by design and by default. Data protection must be integrated into systems and processes from the outset, not added later. By default, only the personal data necessary for the specific purpose should be processed. This is not a technical concept. It is a governance requirement.

Staff training

Most data breaches involve human error. Most regulatory breaches involve processes that staff have not been trained to follow. Staff training is not an optional extra in a privacy programme.

Training should cover what personal data is, the organisation's obligations, how to handle data subject requests, what constitutes a breach and how to report it, and the consequences of non-compliance. It should be role-specific for staff with higher-risk data handling responsibilities. Training should be delivered on induction, refreshed regularly, and documented. The documentation matters because, if a breach occurs, one of the first questions from the supervisory authority will be whether the staff involved were trained.

Enforcement and penalties

The regulatory consequences of privacy failures have escalated significantly since the GDPR came into force. The headline fines are large. More relevant to most organisations are the investigation costs, reputational damage, and remediation work that follow.

GDPR enforcement

The GDPR provides for fines at two tiers. The lower tier, covering less serious infringements such as administrative failures and notification breaches, is up to 10 million euros or 2% of global annual turnover, whichever is higher. The upper tier, applying to breaches of the core principles, lawful bases, consent requirements, individual rights, and international transfer rules, is up to 20 million euros or 4% of global annual turnover, whichever is higher.

The scale of enforcement has grown considerably since 2018. The Irish Data Protection Commission imposed a 1.2 billion euro fine on Meta Platforms in 2023 for unlawful international data transfers, the largest GDPR fine to date. The Luxembourg DPA fined Amazon 746 million euros in 2021 for advertising targeting without proper consent. TikTok was fined 345 million euros by the Irish DPC for failures in handling children's data.

Enforcement is not limited to large platforms. Regulators in several member states have taken action against mid-size organisations for failures in SAR handling, data security, and unlawful processing. The ICO in the UK has increasingly used its powers to investigate and sanction public and private sector organisations.

Enforcement in New Zealand and Australia

The Office of the Privacy Commissioner in New Zealand can investigate complaints, issue compliance notices, and refer serious cases to the Human Rights Review Tribunal, which can award damages. The 2020 Act introduced mandatory breach notification and increased the Commissioner's powers. The focus of enforcement has been on organisations that fail to address breaches or demonstrate systemic non-compliance adequately.

In Australia, the 2024 reforms strengthened enforcement and introduced a statutory tort for serious invasions of privacy, which took effect on 10 June 2025. For serious or repeated interference with privacy by a body corporate, the maximum civil penalty is the greater of 50 million Australian dollars, three times the value of the benefit obtained, or 30 per cent of adjusted turnover for the breach turnover period. A further tranche of reform is expected, but the timing and content remain subject to the legislative agenda.

Ten steps to implementation

For organisations building a privacy programme from the ground up, the following sequence is an effective starting point.