Compliance Review

Compliance Review

Purpose

Assess proposed features and data flows against applicable privacy regulations, identify compliance gaps, and produce actionable remediation plans.

Scope Constraints

Reads feature proposals, data flow descriptions, consent flows, and regulatory requirements for compliance analysis. Does not implement fixes, modify application code, or access production data stores.

Inputs

• Feature description or proposal being analyzed
• Data elements collected, processed, or stored
• User-facing consent flows and privacy notices
• Third-party integrations and data sharing arrangements
• Target jurisdictions and applicable regulations

Input Sanitization

No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.

Procedure

Progress Checklist

• Step 1: Identify applicable regulations
• Step 2: Map data flows for PII
• Step 3: Assess consent mechanisms
• Step 4: Evaluate data retention policies
• Step 5: Check right-to-deletion compliance
• Step 6: Design audit trail requirements

Step 1: Identify Applicable Regulations

Determine which regulatory frameworks apply based on user base, data types, and jurisdictions. Map each regulation to its key obligations:

• GDPR (EU/EEA): Lawful basis, consent, right to access/erasure/portability, DPIAs, breach notification
• CCPA/CPRA (California): Right to know, right to delete, right to opt-out, data sale restrictions
• HIPAA (US health): PHI safeguards, minimum necessary standard, BAAs
• SOC2: Security, availability, processing integrity, confidentiality, privacy trust principles
• PCI-DSS: Cardholder data protection, network segmentation, access controls

Step 2: Map Data Flows for PII

Trace every data element through its lifecycle. For each element, document:

• Collection point: Where and how is it gathered? (form, API, third-party sync)
• Lawful basis: What legal ground justifies processing? (consent, contract, legitimate interest)
• Storage location: Where does it live? (database, cache, logs, backups, third-party)
• Processing purposes: What is it used for? (core feature, analytics, marketing, ML training)
• Sharing: Who else receives it? (sub-processors, analytics vendors, ad networks)
• Retention: How long is it kept? (active use, archival, legal hold)

Step 3: Assess Consent Mechanisms

Evaluate whether consent collection meets regulatory standards:

• Is consent freely given, specific, informed, and unambiguous?
• Are consent purposes granular (not bundled)?
• Can users withdraw consent as easily as they gave it?
• Is consent recorded with timestamp, version, and scope?
• Are pre-checked boxes or dark patterns avoided?
• Is there a mechanism for parental consent if minors are in scope?

Step 4: Evaluate Data Retention Policies

For each data category, assess:

• Is there a defined retention period with documented justification?
• Does the retention period align with the lawful basis? (consent-based data must be deletable)
• Are automated deletion/anonymization processes in place?
• Do backups respect retention limits, or do they create shadow copies?
• Are legal hold requirements accounted for without overriding general deletion?

Step 5: Check Right-to-Deletion Compliance

Verify that data subject rights are technically implementable:

• Can all PII for a given user be located across all systems?
• Does deletion cascade to backups, caches, logs, and third-party systems?
• Is soft-delete distinguished from hard-delete, and is hard-delete available?
• Can deletion be completed within regulatory timeframes (e.g., 30 days for GDPR)?
• Are there documented exceptions (legal obligations, legitimate interest overrides)?

Step 6: Design Audit Trail Requirements

Specify what must be logged for compliance evidence:

• Consent events (granted, modified, withdrawn) with full context
• Data access events (who accessed what PII, when, for what purpose)
• Deletion/anonymization events (request received, processing, confirmation)
• Breach-related events (detection, assessment, notification timeline)
• Policy changes (consent text updates, retention policy modifications)

Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.

Output Format

Regulatory Applicability Matrix

Data Flow Map

[User] → [Collection Point] → [Processing Service] → [Data Store]
                                      ↓
                              [Third-Party / Sub-processor]

PII Elements: [list]
Lawful Basis: [basis per element]
Retention: [period per element]

Compliance Gap Analysis

Severity Key

• Mandatory: Regulatory requirement — must fix before launch or risk enforcement action
• Strongly Recommended: Best practice that significantly reduces risk — fix in current sprint
• Advisory: Improvement that strengthens posture — schedule for next iteration

Handoff

• Hand off audit logging requirements to audit-trail-design for detailed event catalog and schema design.
• Hand off data sensitivity tiering to data-classification if PII elements need formal classification and handling requirements.

Quality Checks

• All applicable regulations are identified with specific articles/sections referenced
• Every PII element has a documented lawful basis for processing
• Consent mechanisms meet the "freely given, specific, informed, unambiguous" standard
• Data retention periods are defined and justified for every data category
• Right-to-deletion path covers all storage locations including backups and caches
• Third-party data sharing is documented with DPA/contractual coverage
• Audit trail requirements cover consent, access, deletion, and breach events
• Gap analysis includes specific, actionable remediation for every finding

Evolution Notes