Compliance & Privacy Testing
Verify that your system handles personal data correctly according to regulations like GDPR, CCPA, and NZ Privacy Act 2020. This includes encryption, access control, consent flows, data deletion, and audit logging.
1 The Hook
A Christchurch health-and-wellbeing app adds a “Delete my account” button to meet its obligations under the Privacy Act 2020. A tester clicks it, the account disappears from the app, the profile page 404s, sign-off given. The feature “works”.
Six months later a former user makes a complaint to the Office of the Privacy Commissioner: after deleting their account they received a marketing email referencing their old appointments, and a support agent was still able to pull up their full medical notes. The “delete” button had only flipped a status = inactive flag. The records were still in the live database, still in nightly backups, still synced to a third-party analytics tool, and still on the marketing list. The app looked compliant from the front end and was breaching the Act everywhere the tester didn’t look.
This is what makes compliance and privacy testing different: the visible behaviour can be completely correct while the legal obligation is completely unmet. “The button works” is not the question. “Is the data actually gone, everywhere, and can you prove it?” is the question — and that answer lives in the database, the backups, the logs, and the third-party integrations, not on the screen.
Most teams spend days verifying deletion on their own database and call it done. The actual liability is almost always sitting in the integrations nobody mapped. I have seen NZ health and government projects where the core app deleted correctly, but Mailchimp still held the patient’s email, Google Analytics still knew their pseudonymous ID, and the Salesforce CRM still had their case notes — because no one ever asked the vendors whether they had a deletion endpoint, let alone called it. Under the Privacy Act 2020, that is a notifiable breach waiting for a complaint. Before any “delete” feature is signed off, get engineering to give you a complete list of every third party that received that user’s data. Then verify each one. The ones with no documented deletion API are your compliance gaps — raise them explicitly.
2 The Rule
A compliance failure is a legal liability, not a UI bug — so don’t test what the screen shows, test what the system actually does with the data. Verify deletion, access, consent and encryption all the way down: the database, the backups, the logs, and every third party the data was shared with.
3 The Analogy
Shredding a document versus putting it in a drawer.
Imagine a clinic that promises to destroy your file when you leave. Closing the filing cabinet so you can’t see the folder is not destroying it — the file is still there, the receptionist can still open the drawer, and there are photocopies in the back office and at the off-site storage company. The patient asked for it to be gone; “out of sight” is not “gone”.
Privacy testing is being the person who checks the shredder actually ran — and then walks to the back office and the storage company to confirm there are no copies left. A “delete” that only hides the record is exactly the closed drawer: it satisfies the eye and breaches the promise.
Senior engineer insight
The moment I stopped thinking of compliance testing as "checking boxes on a regulation list" and started treating it as "verifying every data flow promise the system makes," everything changed. The regulation is just a formalisation of what the user was already owed — test from that angle and you catch the gaps that a checklist never will. The most revealing test I run on any privacy-sensitive system is asking engineering to draw a complete data-flow diagram, then testing every line on that diagram for deletion, access control, and consent — not just the ones visible in the UI.
Most common mistake: testing the front-end delete button and calling it done. The real work is verifying the data is gone from the database, the backups, the logs, and every third-party integration — which almost never happens without someone explicitly asking for it.
From the field
On a NZ health-sector project — a digital triage tool collecting patient contact details and symptom history — we passed a full functional regression two weeks before go-live. A privacy review the day before launch caught that we were sending the patient's NHI number and appointment date to a third-party analytics vendor in a custom event attribute. The vendor's contract said they retained event data for 18 months with no deletion endpoint. Under the Health Information Privacy Code and the NZ Privacy Act 2020 Information Privacy Principle 3A, we were collecting and disclosing that data beyond the stated purpose, with no DPA in place. The analytics integration was removed on the day and the launch delayed a week. The lesson that generalises: always map third-party data flows before sign-off, not after — and check every vendor contract for retention and deletion terms, not just security certifications.
What it is
Compliance testing verifies that a system follows laws and regulations that govern data handling. Privacy testing is a subset: checking that personal data is protected, only used for stated purposes, and can be accessed or deleted by the individual it belongs to.
Most businesses don’t have a dedicated privacy test team. This falls on testers to catch — alongside security testing. The line blurs: encryption is both a security control and a privacy requirement. Access control is both a security boundary and a compliance mandate.
Compliance failures are not bugs; they’re liabilities. An inaccessible feature is bad UX. A missing encryption layer is a fine. A system that doesn’t let users delete their data violates GDPR and can result in fines up to 4% of global revenue.
Key regulations to know
GDPR (EU and UK)
General Data Protection Regulation. Applies to any company processing data of EU residents, regardless of where the company is based. Rights include: access (give me my data), rectification (fix my data), erasure (delete me), portability (export my data), and objection (stop processing my data).
CCPA (California, USA)
California Consumer Privacy Act. Grants California residents similar rights: access, deletion, opt-out of sale. Fines up to $7,500 per intentional violation.
NZ Privacy Act 2020
New Zealand’s privacy law. Applies to all organisations in NZ that hold personal information, plus overseas companies that collect data about NZ residents. Key rights: access, correction, and deletion. The Privacy Commissioner can issue compliance orders.
HIPAA (USA healthcare)
Health Insurance Portability and Accountability Act. Requires encryption of patient data (PHI — Protected Health Information) at rest and in transit, audit logging, and breach notification within 60 days.
PCI DSS (payment cards)
Payment Card Industry Data Security Standard. If you process credit cards, you must encrypt card data, restrict access, maintain audit logs, and undergo annual assessments. Level of compliance depends on transaction volume.
NZ Privacy Act 2020: what testers must verify
| Requirement | What to test | Red flags |
|---|---|---|
| Collection limits Only collect data for stated purpose |
Does the privacy policy say why data is collected? Is the system collecting data beyond that? | Collecting phone numbers “just in case” without a stated purpose; selling data to third parties not disclosed in policy |
| Use limitation Only use data for the stated purpose |
If data is collected for shipping, is it used for marketing without consent? | Address used for marketing mail; email sold to a broker |
| Data accuracy Data must be accurate and kept up to date |
Can users correct their information? Is there a correction flow? Does corrected data propagate? | Edit profile button does nothing; old address still used for shipping after correction |
| Right of access Individuals can request and view their data |
Can a user export their data? Is all data they provided included? Is it in a usable format? | Export missing recent transactions; exported file is corrupted |
| Right of deletion Individuals can request deletion |
Can a user delete their account? Is all personal data removed? Are backups purged? | Delete button doesn’t work; data remains in a backup; old emails still sent after deletion |
| Data security Personal data must be protected |
Is data encrypted in transit (HTTPS) and at rest (database)? Are access logs kept? | HTTP instead of HTTPS; passwords stored in plaintext; no audit log of who accessed what data |
Core testing areas
Encryption (in transit and at rest)
In transit: All endpoints handling personal data must use HTTPS with TLS 1.2 or higher. Test with a network sniffer (Wireshark, browser DevTools) to verify data is not sent in plaintext over HTTP.
At rest: Sensitive data in the database must be encrypted (especially PCI or medical data). Passwords must be hashed, not encrypted. Test by querying the database directly and verifying you cannot read the raw data.
Access control
Only authorised users should see personal data. A user should see only their own data, not another user’s. Admins should see only data they’re entitled to (e.g. support staff can see orders, but not internal notes).
Test: Log in as User A. Request User B’s data (by URL parameter or ID). You should get a 403 Forbidden, not User B’s data (IDOR vulnerability).
Audit logging
Every access to sensitive data should be logged: who accessed it, when, and why. This enables breach investigations and regulatory audits.
Test: Query sensitive data and check the audit log. Is it recorded? Does the log include timestamp, user ID, and what data was accessed?
Consent flows
Users must explicitly opt-in to data uses beyond the stated primary purpose (marketing, profiling, third-party sharing). Cookies require consent. Email lists require double-opt-in.
Test: Sign up without checking the marketing consent box. You should not receive marketing emails. Don’t accept cookies. Cookies should not be set.
Data retention and deletion
Personal data must not be kept longer than necessary. Users have a right to deletion. Test that deletion is complete: data is removed from the live database, backups are purged within a reasonable timeframe (e.g. 90 days), and no stale references remain.
Real test scenarios
GDPR: right to access
User requests “send me all my data.” Your system exports: name, email, address, orders, saved preferences, activity log. Format: JSON or CSV. Contains all PII.
Test: Export your own data from a test account. Verify completeness and accuracy.
GDPR: right to deletion
User deletes account. Personal data is removed immediately. Backups expire after 30 days. Support staff cannot see the user’s data anymore.
Test: Delete a test account. Query the database. Data is gone. Check that old emails don’t still reference the user.
NZ Privacy Act: consent for marketing
User signs up without checking “receive marketing emails.” System does not add them to the marketing list. They do not receive promotional emails.
Test: Create an account without consent. Trigger a marketing email campaign. Verify the user is not included.
HIPAA: PHI encryption
Healthcare app stores patient medical history. All data is encrypted AES-256 at rest. API responses are HTTPS. Audit log shows every access.
Test: Query the database. Medical data is unreadable (encrypted). API requests show encrypted payloads in transit. Audit log records each access with timestamp and user.
Tools for compliance testing
- Snyk (free tier) — scans your code and dependencies for security and compliance issues. Flags known vulnerable libraries.
- Qualys — web vulnerability scanner; identifies weak encryption, missing TLS, unpatched systems
- Burp Suite Community (free) — intercept and inspect HTTPS traffic; useful for testing encryption, missing headers, cookie handling
- OWASP ZAP (free) — automated security scanner; tests for common vulnerabilities including data exposure
- SQLMap (free) — tests for SQL injection; if your system is vulnerable, attackers can extract all data without encryption protection
Regulatory audit preparation
When a regulator or auditor requests evidence of compliance, have these documents ready:
- Privacy policy — clear, accurate description of what data you collect and why
- Data processing agreement (DPA) — if you use third-party vendors (cloud storage, payment processors), they must sign a DPA committing to your security standards
- Consent records — proof that users opted in to marketing, cookies, etc. Can be as simple as a timestamp and checkbox state in the database
- Audit logs — records of who accessed personal data, when, and why. Auditors will request these as evidence.
- Incident response plan — what do you do if data is breached? GDPR requires notification within 72 hours.
- Data inventory — what personal data do you hold? Where? How long? Who can access it?
Common compliance failures
- No HTTPS — personal data sent in plaintext; trivial to intercept
- Passwords not hashed — if the database is leaked, passwords are readable
- No audit logging — no way to investigate who accessed what data or when
- IDOR on data access — users can see other users’ data by changing a URL parameter
- No deletion function — users cannot delete their account; violates GDPR and NZ Privacy Act
- Data not purged after deletion — user deleted their account, but data remains in backups indefinitely
- Consent not recorded — user received marketing emails but claims they didn’t opt in; no checkbox record
- Third-party sharing without disclosure — data sold to a broker not mentioned in privacy policy
Tips
Read the privacy policy and compare it to the code. Often the policy says one thing and the system does another. Is data really deleted when the user clicks “delete”? Or is it just marked as inactive?
- Test deletion thoroughly — delete a test account. Query the database, backups, logs, and third-party integrations. Is data gone everywhere or just hidden?
- Check the audit log — every query on personal data should be logged. If there’s no audit log, compliance testing reveals a critical gap.
- Test with a network sniffer — Wireshark or browser DevTools shows what’s actually being transmitted. HTTPS headers, certificate validity, and encryption strength are visible.
- Ask for the data processing agreement — if your company uses cloud storage, payment processors, or analytics services, those vendors must have a DPA. If there isn’t one, that’s a compliance gap.
- Test consent separately — create two test accounts: one with marketing consent, one without. Trigger a marketing email. Verify the system respects the setting.
4 Industry Reality
- Requirements say “be compliant” without specifying how. Most tickets you receive will say “ensure GDPR compliance” or “meet Privacy Act requirements” with no acceptance criteria. Senior testers translate regulations into testable conditions themselves — you build the test plan, not just execute one.
- Deletion is almost always soft-delete in legacy systems. Codebases more than three or four years old typically set a
deleted_attimestamp or flip a status flag and call it done. The actual hard-delete path — backups, third-party sync, audit cascades — either was never built or was deferred. Budget time to find and test the real purge schedule. - Third-party integrations are the biggest gap and the hardest to test. Marketing platforms, analytics tools, CRMs, and payment processors each have their own deletion timelines and APIs. In most projects you will find at least one vendor who has no documented deletion endpoint, or whose contract says they retain data for 90 days regardless. These gaps rarely surface until a complaint is made.
- Legal and engineering disagree on what “deleted” means, and you get caught in the middle. Lawyers want immediate purge. Engineers argue that nightly backup retention for 30 days is fine. The Privacy Commissioner’s guidance says “as soon as reasonably practicable.” Your job is to document what the system actually does, not resolve the policy debate — but you do need to raise it as a risk if no one else has.
- Compliance testing in NZ almost never has a dedicated budget or schedule. At most NZ companies you will run compliance checks alongside functional testing, not as a separate phase. Work it into your regression pack as standing checks so it doesn’t get squeezed out before release.
5 When to Use It — and When Not To
✓ Use it when
- The system collects, stores, or processes personal information about NZ residents (even if the company is offshore)
- You are building or changing account deletion, data export, or consent flows
- The product handles health data, financial records, payment cards, or any data classified as sensitive under the Privacy Act 2020
- A third-party vendor is being integrated who will receive personal data (marketing tool, analytics, CRM)
- A privacy breach, complaint to the Privacy Commissioner, or regulatory audit has occurred and the fix needs verification
✗ Skip it when
- The system handles no personal information whatsoever (a pure internal data-processing pipeline on anonymised data, for example)
- You’re testing an isolated internal tool with no user accounts and no PII — a build-pipeline dashboard, a log aggregator, or a config tool
- Compliance has already been locked down by a specialist privacy engineer this sprint and the scope of your changes doesn’t touch any data-handling paths
- The feature is a pure UI cosmetic change with no backend data flow (icon update, colour scheme, copy-only release)
- You are tempted to replace security testing with compliance testing — they overlap but neither is a substitute for the other; both need to run
Context guide
How the right level of compliance and privacy testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| HealthNZ / CoverNZ / Benefits NZ systems processing health or benefit data | Essential | Health information has the highest sensitivity under the Health Information Privacy Code. Breaches are publicly reportable; CoverNZ and Benefits NZ handle some of NZ’s most vulnerable populations and are frequent targets of Privacy Commissioner complaints. |
| Revenue NZ / Revenue NZ digital services (tax, GST, KiwiSaver) | Essential | Tax file information is protected by the Tax Administration Act and the Privacy Act. Any exposure of Revenue NZ numbers, income data or return details triggers mandatory breach notification and potential criminal liability. |
| Harbour Bank / Pacific Bank / KiwiFirst Bank retail banking or payments | Essential | PCI DSS mandates encryption, audit trails and access control for all card data. NZ banks are also subject to RBNZ prudential standards. A single misconfigured access-control rule exposes millions of accounts. |
| TransitNZ / Pacific Air customer-facing portals (bookings, accounts) | High | High volume of personal data including travel history and payment details. Consent flows for marketing and third-party sharing require explicit testing; IDOR vulnerabilities in booking APIs have historically exposed passenger manifests. |
| Spark / Vodafone / 2degrees telco billing and account management | High | Telecommunications metadata (call records, location) is classified as sensitive. The Telecommunications (Interception Capability and Security) Act adds obligations beyond the Privacy Act. Account-deletion and data-export testing must cover call and location history, not just profile fields. |
| Internal SaaS tools with no user PII (build dashboards, config management) | Low | If the system genuinely holds no personal information and has no user accounts, most Privacy Act obligations do not apply. Confirm with the privacy engineer that scope is truly anonymised before reducing effort. |
Trade-offs
What you gain and what you give up when you choose compliance and privacy testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Catches legal liability before it reaches production — a Privacy Act complaint or Privacy Commissioner investigation costs far more than any test cycle. | Requires access to the database, backups, and third-party integrations that functional testers often don’t have. Getting that access takes time and stakeholder buy-in. | The change genuinely touches no personal data path. Confirm with the privacy engineer rather than assuming — small releases often have hidden data-flow side-effects. |
| Produces artefacts (consent records, deletion evidence, audit log checks) that double as audit-readiness evidence when the Privacy Commissioner or a regulator requests them. | Testing third-party integrations (Salesforce, Mailchimp, Google Analytics) is slow. Many vendors have no documented deletion API, so confirming compliance requires contract review and manual confirmation rather than automated assertion. | The feature is covered by a current, verified DPA and the sprint’s scope does not touch data-handling paths. Even then, keep standing regression assertions running. |
| Builds trust with users and regulators. NZ organisations that proactively demonstrate compliance attract fewer complaints and pass audits faster. | Compliance obligations are defined by regulation, not by a test specification. Testers must translate law into testable conditions themselves — which requires understanding the Privacy Act, not just running a standard test plan. | You are looking for active exploits or injection vulnerabilities. Compliance testing covers legal obligations; use security testing (penetration testing, SAST, DAST) for threat-model coverage. Both must run — neither replaces the other. |
| Forces a complete data-flow inventory. The process of mapping every system that receives personal data frequently surfaces undocumented integrations that no one else had tracked. | Results can be hard to quantify on a test dashboard. A “delete propagates to all third parties within 30 days” check cannot be automated end-to-end and may require manual verification across multiple vendor portals. | A dedicated privacy engineer has already performed a Privacy Impact Assessment and signed off on the specific data flows in scope for this release. Your effort then shifts to verifying the mitigations they specified were implemented. |
Enterprise reality
How compliance and privacy testing changes at 200–300-developer scale — and what NZ enterprise teams actually run into
- At scale, consent-flow and encryption checks move into automated regression pipelines — tools like OneTrust and BigID continuously scan data stores and flag new PII fields, rather than relying on testers manually checking each sprint. KiwiFirst Bank runs automated data-classification sweeps across its core banking platform so that any new field touching account or identity data triggers a compliance workflow before the code can be promoted to production.
- Governance gets formal: large NZ organisations subject to the Privacy Act 2020, NZISM (the NZ Information Security Manual), and PCI DSS maintain a dedicated Privacy Impact Assessment (PIA) process, a Data Protection Officer, and a compliance register that maps every data flow to its legal basis. Testers at this level don't write the PIA — but they are expected to verify that the controls the PIA mandated were actually implemented and are still functioning after each release.
- Tooling at volume looks different: Burp Suite Enterprise (not Community) runs scheduled scans against staging continuously; Snyk is wired into the CI pipeline and blocks builds on critical findings; database activity monitoring tools (IBM Guardium, Imperva) generate the audit trail automatically rather than relying on application-level logging. The manual proxy-and-check approach from smaller teams won't scale across 40 squads releasing independently.
- Cross-team coordination is the hardest part. At 10+ squad scale, a single "Delete account" flow touches squads that own identity, payments, marketing, analytics, and third-party integrations — none of which reports to the same lead. Revenue NZ's enterprise test function handles this with a compliance chapter model: a small group of senior testers owns the compliance test strategy and sits across all squads, reviewing each team's deletion and consent coverage before release rather than letting individual squads self-certify.
◆ What I would do
Professional judgment — when to reach for compliance and privacy testing, when to skip it, and what to watch for.
The bottom line: On any NZ system handling personal information, assume the gap is in the integrations and the deletions — not the UI. Check the database, the backups, and every third party that ever received the data before you sign off. That is the work the Privacy Act 2020 actually requires.
6 Best Practices
- ✓ Read the privacy policy before writing a single test case. Compare what it promises to what the system actually does. The gap between the two is your test plan.
- ✓ Go to the database, not the UI, to verify deletion. SELECT the old record by email or user ID after deleting it through the front end. If it’s still there, the UI is lying.
- ✓ Test the backup and restore path. Ask engineering: if we restored from last night’s backup, would the deleted user’s data come back? If yes, that’s a documented risk until backup retention aligns with your purge schedule.
- ✓ Create two test accounts: one with each consent state. One opts in to marketing, one does not. Trigger a campaign. Confirm only the consented user receives it. This single test catches most consent-flow bugs.
- ✓ Record the consent record at sign-up, not just the checkbox outcome. Check the database timestamp, what was agreed to, and from which IP or device. Without this, you have no evidence to defend a complaint to the Privacy Commissioner.
- ✓ Test IDOR by switching user IDs in API calls. Log in as User A. Change the user ID or account reference in a data-export or profile request to User B’s ID. You must receive a 403, not User B’s data.
- ✓ Verify TLS with DevTools or a proxy, not by checking the padlock. Open the Network tab and confirm requests carrying PII use HTTPS with TLS 1.2+. Look for accidental HTTP fallback on any mixed-content or redirect path.
- ✓ Document every third-party integration and its deletion timeline. For each vendor receiving personal data, confirm in writing: how to trigger deletion, how long they retain data, and whether they’re covered by a Data Processing Agreement. Flag any without a DPA as a compliance gap before release.
- ✓ Add compliance assertions to your regression pack, not just exploratory sessions. Encryption checks, IDOR probes, and consent-state verifications should run on every release so they can’t silently break.
- ✓ Treat a found vulnerability as a Privacy Act mandatory notification candidate. If your test uncovers a defect that could have exposed personal data, escalate immediately. Under the NZ Privacy Act 2020, a notifiable privacy breach must be reported to the Privacy Commissioner as soon as practicable.
7 Common Misconceptions
❌ Myth: HTTPS on all pages means we’re compliant with data-in-transit requirements.
Reality: HTTPS is necessary but not sufficient. You also need a valid, non-expired certificate with TLS 1.2 or higher (TLS 1.0 and 1.1 are deprecated), no HTTP fallback or mixed-content requests, and no sensitive data leaking through query strings that end up in server access logs. A site can serve HTTPS and still transmit passwords or tokens in a URL, which makes them visible in logs and browser history. Check what’s in the request body and headers, not just the protocol prefix.
❌ Myth: The Privacy Act 2020 only applies to NZ-based companies.
Reality: The Privacy Act 2020 applies to any organisation that collects or holds personal information about New Zealand residents, regardless of where the organisation is incorporated or headquartered. An overseas SaaS platform used by NZ customers, or an offshore data processor handling NZ data on behalf of a NZ business, is in scope. As a tester, if your product has NZ users, the Act applies to the data you’re handling — even if your employer is based elsewhere.
❌ Myth: Compliance testing is a one-off activity done before a major release.
Reality: Compliance obligations are continuous. A system that was compliant in January can breach the Privacy Act in March because a developer added a new analytics integration that now shares data with a vendor not covered by a DPA, or because a routine change removed the purge step from the account-deletion flow. Senior testers build standing compliance checks into their regression pack so that each release cycle verifies the critical controls — not just the sprint that delivered the privacy feature originally.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
A tester signs off the “delete my account” feature on a NZ wellbeing app with this single test: “Click Delete. Confirm the profile page returns 404 and the account no longer appears in the app.” Under the Privacy Act 2020, explain why this test is inadequate and list everywhere else you must check that the personal data is actually gone.
Show model answer
Why the single test is inadequate: A 404 and disappearance from the app only proves the record is hidden from one view. The "delete" may just be a status = inactive flag. Under the Privacy Act 2020 the obligation is that personal information is no longer held when there is no lawful reason to keep it — visible absence in the UI does not prove that. Other places you must verify the data is actually gone: 1. Live database — query directly (by old user ID / email) and confirm no personal data remains beyond anything you're legally required to retain. 2. Backups — confirm the data is purged from backups within a defined, reasonable window (and that restoring a backup wouldn't resurrect the person). 3. Logs and audit trails — confirm personal data isn't left sitting in application logs; the audit record of the deletion itself can remain. 4. Third-party integrations — marketing/email lists, analytics tools, payment processor, CRM. Confirm the deletion propagates so no downstream system still holds or acts on the data (e.g. no marketing email referencing old activity). A senior would also confirm support staff can no longer retrieve the record, and that the deletion request and its completion are themselves logged as evidence.
A NZ retailer’s sign-up form is described below. It breaches the Privacy Act’s use-limitation and consent expectations in three ways. Identify each breach and state the fix.
“The marketing-emails checkbox is ticked by default. We collect the customer’s date of birth even though it’s only a courier delivery sign-up. We don’t store whether the customer agreed — we just read the checkbox at send time.”
Identify the breaches and give the fix for each:
Show model answer
Three breaches: 1. Pre-ticked marketing consent — consent must be a positive, informed opt-in, not a default the user has to notice and untick. Fix: leave the checkbox unticked by default; the user must actively opt in. 2. Collecting date of birth for a courier delivery — this breaches collection limitation / data minimisation: only collect personal information you actually need for the stated purpose. Fix: remove the date-of-birth field, or only collect it where there is a genuine, disclosed need (and say why in the privacy notice). 3. No stored consent record — reading the checkbox "at send time" means there's no evidence of what the customer agreed to, and the state can change. Fix: record consent at the moment it's given — timestamp, what was consented to, and the checkbox state — so you can prove it later and honour withdrawal. A senior would add: test withdrawal of consent actually stops the emails, and that the privacy notice matches what the form collects and does.
Under the Privacy Act 2020, an individual can request access to the personal information an organisation holds about them. A NZ insurer is building a “Download my data” feature. Design a test set covering completeness, accuracy, format, access control, and the response timeframe. For each test, give the setup and the expected result.
Show model answer
Right-of-access test set (Privacy Act 2020): 1. Completeness — Setup: from a test account with policies, claims, payments, preferences and an activity history, request the data export. Expected: the export includes ALL personal information held — not just the profile, but claims, correspondence, notes about the person, and any data held in linked systems. 2. Accuracy — Setup: compare exported values against the live records. Expected: names, dates, amounts and statuses match exactly; nothing is stale, truncated, or mis-mapped. 3. Usable format — Setup: open the exported file. Expected: it's in a readable, structured format (e.g. JSON/CSV/PDF), not corrupted, and a non-technical person could understand what they've received. 4. Access control — Setup: as User A, attempt to request or download User B's data (e.g. by changing an ID in the request). Expected: 403 Forbidden / rejected; a user can only ever access their own information (no IDOR). 5. Response timeframe — Setup: lodge an access request and track the workflow. Expected: the request is logged and fulfilled within the statutory timeframe (the Privacy Act requires a response without undue delay — generally within 20 working days), with the deadline tracked rather than open-ended. A senior would also confirm the request itself is logged for audit, and that withheld information (where a lawful ground to withhold applies) is handled and recorded correctly.
Why teams fail here
- Testing the UI instead of the data: the delete button returning a 200 OK is not evidence that personal information has been removed from the database, backups, logs, or third-party systems.
- No third-party data inventory: teams verify the application they own but never confirm whether Salesforce, Mailchimp, Google Analytics, or the payment processor still holds the deleted user's data — because nobody mapped those flows before testing started.
- Treating compliance as a one-sprint activity: a system that was compliant in Q1 can silently breach the NZ Privacy Act 2020 in Q3 when a developer adds an analytics tag that starts sending user IDs to an undisclosed vendor — with no compliance check in the regression pack to catch it.
- Confusing "secure" with "compliant": passing a penetration test does not prove the system honours collection limitation, retains consent records, or provides a complete right-of-access export — those are legal obligations that exist regardless of whether there is an attacker.
Key takeaway
Compliance testing is not about what the screen shows — it is about verifying what the system actually does with personal data at every layer: the database, the backups, the logs, and every third-party integration the data touched.
How this has changed
The field moved. Here is how Compliance and Privacy Testing evolved from its origins to current practice.
Privacy in software is primarily a physical security concern — who has access to the building and the filing cabinet. Software privacy testing as a discipline does not exist. Data protection is a legal and HR concern, not a QA concern.
NZ Privacy Act 1993 is a decade old but has minimal impact on software development practice. HIPAA in the US (1996) begins requiring technical safeguards for health data, creating the first systematic privacy testing requirements.
GDPR comes into force (May 2018) — the most significant privacy regulation globally. Fines up to 4% of global revenue create board-level attention. Privacy testing moves from advisory to mandatory in organisations processing EU personal data. Privacy by design becomes a development requirement.
NZ Privacy Act 2020 replaces the 1993 Act with stricter obligations — mandatory breach notification, stronger individual rights, international data transfer restrictions. NZ organisations begin building privacy testing into their QA practice.
Privacy testing is a standard component of any NZ software release that handles personal information. Automated tools scan for PII exposure in logs, APIs, and test data. AI systems introduce new privacy considerations — training data provenance, output inference attacks, and model inversion — requiring new testing approaches.
Interview Questions
What NZ hiring managers ask about Compliance and Privacy Testing — and what strong answers look like.
Under the NZ Privacy Act 2020, what test cases would you write for a new user registration form?
Strong answer: I would test: (1) Purpose notification — does the form clearly state why each piece of information is collected (Information Privacy Principle 3)? (2) Minimal collection — is the form requesting only information necessary for the stated purpose (IPP 1)? (3) Individual access — can a registered user view all the personal information held about them (IPP 6)? (4) Correction — can users correct inaccurate information (IPP 7)? (5) Security — is the information stored securely (IPP 5) — I would check that passwords are hashed, that personal data is not exposed in URLs or logs, and that the form uses HTTPS.
Junior/Mid
A developer says the privacy impact assessment is done and approved — no privacy testing needed. How do you respond?
Strong answer: A privacy impact assessment (PIA) identifies privacy risks and proposes mitigations — it does not verify that the mitigations were implemented correctly. Testing is what verifies implementation. I would ask to see the PIA and test each mitigation: if the PIA says personal data is masked in logs, I test that logs do not contain NHI numbers, Revenue NZ numbers, or email addresses. If it says data is encrypted at rest, I verify the encryption configuration. The PIA is the design; testing is the verification that the design was built correctly.
Mid/Senior
What is the difference between data masking and data anonymisation for test data, and why does it matter for NZ Privacy Act compliance?
Strong answer: Data masking replaces sensitive values with realistic-looking fake values that preserve format — masking an Revenue NZ number to a different valid-format number. The masked data can be reverse-engineered if the masking algorithm is known. Anonymisation makes it impossible to re-identify individuals — not just replacing values but removing enough combinations to prevent linkage attacks. Under the NZ Privacy Act 2020, anonymised data is not personal information and has no obligations. Masked data that could re-identify individuals is still personal information. For test environments that multiple people access, anonymisation is the safer choice.
Senior/Lead
Self-Check
Click each question to reveal the answer.
Q1: Why isn’t “the delete button removes the account from the app” enough to prove compliant deletion?
Because disappearing from the UI only proves the record is hidden — it may just be a status flag. Compliant deletion means the personal data is genuinely no longer held: removed from the live database, purged from backups within a reasonable window, not lingering in logs, and propagated to every third party it was shared with. You have to verify all of those, not the screen.
Q2: What is an IDOR and why is it both a security and a privacy failure?
An Insecure Direct Object Reference lets a user reach another user’s data by changing an identifier (e.g. a URL parameter or ID) instead of being blocked. It’s a security bug (broken access control) and a privacy breach (one person can see another’s personal information). Test it by logging in as User A and trying to request User B’s data — you should get a 403, not the data.
Q3: Under the Privacy Act 2020, what does “collection limitation” mean for testers?
An organisation should only collect personal information it actually needs for a stated, disclosed purpose. As a tester you check the form against the privacy notice: is it collecting fields it has no need for (e.g. date of birth for a simple delivery sign-up)? Collecting “just in case” data with no stated purpose is a compliance gap.
Q4: Why must consent be recorded, not just read at the moment an email is sent?
Because you need evidence of what the individual actually agreed to and when. Recording the consent — timestamp, what was consented to, and the checkbox state — lets you prove compliance if challenged and lets you honour a later withdrawal. Reading a live checkbox at send time leaves no audit trail and no proof.
Q5: What does the Privacy Act 2020’s mandatory breach-notification duty mean for how you treat a vulnerability found in testing?
If a privacy breach is likely to cause serious harm, the organisation must notify the Privacy Commissioner and affected individuals as soon as practicable. So a vulnerability that could expose personal information is a high-priority defect: track it clearly (what data, under what conditions, what harm), get it fixed, and verify the fix before release rather than treating it as a minor bug.
Q6: Your team is testing a new “Download my information” feature on an Benefits NZ portal that serves beneficiaries. A tester says the export file looks complete because the profile page shows all fields. What is missing from that assessment and what would you do instead?
Looking at the profile page only confirms what Benefits NZ chose to display, not what it actually holds. For a right-of-access request under the Privacy Act 2020 you must verify completeness against the underlying data: query the database directly and list every table that contains personal information for that user (case notes, payment history, correspondence, linked third-party systems). Compare the exported file field-by-field against that inventory. You would also check the format is readable by a layperson, confirm the request was logged with a timestamp, and verify the response is sent within 20 working days — statutory rights, not just a UX feature.
Q7: What is the key difference between compliance & privacy testing and security testing, and why can neither replace the other?
Security testing asks whether an attacker can compromise the system — its focus is on threats, vulnerabilities, and defence. Privacy testing asks whether the system handles personal data in accordance with legal obligations regardless of any attacker — things like collection limitation, consent, access rights, and deletion. They overlap (encryption and access control appear in both), but a system can be secure and still breach the Privacy Act (e.g. no deletion path, no consent record, excess data collection). Conversely, a system can satisfy every Privacy Act obligation and still have an exploitable SQL injection. Both must run.
Q8: A developer tells you “we use HTTPS everywhere so we’re covered for data-in-transit compliance.” What is wrong with this and how do you respond?
HTTPS is necessary but not sufficient. You still need to verify: the certificate is valid and uses TLS 1.2 or higher (TLS 1.0/1.1 are deprecated and non-compliant); there is no HTTP fallback or mixed-content path where personal data could leak in plaintext; and sensitive data is not being passed in query strings, which end up in server access logs and browser history even over HTTPS. Use DevTools or a proxy like Burp Suite to inspect actual requests carrying PII — check the protocol version, look for any accidental redirect to HTTP, and confirm passwords or tokens appear in the request body, not the URL. The padlock icon alone is not a compliance test result.
Q9: When should you NOT run compliance and privacy testing, and what is the risk of skipping it on a feature you assume is low-risk?
Skip it only when the change genuinely touches no personal information path: a pure UI cosmetic release (colour or copy only), an isolated internal tool with no user accounts or PII, or anonymised data pipelines where the privacy engineer has confirmed no personal information is in scope. The risk of assuming a feature is low-risk without checking is that small changes often have hidden data-handling implications — a new analytics tag added during a “cosmetic” release can start sending user IDs to an undisclosed third party, creating a use-limitation breach under the Privacy Act 2020. In NZ government contexts (Revenue NZ, CoverNZ, TransitNZ) the consequences of missed compliance obligations include Privacy Commissioner complaints and public reporting, so the bar for confidence must be high before skipping.
Related techniques
Related: See Security Testing for encryption and access control details, and Accessibility Testing for handling user rights to access data.
The Privacy Testing (Specialised) track goes further: multi-lesson deep-dive with NZ-specific compliance context, advanced tooling, and practice exercises. Recommended once you have the fundamentals on this page.