GDPR Compliance Helper

/gdpr-data-handling

Practical GDPR implementation guidance: choosing lawful bases, building compliant consent, handling data subject requests on deadline, retention schedules, breach notification, and privacy-by-design data architecture.

Usage

/gdpr-data-handling $ARGUMENTS

Note: this is implementation guidance, not legal advice; confirm decisions with your DPO or counsel.

What I Need From You

Describe what data you process, about whom, why, and where it flows (vendors, regions). Paste your privacy policy, data inventory, or the specific request/incident you are handling.

Data Categories and Protection Levels

Lawful Bases (Art. 6)

Consent (freely given, specific, informed), contract necessity, legal obligation, vital interests, public interest, legitimate interest (requires a documented balancing test). Pick and document exactly one basis per processing purpose; changing basis later is painful.

Consent Done Right

• Opt-in only: no pre-checked boxes, no consent bundled across purposes.
• Separate toggles per purpose (necessary/always-on, analytics, marketing) with equal-prominence Accept All and Reject All.
• Record proof per consent event: purpose, granted/withdrawn, timestamp, source, privacy policy version, and an audit log of changes. Withdrawal must be as easy as granting and must propagate to downstream systems.

Data Subject Rights (respond within 1 month)

Access (Art. 15), rectification (16), erasure (17), restriction (18), portability (20), objection (21). A complex request can be extended up to 2 further months with notice.

DSAR workflow: verify identity, log the request with a 30-day deadline, collect data from every store (production DB, analytics, support tooling, backups policy, vendors), then respond with: the data by category, processing purposes, retention periods, and third-party recipients. For erasure, check legal exceptions first (e.g. tax records) and tell the requester what was deleted vs retained and why. For portability, export in a structured machine-readable format such as JSON.

Retention Schedule

Define per data type: retention period, lawful basis, trigger date, and disposal method (delete, archive-then-delete, or anonymize). Typical anchors: transaction records ~7 years (tax law), user accounts ~3 years after last activity, marketing consent ~2 years, analytics ~1 year (anonymize instead of delete where useful). Enforce on a schedule and log each enforcement run.

Breach Notification

• Notify the supervisory authority within 72 hours when the breach risks individuals' rights -- always for health, financial, credential, or biometric data.
• Notify affected individuals when risk is high.
• The authority report needs: nature of the breach, data categories and approximate numbers affected, likely consequences, measures taken and proposed, DPO contact, and a timeline. Keep an internal breach register even for non-reportable incidents.

Privacy by Design

• Minimize: collect only fields required for the stated purpose.
• Separate: keep PII apart from behavioral data; encrypt PII at rest and in transit; use non-sequential IDs and hashed lookups.
• Pseudonymize analytics (rotating pseudonyms, country-level location, generalized device info).
• Access control on need-to-know basis with audit logging.

Compliance Checklist

• Documented lawful basis per processing activity; LIAs completed
• Clear privacy policy with purposes and retention periods
• Access, erasure, rectification, and portability processes that hit the 30-day deadline
• Encryption at rest and in transit; access controls; audit logs
• 72-hour breach process and breach register
• Records of processing activities (Art. 30), DPIAs where required, DPAs with vendors, SCCs or adequacy for transfers

Output

Depending on the ask: a lawful-basis map, a consent flow spec, a step-by-step DSAR response plan with deadline dates, a retention schedule table, or a gap analysis against the checklist above.