gdpr-test-patterns
Reference catalog of GDPR-aligned test patterns - data-subject-rights workflows (Art. 15 access, Art. 16 rectification, Art. 17 erasure / "right to be forgotten", Art. 18 restriction, Art. 20 portability, Art. 21 objection); consent recording + revocation per Art. 7; data-residency assertions per Art. 44 - 50 international transfers; breach-notification timing tests per Art. 33 (72 hours); data-minimization assertions in fixtures per Art. 5(1)(c). Use when authoring GDPR-readiness tests for any product processing EU personal data.
Install with skills.sh (any agent)
npx skills add testland/qa --skill gdpr-test-patternsgdpr-test-patterns
Overview
Per gdpr.eu (opens in new window) (community-maintained reference; canonical text at eur-lex.europa.eu Regulation 2016/679):
GDPR (General Data Protection Regulation, in force 2018-05-25) applies to any processing of EU personal data regardless of the processor's location. Failure to demonstrate compliance carries fines up to €20M or 4% of global annual turnover (whichever higher).
This is a reference skill - defines the test-pattern catalog by Article. Tests use the team's existing test framework; this skill is the per-Article test recipe.
When to use
How to use
Test patterns by GDPR Article
Art. 7 - Conditions for consent
def test_consent_recorded_at_collection_time():
response = client.post('/signup', json={
'email': 'alice@example.com',
'consent_marketing': True,
'consent_timestamp': '2026-05-06T12:00:00Z',
})
user = User.objects.get(email='alice@example.com')
consent = ConsentRecord.objects.get(user=user, scope='marketing')
assert consent.granted is True
assert consent.granted_at is not None
assert consent.granted_via == 'signup-form' # auditable evidence
def test_consent_revocable():
revoke_consent(user, scope='marketing')
consent = ConsentRecord.objects.get(user=user, scope='marketing')
assert consent.granted is False
assert consent.revoked_at is not None
# Subsequent marketing emails must not be sent:
assert not user.is_eligible_for(EmailType.MARKETING)Art. 15 - Right of access
def test_subject_access_request_returns_all_personal_data():
response = authenticated_client.post('/sar', json={'subject_email': 'alice@example.com'})
assert response.status_code == 200
data = response.json()
# Must include data from EVERY system that holds PII for this subject:
assert 'profile' in data
assert 'billing' in data
assert 'support_tickets' in data
assert 'analytics' in data # often forgotten; tests catch it
assert 'third_party_sharing' in data
# Response must arrive within 1 month per Art. 12(3):
assert response.headers['X-Processing-Time'] < timedelta(days=30)Art. 17 - Right to erasure ("right to be forgotten")
def test_erasure_removes_all_personal_data():
erase_subject('alice@example.com')
# Across ALL systems:
assert User.objects.filter(email='alice@example.com').count() == 0
assert BillingRecord.objects.filter(user_email='alice@example.com').count() == 0
assert AnalyticsEvent.objects.filter(user_email='alice@example.com').count() == 0
# Backup retention: erasure marker recorded; backup expires within retention window
assert ErasureMarker.objects.filter(subject='alice@example.com').exists()Art. 20 - Right to data portability
def test_data_portability_export_machine_readable():
response = client.post('/data-export', json={'subject': 'alice@example.com'})
export = response.json()
# Must be in "structured, commonly used and machine-readable format"
assert response.headers['Content-Type'] in ['application/json', 'text/csv', 'application/xml']
# Format must be self-describing (keys not random IDs):
assert 'profile' in export
assert 'orders' in exportArt. 33 - Breach notification (72-hour test)
def test_breach_notification_workflow_within_72h():
# Simulate a breach detection event
breach = BreachIncident.create(detected_at=timezone.now())
# Workflow MUST notify supervisory authority within 72 hours:
deadline = breach.detected_at + timedelta(hours=72)
notification = BreachNotification.objects.filter(incident=breach).first()
assert notification is not None
assert notification.sent_at <= deadline
assert notification.recipient == 'supervisory.authority@dpa.example.eu'Art. 44 - 50 - International transfers (data residency)
def test_eu_user_data_stored_in_eu_region():
user = User.objects.create(email='alice@example.fr', region='EU')
# Storage assertions vary by infra (AWS region, GCP region, etc.):
assert user.storage_region in ['eu-west-1', 'eu-central-1', 'eu-north-1']
# Cross-region replication MUST stay in EU:
backups = Backup.objects.filter(user=user)
for b in backups:
assert b.region in EU_REGIONSArt. 5(1)(c) - Data minimization
def test_signup_fixtures_contain_only_required_pii():
fixture = load_fixture('user_signup.json')
required = {'email', 'consent_terms', 'consent_marketing'}
optional = {'phone', 'city', 'date_of_birth'}
for k in fixture.keys():
assert k in required | optional, f"Unrecognized field: {k}"
# No SSN, no passport number, no genetic / biometric data unless explicitly justified:
forbidden = {'ssn', 'passport', 'genetic_data', 'biometric_data'}
for k in forbidden:
assert k not in fixture, f"Forbidden PII type: {k}"Worked example
A support agent triggers an Art. 17 erasure for alice@example.com. The team already has test_erasure_removes_all_personal_data (above), which asserted the app User table was empty and passed. Running the multi-system version reveals AnalyticsEvent still holds rows keyed by user_email, because analytics writes were never wired into the erasure job. The test fails on AnalyticsEvent.objects.filter(...).count() == 0. The team adds analytics to the erasure fan-out, re-runs, and the test goes green with an ErasureMarker recorded so the nightly backup expiry honors the request within the retention window.
Key compliance gaps tests should catch
| Gap | Detection |
|---|---|
| Marketing emails sent to revoked-consent users | Step Art. 7 + email-flow tests |
| SAR returns incomplete dataset (missing analytics/CRM) | Step Art. 15 multi-system assertion |
| Erasure leaves data in unindexed backup tables | Step Art. 17 multi-system assertion |
| EU user data quietly replicated to US region | Step Art. 44 - 50 region assertion |
| Breach detected but DPO not notified within 72h | Step Art. 33 timing test |
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Test only main-app data store on SAR/erasure | Misses analytics, CRM, support, backups | Multi-system assertion (Steps Art. 15 + 17) |
| Hardcode 30-day SAR window assumption | GDPR allows extension to 3 months in complex cases | Test timeline against actual policy doc |
| Test consent recording without revocation | Half the workflow uncovered | Both grant + revoke tests (Step Art. 7) |
| Fixture data uses real customer PII | GDPR violation in tests themselves | Use synthetic-pii-generator |
| Skip data-minimization assertions | New PII types creep in via schema changes | Step Art. 5(1)(c) field-allowlist test |
Limitations
References
Related skills
audit-trail-test-author
Build-an-X for audit-log tests across compliance frameworks - required-events catalog (auth events / privilege change / data access / admin action / config change / export / impersonation); structured-log-format assertions per OWASP A09:2021; tamper-evident chain (hash-chain + signed-batch patterns) for HIPAA §164.312(b) + PCI Req 10 + SOC 2 CC7.3; immutability + retention per framework; query-replay tests for forensic reconstruction. Use when authoring audit log tests for any compliance framework (HIPAA / PCI / SOC 2 / GDPR / etc.).
ccpa-test-patterns
Reference catalog of CCPA + CPRA-aligned test patterns - do-not-sell-or-share opt-out via Global Privacy Control (GPC) signal; data-disclosure category tests per Cal. Civ. Code §1798.110; sensitive personal information (SPI) handling per CPRA §1798.121; deletion-request workflows per §1798.105; CPRA's right to correct (§1798.106) + limit-use (§1798.121). Use when authoring CCPA/CPRA-readiness tests for any product processing California consumer data.
compliance-coverage-scoring
Scores existing tests and evidence against a named compliance framework's criteria list (GDPR, CCPA/CPRA, SOC 2 Trust Services Criteria, HIPAA Security Rule, PCI DSS, ISO/IEC 27001), marking every criterion met, partial, not met, or not applicable with a stated evidence requirement per state, and recording each scope exclusion with its criterion reference, reason, named approver, and re-review date. Produces a readiness self-assessment only: not certification, not an audit opinion, not legal advice. Use when a framework version has been named and an evidence set already exists, and someone needs a per-criterion readiness score before an observation period opens, before a qualified assessor arrives, or in response to a regulator inquiry.
compliance-evidence-generator
Build-an-X workflow that produces auditor-facing evidence packages from automated test results: maps control IDs to test outcomes across any compliance framework (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP); generates the control-evidence matrix, timestamped evidence bundles (screenshots, log excerpts, CI exports), and chain-of-custody notes per NIST SP 800-72. Distinct from soc2-evidence-collector (SOC2-only raw log harvest) and from read-only coverage gap analysis that produces no artifacts. Use when an audit engagement requires auditor-ready evidence packages built from existing automated test output.
hipaa-test-patterns
Reference catalog of HIPAA Security Rule-aligned test patterns - administrative safeguards (45 CFR §164.308: workforce training, access management, contingency planning), physical safeguards (§164.310: facility access, workstation security, device disposal), technical safeguards (§164.312: access control, audit logs, integrity, transmission security); PHI handling assertions in fixtures; minimum-necessary tests per §164.502(b); BAA-scope boundary verification. Use when authoring HIPAA-readiness tests for any product handling Protected Health Information.
iso27001-test-patterns
Reference catalog of ISO/IEC 27001:2022 Annex A test patterns: testable technical controls with code-level assertions for access control (A.8.2-A.8.5), logging and monitoring (A.8.15-A.8.16), cryptography (A.8.24), and secure development (A.8.25-A.8.31), plus evidence patterns for Stage 1 and Stage 2 certification audits and Statement of Applicability scoping. The full 93-control Annex A index (four themes: organizational A.5, people A.6, physical A.7, technological A.8) and the exhaustive per-control test code live in references/. Use when authoring ISMS test coverage for an ISO 27001:2022 certification engagement or gap assessment.
pci-dss-control-test-author
Build-an-X for PCI DSS v4.0 scope verification - cardholder data environment (CDE) boundary tests, segmentation tests (PCI Req 1), prohibited-data-storage assertions per Req 3 (no full track data, no CVV/CAV2/CVC2/CID, no PIN/PIN block post-authorization), key-management tests per Req 3.6, encryption-of-transmissions per Req 4. Use when authoring PCI DSS scope-reduction + control tests for any system handling payment-card data.
soc2-evidence-collector
Build-an-X for SOC 2 Type II evidence collection - per-Trust-Services-Criterion test artifacts (Common Criteria CC1.1 - CC9.2; plus Availability A1, Confidentiality C1, Processing Integrity PI1, Privacy P1 - P9 if in scope); auto-collection from CI logs + audit trails + access logs + change-management records; alignment with Vanta / Drata / Secureframe evidence shapes; observation-period sampling. Use when the team is preparing for SOC 2 Type II audit and needs continuous evidence collection automation.