Download the PHP package graystackit/laravel-gdpr-compliance without Composer

Laravel GDPR Compliance

A comprehensive GDPR/DSGVO compliance toolkit for Laravel applications. Declare personal data on your Eloquent models, manage consent, export subject data, schedule erasure with grace periods and legal hold, and maintain a tamper-evident audit trail — all through a fluent PHP API.

Features

• Fluent personal data declaration on any Eloquent model via a builder DSL
• Registry-driven processing — one config array lists all PII-holding models; no relation graph to maintain
• Subject data export (DSGVO Art. 15) as a structured JSON file, dispatched as a queue job
• Subject data erasure (DSGVO Art. 17) with configurable grace period, three retention modes (delete, anonymize, legal_hold), and deterministic processing order for FK safety
• Per-purpose consent management — append-only consents table, cookie consent helper, middleware
• Policy version tracking with subject acceptance records
• Event-driven audit log (gdpr_audits) that never stores PII values — only field names, event names, and metadata
• 7 built-in anonymizers (name, email, phone, IP address, address, free text, static text) with custom alias support
• Package inventory scanner that reads composer.lock + package-lock.json and writes a JSON snapshot
• 4 Laravel Notifications for deletion requested/cancelled/completed and export ready — overridable via config
• 3 middleware for consent-gated routes, cookie propagation, and deletion-pending auth blocking
• 8 Artisan commands for daily operations, reporting, pruning, and inventory scanning
• 3 queue jobs for async export, deletion processing, and legal hold cleanup

Requirements

• PHP 8.3+
• Laravel 11, 12, or 13

Installation

Publish the config and migrations:

Optionally publish translations for customization:

Quick Start

1. Declare personal data on your models

Every model that holds personal data implements PersonalData and uses one or more GDPR traits:

Related models (that are NOT subjects) use HasPersonalData and define a scope:

2. Register models in config

In config/gdpr.php, list every model that contains personal data:

3. Use the API

Trait Reference

Per-Field DSL

Both behaviors are opt-in per field:

Built-in anonymizer aliases

Register custom anonymizers in config/gdpr.php:

Your class must implement GraystackIt\Gdpr\Contracts\Anonymizer.

Retention Modes

Configured per model via ->retention():

Processing order

->processOrder(int) controls the sequence when multiple models are processed for the same subject. Lower numbers go first. Convention:

This prevents FK constraint violations when children reference the subject with NOT NULL foreign keys.

Deletion Lifecycle

During the grace period, nothing is modified on host model rows. The entire grace state lives in the gdpr_deletions table. This means:

• Cancellation is trivial — just flip the state
• The package never forces SoftDeletes on your models
• Auth behavior during grace is your app's decision (see below)

Auth during grace

The package does not lock users out during grace. Use these helpers to implement your preferred UX:

Consent Management

Database consent (authenticated users)

The consents table is append-only. Each grant and withdraw is a new row. The current state is the latest row per (subject, purpose).

ConsentPurpose::Necessary always returns true without any database check.

Cookie consent (anonymous visitors)

The ConsentCookieManager reads/writes a JSON cookie (gdpr_consent) with per-purpose booleans:

Consent middleware

Audit Log

The gdpr_audits table records deletion/export pipeline events only. It never stores:

• Field values (only field names)
• Raw user agents or full IP addresses
• Consent grants/withdrawals (those live in consents)
• Policy acceptances (those live in gdpr_policy_acceptances)

After a subject is hard-deleted, their audit entries survive as orphans — the subject_id FK points nowhere, which means no re-identification is possible. This is by design.

Logged events: deletion_requested, deletion_scheduled, deletion_cancelled, anonymization_completed, deletion_completed, legal_hold_started, legal_hold_expired, export_requested, export_completed.

Events

The package fires these events for external system integration (e.g., deleting Stripe customers, removing Mailchimp subscribers):

Notifications

Four mail notifications are sent automatically (when config('gdpr.notifications.enabled') is true):

The recipient email is snapshotted into gdpr_requests.notification_email at request time, so notifications work even after the subject's data has been anonymized or deleted. After the final notification, the email is wiped.

Customizing notifications

Text only: publish translations with php artisan vendor:publish --tag=gdpr-lang and edit lang/vendor/gdpr/en/gdpr.php.

Deep customization: override the class in config/gdpr.php:

Artisan Commands

Scheduling

Add to your routes/console.php or scheduler:

Package inventory

Wire the scanner into your host app's composer.json:

Access the inventory programmatically:

Pruning & Retention

The gdpr:prune command handles time-based cleanup:

Configure in config/gdpr.php:

Database Tables

GDPR Compliance Notes

Anonymization vs. pseudonymization

The anonymize mode replaces personal field values with non-identifying placeholders. Whether the result qualifies as true anonymization (GDPR no longer applies) or pseudonymization (GDPR still applies) depends on which fields you configure.

To achieve proper anonymization, ensure you mark all identifying fields — including quasi-identifiers:

• Birthdate + ZIP + gender can uniquely identify 87% of the US population (Sweeney 2000)
• Behavioral patterns in related tables (order timestamps, login times) may re-identify subjects
• External datasets can be joined to remaining data points

The package gives you the tooling. Field selection is your responsibility.

Grace period

• Default 0 days (immediate processing). Opt in per model.
• Hard cap at 30 days (DSGVO Art. 12(3): "without undue delay, in any event within one month").
• During grace, no host model data is modified — cancellation is a clean rollback.

Legal hold

• Enabled via RetentionMode::LegalHold with legalHoldDays.
• The legalBasis field is optional but recommended — the audit log records it for compliance evidence.
• After hold_until expires, the row is mandatorily force-deleted by the cron command.

Backups

The package cannot reach into backup files. If you restore from a backup, pending deletion requests should be re-applied. Document your backup retention in your privacy policy and ensure backups rotate within a documented window.

Subject-to-subject references

When processing Subject A, the package never modifies Subject B — even if B has a foreign key to A. Use onDelete('set null') on FK migrations or listen to the PersonalDataErased event to handle cross-subject cleanup in your app code.

Publishing Reference

Testing

License

The MIT License (MIT). See LICENSE for details.