NZ Privacy Act 2020 Testing & Compliance
New Zealand has its own privacy law, distinct from GDPR. The 13 Information Privacy Principles govern how systems must collect, use, store, and share personal data. Learn to test compliance, verify consent workflows, and avoid the regulations that carry $3000 fines and Human Rights Commission investigations.
1 The Hook — Why This Matters
In 2023, a Dunedin SaaS company launched a staff scheduling tool without testing privacy compliance. They collected employee phone numbers and shift preferences, stored them in plain text in a US-based cloud service, and shared the data with shift managers who hadn't explicitly agreed. A disgruntled employee complained to the Privacy Commissioner. The investigation found breaches of four Information Privacy Principles: Collection, Use and Disclosure, Security, and Access.
The company wasn't under GDPR (it was NZ-based but served mostly NZ users). The fines under the Privacy Act 2020 were NZ$3,000 per breach. The remediation cost $150,000. The reputational damage was worse. A senior tester who understood NZ Privacy Act compliance would have caught this in the first security review.
This page teaches the Information Privacy Principles and how to verify them in code. Compliance testing is not optional. It is a legal obligation.
2 The Rule — The One-Sentence Version
The Privacy Act 2020 defines 13 Information Privacy Principles. Your job is to verify that the system meets each one. Don't confuse NZ law with GDPR: they are different in scope, enforcement, and scope.
GDPR is EU/UK law. The Privacy Act 2020 is NZ law. GDPR has a 4% global revenue penalty. Privacy Act has a NZ$3,000 maximum fine. GDPR is stricter on consent. Privacy Act permits some uses without explicit consent under "legitimate interest." Know which law applies to your users.
3 The Analogy — Think Of It Like...
A health clinic's paper filing system, audited by the Health Board.
The 13 Privacy Principles are like the clinic's filing rules: (1) only collect what's needed, (2) use it only for the stated purpose, (3) keep it secure and locked, (4) let the patient access their file, (5) correct wrong information, (6) delete old files after a retention period, (7) don't share without permission. The Health Board audits compliance. Systems must follow the same rules. The Privacy Commissioner is the audit authority.
4 Watch Me Do It — Step by Step
Here is a systematic walkthrough of testing privacy compliance for a real NZ system: an employee HR portal that collects salary data, bank account numbers, and emergency contact information.
- Principle 1: Collection Limitation Verify the system only collects data that is necessary for the stated purpose. The HR portal collects Salary, Bank Account, Emergency Contact, Home Address, and Marital Status. Which are necessary? Salary (yes—for payroll), Bank Account (yes—for payment), Emergency Contact (yes—for emergencies), Home Address (questionable—for what purpose?), Marital Status (no—not necessary). Test: attempt to submit the form without optional fields marked optional. Attempt to see the form spec to verify which fields are documented as "necessary".
- Principle 2: Use Limitation Verify personal information is used only for the purpose it was collected for. The HR portal collects salary data for payroll. Verify the salary data is not exported or shared with third-party analytics vendors. If it is, the employee must have been informed ("We will share your salary with Guidepoint Analytics"). Test: trace the data flow. Does salary data leave the system? Who has access to it?
- Principle 3: Individual Participation — Access Every person must be able to access their own data. Test: log in as an employee. Can you view all personal data the system holds about you? Does the download format export all fields? If not, send a formal request to the organisation and verify they provide the data in a timely manner (20 working days under the Act).
- Principle 4: Data Quality & Accuracy Test that personal data is accurate and kept up to date. Can an employee correct their own information? If they submit a correction request, is it processed? Verify the system doesn't cache or freeze data (old backups are okay if retention policy is documented).
- Principle 5: Data Security Verify personal information is protected by appropriate security measures. Test: Is salary data encrypted in transit (HTTPS)? At rest (encrypted in the database)? Who has access to the database? Are access logs maintained? Can you view your own access history?
- Principle 6: Openness — Privacy Policy Verify the organisation has a clear privacy policy stating what data they collect, why, and who can access it. Test: Is the privacy policy linked from every page where data is collected? Does it explain data retention periods?
- Principle 7: Prevention of Misuse Verify the system prevents unauthorised use of personal data. Test: Can an HR manager view another employee's salary without legitimate reason? Are role-based access controls enforced? Is there an audit trail?
- Data Retention & Deletion Verify the system has a documented retention policy. How long is salary data kept? What happens when an employee leaves? Can an employee request deletion? Test: attempt to request deletion of your account. Verify the system responds with a documented timeline for data removal.
- Third-party Data Sharing If data is shared with third parties (e.g., payroll processor), verify explicit consent was obtained and documented. Test: Can you see a list of third parties with access to your data? Can you revoke consent to share with a specific third party?
- Breach Notification If personal data is compromised, the Privacy Act requires notification to affected individuals (without unreasonable delay). Test: Review incident response processes. Does the organisation have a documented breach notification procedure? What is the timeline?
| Principle | Rule | Test point |
|---|---|---|
| 1. Collection | Collect only necessary data | Are optional fields documented? Why is each field collected? |
| 2. Use & Disclosure | Use only for stated purpose | Does salary data leave the system? Who sees it? |
| 3. Data Quality | Keep data accurate, up-to-date | Can employees correct their information? |
| 4. Accuracy | Data is correct; outdated data is updated | Is there a process for accuracy complaints? |
| 5. Retention | Retain only as long as necessary; then delete | What is the documented retention period? |
| 6. Security | Protect against loss, misuse, modification | Is data encrypted in transit and at rest? |
| 7. Openness | Publish privacy policy; be transparent | Is privacy policy clear and accessible? |
| 8. Access | Individual can access their data | Can users download all data about them? |
| 9. Correction | Individual can request correction | Is there a correction request form? |
| 10. Prevention of Misuse | Prevent unauthorised use | Are access controls role-based? Is there an audit log? |
| 11. Unique Identifiers | Don't use personal ID without good reason | Is IRD number stored? Justified? |
| 12. Anonymisation | De-identify data when possible | Are anonymised datasets actually de-identifiable? |
| 13. Overseas Disclosure | Don't send overseas without safeguards | If data goes to US cloud, are safeguards documented? |
| Aspect | NZ Privacy Act 2020 | GDPR (EU/UK) |
|---|---|---|
| Scope | NZ-based organisations + organisations serving NZ residents | EU/UK organisations + organisations serving EU/UK residents |
| Consent requirement | Required for sensitive data; "legitimate interest" permitted for non-sensitive | Explicit consent required for all personal data |
| Penalty | Max NZ$3,000 per breach | Up to 4% global revenue or €20 million |
| Right to be forgotten | Not explicitly required (retention policy governs) | Explicit right to deletion |
| Data Protection Officer | Not required | Required for large processors |
| Enforcement | Privacy Commissioner (NZ) | Data Protection Authorities (EU/UK) |
| Overseas transfer | Allowed with documented safeguards | Restricted to "adequate" jurisdictions |
5 When to Use It / When NOT to Use It
✅ Use this testing when...
- The system collects, stores, or processes personal data
- The organisation is NZ-based or serves NZ residents
- The system is in pre-launch compliance review
- There has been a security or data handling change
- Users request access to, correction of, or deletion of their data
- A data breach or security incident occurs
- Te Tiriti obligations apply (iwi data, Maori health)
❌ Don't use it when...
- The system processes only non-personal data (aggregate stats)
- You're testing a purely EU/UK service (use GDPR framework)
- Personal data is already anonymised and cannot be re-identified
- The system is read-only without data collection
- You have no access to privacy documentation or policies
Before you test privacy compliance, ask:
- Does the organisation have a documented privacy policy?
- What personal data is collected and why?
- Who has access to the data and under what conditions?
- What is the documented data retention and deletion policy?
6 Common Mistakes — Don't Do This
🚫 Assuming GDPR applies when it is NZ Privacy Act
I used to think: GDPR is the global privacy standard, so I'll use that framework.
Actually: NZ Privacy Act 2020 has different rules. It permits "legitimate interest" uses without consent (GDPR requires explicit consent). It has no "right to be forgotten"—retention policy governs deletion. It has no Data Protection Officer requirement. GDPR fines are up to 4% revenue; Privacy Act fines are capped at NZ$3,000. Know which law applies to your users.
🚫 Confusing "minimisation" with "don't collect anything"
I used to think: The Privacy Act says collect only what's necessary, so we should ask for minimal data.
Actually: "Necessary" is context-dependent. An HR system needs salary, bank account, and emergency contact. An e-commerce site needs address for shipping. Don't mistake privacy minimisation for "ask for nothing"—ask for what you actually need and document why. Undercollecting defeats the system's purpose.
🚫 Not documenting consent
I used to think: If the user ticked a checkbox, consent is proven.
Actually: You must prove the user consented at a specific date and time. Store the consent record: the date, what they consented to, the privacy policy version they saw. Without documented evidence, the Privacy Commissioner won't accept your defence if investigated.
When privacy compliance testing fails
Usually the problem is that consent wasn't documented, data is stored longer than the stated retention policy, overseas disclosure occurred without documented safeguards, or access controls are missing (staff can view other employees' data). Also watch for hardcoded PII in logs, unencrypted database exports, and missing audit trails. Always trace the data flow from collection to deletion.
7 Now You Try — Health Clinic Portal
Scenario: You are testing a NZ health clinic's patient portal. The clinic collects name, DOB, address, email, phone, medical history, and medication list. They store data in a US-based cloud service. They want to email appointment reminders to patients.
Your task: Identify at least five Privacy Act compliance test points specific to this system.
Suggested privacy test points for health clinic:
- Collection Limitation (Principle 1): Medical history is sensitive personal information. Verify explicit informed consent was obtained. Check the consent form states the data will be used for clinical care only, not research or third-party sharing without further consent.
- Overseas Disclosure (Principle 13): Data is stored in a US-based cloud service. Verify the clinic has documented what safeguards are in place (encryption, access controls). Under Privacy Act, overseas transfer requires documented appropriate protections. Test: Can the clinic explain what happens if the US cloud provider is breached?
- Security (Principle 6): Medical history is highly sensitive. Verify data is encrypted in transit (HTTPS) and at rest (encrypted database). Test: Can you access the database directly? Can staff download unencrypted patient lists?
- Access (Principle 8): Test: Can a patient log in and view their full medical history? Can they download a copy? Can they request a copy from the clinic directly?
- Correction (Principle 9): Test: If a patient's medication list is wrong, can they request a correction? Is there a documented correction workflow? Who approves medication corrections (the patient's GP)?
- Openness (Principle 7): Test: Is there a privacy policy? Does it state what data is collected, who sees it (just the patient's GP, or admin staff?), and how long it is kept? For a health clinic, retention might be 10 years post-final appointment, then deleted.
Key insight: Health data is sensitive. The clinic must justify every field collected (medical history = necessary; insurance provider = maybe not necessary, so ask why). Overseas disclosure is a high risk; the clinic must have documented safeguards (encryption, access logs, breach notification from the cloud provider). Te Tiriti also applies—if any patients are Maori, consider whether their data is treated with cultural respect and whether iwi leadership was consulted on data use.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What is the difference between Privacy Act and GDPR?
NZ Privacy Act applies to NZ organisations and organisations serving NZ residents. It permits "legitimate interest" uses without explicit consent (for non-sensitive data). Fines are capped at NZ$3,000. GDPR applies to EU/UK organisations and residents, requires explicit consent for all data, has fines up to 4% revenue, and includes a "right to be forgotten." They are different laws for different jurisdictions.
Q2. Name three Privacy Act breaches that are most common in NZ systems.
(1) Collecting more data than necessary without documented justification, (2) Not documenting consent—storing ticked checkboxes without timestamp, version of policy, and date, (3) Storing personal information in plain text or unencrypted in overseas clouds without documented safeguards, (4) Not having an access control policy (staff can view all customer data regardless of role), (5) No audit trail of who accessed what data when.
Q3. What evidence must you collect to prove a system is Privacy Act compliant?
Document: (1) Privacy policy (clear, accessible, states what data is collected and why), (2) Data retention and deletion policy with timelines, (3) Consent records (date, version of policy, what was consented to), (4) Access controls and audit logs (who can see what data, when, and why), (5) Encryption in transit and at rest, (6) Overseas disclosure safeguards (if applicable), (7) Breach notification process and timeline, (8) Right to access/correct/delete workflows with SLAs.
9 Interview Prep — Senior Privacy Questions
Privacy compliance questions are common in senior QA interviews for NZ companies. These are real questions.
Q. "We're GDPR-compliant, so we're GDPR-compliant under NZ Privacy Act too, right?"
No. GDPR and NZ Privacy Act are different. GDPR is stricter on consent (explicit required for all data). Privacy Act permits legitimate interest without explicit consent. Also, GDPR has a right to be forgotten; Privacy Act does not (retention policy governs). If your system serves NZ users, test against NZ Privacy Act, not just GDPR. Know which law applies to your user base.
Q. "How do you test data retention policies?"
First, get the documented retention policy: "Salary data retained for 7 years post-employment, then deleted." Then trace the data: Is salary data stored in the active database only, or in backups? If backups are kept for 10 years, the actual retention is 10 years, not 7. Test deletion: Request your own data deletion, verify it's removed from active DB and scheduled backups within the stated timeline. Audit logs should show when data was deleted and who authorised it.
Q. "A customer in NZ and one in the EU. Which privacy law applies to each?"
Both. If the EU customer is in the EU, GDPR applies to their data. If the NZ customer is in NZ, Privacy Act applies. If you have a single system serving both, you must meet the stricter law for all users (GDPR, because it's stricter). So in practice: GDPR for everyone. Same applies if you have US (no federal law) and NZ users: Privacy Act for both.