Filagora Compliance Laravel Package

Product Decisions This Supports

• Build vs. buy for GDPR/privacy compliance. This package makes "buy/integrate" a credible option: DSAR intake, triage, fulfilment (export/erasure), audit trail, retention automation, cookie consent, and policy versioning all ship in one module. A PM can weigh this against a 2–4 month in-house build and typically find the package covers ~70–80% of a standard compliance backlog out of the box.
• Launching into regulated markets (EU/UK, and any enterprise deal with a DPA and security questionnaire). The "Privacy requests" screen with statuses, legal hold, reply, rejection-with-reason, and an audit log is exactly what procurement and legal reviewers ask to see demonstrated. This can unblock enterprise sales cycles rather than being a compliance-only cost.
• Roadmap sequencing: compliance as a feature, not a project. Because it plugs into filagora-core (and optionally filagora-entitlements and filagora-cms), it can be scheduled as a thin slice in an existing Filament-based product instead of a standalone initiative. The KPI widget (fulfilled within deadline, open requests, awaiting review) gives a ready-made operational dashboard, which is also a credible demo/screenshot asset.
• Support-operations staffing and SLA decisions. The filagora:compliance:prune command with --dry-run, daily scheduling, and per-rule failure reporting (mailed to the DSAR address, non-blocking) lets a PM commit to "we respond within 30 days" and "we retain request data for X" with automated enforcement rather than a manual spreadsheet process. The distinction between deleting export files after N days while keeping the request is a policy decision the package supports directly.
• Data-retention policy as a configurable product surface. Retention windows by request status, never pruning items on legal hold, and the ability for other modules to register their own rules via core's RetentionRuleRegistry means retention policy becomes one auditable place instead of ad-hoc cron jobs scattered across the codebase.
• Cookie consent and policy versioning UX decisions. CookieConsent::normalize() defines a clear precedence (cookie's own choice → its group's → default, required groups forced on), and requiresReconsent() supports the "we changed our cookie policy, ask again" flow. That is a product decision the PM can now specify precisely instead of debating.
• Extensibility for future modules (a platform decision). PrivacyContributor and UserAnonymizer interfaces mean new features (e.g. a new module storing personal data) can be made compliant without touching this package. That is a meaningful signal that compliance will not become a recurring tax on every future feature.
• Optionality in packaging/upsell. filagora-entitlements is a suggestion rather than a hard requirement, and access funnels through core's AccessChecker. A PM can ship the module to all customers, or gate it behind a plan, without a code fork.

When to Consider This Package

Consider it when most of the following hold:

• You are on Laravel + Filament with filagora/filagora-core ^0.2.1 already in place. This package requires core and is not standalone.
• You have (or are about to have) real data-subject requests — access/export, erasure, objection — and currently handle them by hand.
• You need an auditable record of who did what to a request, and of policy acceptance, for legal or enterprise-sales reasons.
• You want retention and export-file cleanup automated, including legal-hold protection.
• Your team is small enough that a shipped, tested privacy workflow is worth more than bespoke code you would have to maintain and defend in an audit.
• You are comfortable with a v0.1.0, first-release artifact. This is a strong initial release but young: expect schema and config churn, and plan for upgrade work.

Look elsewhere (or defer) when:

• You are not on Filament. The admin surface is the core value; the services and commands alone are a much thinner proposition.
• You need a certified, vendor-supported compliance product with SLAs, DPA, sub-processor documentation, and legal attestations. This is a library, not a compliance vendor — it gives you the mechanics, not the certification.
• You need multi-tenant or per-brand policy partitioning. The config (gates, kpis, routes, mail, retention, anonymize.attributes, models) is global; nothing here suggests per-tenant policy versions or per-tenant DSAR routing.
• You need identity-scoped erasure across many third parties (warehouses, CRMs, analytics, backups). Contributor-based erasure covers registered first-party contributors only; downstream propagation remains your problem.
• Your data model is heavily normalized or your identity lives outside the users table. The default ConfiguredColumnsAnonymizer replaces configured columns; the PM should confirm every identity-bearing table is either a contributor or covered by the anonymizer config before committing.
• You cannot tolerate a first-release dependency in a compliance-critical path. A reasonable interim stance is to adopt the services/audit tables but keep manual sign-off on erasure until the package has a few point releases.

How to Pitch It (Stakeholders)

For executives (one paragraph). We can stand up a defensible privacy-operations capability — request intake, tracked handling with deadlines, data export and erasure, an immutable-style audit trail, retention automation, and cookie/policy consent — by integrating a package into our existing application rather than commissioning a bespoke build. That converts a multi-month compliance project with ongoing maintenance cost into a contained integration with a visible operations dashboard, and it gives sales a concrete answer to the security and privacy questions that currently stall enterprise deals. The trade-off is that it is a young, first-release library: it provides the mechanics and the audit record, not legal certification, and it assumes our stack already runs on filagora-core and Filament.

For engineering (a few sentences). Adopt filagora/filagora-compliance ^0.1.0 alongside filagora/filagora-core ^0.2.1. It ships eight tables in one migration with an filagora:adopt schema snapshot for existing installs, swappable models via filagora-compliance.models, and two enums (PrivacyRequestStatus, PrivacyRequestType). All staff actions route through the PrivacyRequests service so they are audited and the requester is notified; services return refusals with reasons instead of throwing. Erasure runs contributors and the anonymizer in a single transaction. Retention is a daily scheduled command with --dry-run and per-rule failure isolation. Extension points are the PrivacyContributor and UserAnonymizer contracts — any new module holding personal data should implement a contributor rather than reaching into this package.

For the compliance/legal stakeholder. Request handling, legal hold (which blocks both export and erasure), rejection with recorded reasoning, staff replies, and a filterable operation audit are all in-product. Retention windows by request status and export-file expiry are configurable and enforced automatically. What it does not do: certify anything, propagate erasure to third-party processors, or replace your records of processing.

Key risks to name up front. First release (v0.1.0) — budget for upgrade churn and pin the version. Global, not per-tenant, configuration. Erasure completeness depends entirely on contributor and anonymizer coverage being verified before go-live. Mail delivery is on by default and configurable via mail.enabled — confirm the dsar_request_email routing before the first real request arrives.