Pii Sanitizer Symfony Laravel Package

Product Decisions This Supports

• Privacy-by-design defaults for logging and analytics. A PII sanitizer lets the team ship features that log, export, or forward user data without hand-rolling redaction rules per service — directly supports GDPR/CCPA commitments, DPA obligations, and data-minimization claims made in privacy policies and security questionnaires.
• Build vs. buy on the redaction layer. Sanitizing emails, names, phone numbers, and identifiers is deceptively fiddly (edge cases, locale formats, nested payloads). Adopting a maintained package pushes the decision from "build a bespoke scrubber" toward "buy/wrap," freeing engineering to work on the differentiator.
• Roadmap sequencing for compliance work. This is an enabler for the features that depend on it: audit logging, support tooling that replays customer payloads, third-party error tracking (Sentry/Bugsnag), and AI/LLM integrations that must not receive raw customer data. If it's viable, those items can move up; if not, they carry a redaction dependency.
• Scope of the commitment — and its limits. Note that this is a Symfony bundle, not a Laravel package. For a Laravel codebase it does not drop in via a service provider; adopting it means either running Symfony components inside Laravel or, more likely, treating it as a reference implementation and porting the sanitization rules into a Laravel package/service. That is a materially different cost line and belongs in the decision record.
• Vendor/asset risk register. A pre-1.0, single-maintainer package with a namespace rename at v0.2.0 is a signal for an internal fork-or-wrap strategy with our own tests around the redaction ruleset.

When to Consider This Package

Consider it when:

• The stack is Symfony (or you are prepared to adapt) and you need a configurable bundle for scrubbing PII out of request/response payloads, logs, or serialized objects.
• You want convention over bespoke code: standard identifiers handled by a maintained ruleset beats a regex file one engineer wrote in an afternoon.
• The team is comfortable pinning and auditing a small, low-traffic dependency, and can absorb occasional breaking changes during the 0.x line.
• Redaction needs are rule-shaped and stable (structured fields, known patterns) rather than requiring ML-based entity detection.

Look elsewhere when:

• You are Laravel-first and expect composer require + auto-discovery to just work — this bundle's namespace and service wiring are Symfony-shaped; plan for a port or a different package.
• You need free-text/NER detection (unstructured prose, unusual locales) — pattern-based sanitizers underperform and false confidence is worse than no sanitizer.
• You need a stable public API: 0.x with a namespace change between 0.1.x and 0.2.0 means every minor bump can break use statements and DI config. Fine for internal greenfield, costly for a shared platform library consumed by many teams.
• Bus factor is a hard constraint — single maintainer, no visible 1.0 plan, and no LTS is a procurement blocker in regulated environments.

Concrete adoption criteria before committing: pin to ^0.2, add a characterization test suite over representative payloads (including false-negative cases), wrap the sanitizer behind an internal interface so the vendor can be swapped, and document the 0.1.2 → 0.2.0 namespace migration (Jackal\PiiSanitizer\Bundle) in the upgrade notes.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated an open-source component that automatically strips personal data — names, emails, identifiers — from logs and message payloads before they leave our system. It supports the privacy commitments we already make to customers and unblocks compliance-dependent roadmap items (audit trails, third-party error monitoring, AI features that must not see raw customer data). It is not a drop-in for our Laravel codebase — it targets Symfony — so the realistic play is to reuse its ruleset behind a thin internal wrapper rather than adopt it wholesale. Cost is small and bounded; the alternative (building and maintaining redaction ourselves) is larger and ongoing.

For engineering: This is a Symfony bundle, pre-1.0, single maintainer. v0.2.0 renamed the namespace to Jackal\PiiSanitizer\Bundle — a breaking change with no deprecation path, which tells us to expect more of the same before 1.0. Recommend: pin exactly, vendor the source or wrap it behind our own PiiSanitizer contract, and write tests against representative payloads so a silent regression in matching rules fails our CI rather than leaking data. Do not let it become a shared platform dependency until it reaches 1.0 or we own the fork.