Compliance & Privacy Testing

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.

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

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

• 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.