Gdpr Bundle Laravel Package

Product Decisions This Supports

• DSAR (Data Subject Access Request) handling — the package's export capability maps directly to GDPR Article 15 (right of access) and Article 20 (data portability). This is the single most defensible reason to evaluate it: it turns "we need an export endpoint" from a bespoke project into a configuration-and-annotation exercise.
• Right to erasure (Article 17) — the anonymization layer lets you decide, per entity and per field, whether a record is hard-deleted, scrubbed, or retained for legal/billing obligations. That per-field granularity is the product decision companies usually get wrong and then have to retrofit under legal pressure.
• Entity-level data classification — annotations force an explicit inventory of "where does personal data actually live." This is the artifact most teams lack when a DPO or auditor asks. Even if you never adopt the package, its annotation pattern is a useful spec for your own schema review.
• Build vs. buy (really: build vs. borrow) — MIT-licensed, so the realistic play is vendoring the annotation-reading and anonymization logic rather than taking a runtime dependency. Treat it as a reference implementation and a 1–2 week head start, not a library you install and forget.
• Roadmap sequencing — a compliance self-serve tool (export/anonymize on request) is a credible Q3 deliverable for a regulated B2B SaaS. It de-risks enterprise procurement questionnaires and unblocks deals that stall on "send us your GDPR posture."
• Use cases where it fits — internal admin tooling, back-office CRUD apps, and multi-tenant SaaS with a manageable number of personal-data-bearing entities (tens, not hundreds). Poor fit for event-sourced or heavily denormalized schemas.

When to Consider This Package

Consider it when:

• Your stack is Symfony (Symfony 4/5-era, given the 2020 last release). Note the brief frames this as Laravel/PHP — it is not a Laravel package. There is no service provider, no config publish, no Eloquent integration. Do not plan a Laravel adoption around it.
• You need per-entity, per-field export and anonymization semantics and want a proven-shaped annotation vocabulary to copy.
• You have a small, stable schema where personal data maps cleanly to a few Doctrine entities.
• You have in-house PHP capacity to fork and maintain, and you accept that you are the maintainer from day one.

Look elsewhere (or build in-house) when:

• Actively maintained vendor risk matters. 11 stars, last release February 2020, no release in five-plus years. Every framework upgrade is your problem. This is disqualifying for most production roadmaps.
• You are on Laravel — evaluate spatie/laravel-personal-data-export for export, and hand-rolled anonymization (Spatie's package deliberately does not do erasure).
• You need auditability: an immutable log of who exported or anonymized what, when, and under which request. This bundle does not provide a DSAR case-management or evidence trail, which is what regulators and enterprise buyers actually ask about.
• You need async/queued processing at scale — exports across large tables need to be backgrounded; you'll be building that layer yourself.
• Your personal data lives in non-relational stores, third-party processors, logs, or backups. The package sees your ORM entities and nothing else; scope it honestly before promising a compliance story.

Verdict: treat as a design reference and code to borrow, not a dependency. Budget a fork-and-own spike, not an install.

How to Pitch It (Stakeholders)

For executives (one paragraph): We need a defensible answer to "export my data" and "delete my data" — these are legal obligations under GDPR, and they are the two questions that most often stall enterprise security reviews. An open-source PHP component (superbrave/gdpr-bundle, MIT) already models this well: you tag personal-data fields in your schema, and it generates export and anonymization behavior from those tags. It is old and minimally maintained, so I do not recommend adopting it as a live dependency. I recommend a short spike to borrow its approach — roughly 1–2 weeks of engineering — and ship a first-party, auditable version we own. This gives us the capability without inheriting an unmaintained dependency, and the annotation inventory doubles as the data map our DPO keeps asking for.

For engineering (the honest version):

• It's Symfony-only, last release Feb 2020, 11 stars. No Laravel fit despite how it's often filed. Fork or read, don't require.
• What's genuinely worth taking: the annotation-driven classification model, and the split between anonymize (irreversible scrub, retention-safe) and delete (hard remove) per field.
• What's missing and will be your work: queued exports, an audit log of DSAR fulfilment, retention/TTL enforcement, and coverage of non-ORM data (logs, backups, third-party processors).
• Suggested spike: two days reading the annotation reader + anonymizer, then a one-page internal design doc. Decision point: build in-house or vendor the ~300 lines that matter.