Audit Logger Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the audit trail itself. The single biggest decision this package informs: do we hand-roll "who did what, when, to which record" logging, or adopt an existing implementation? Audit logging looks like a two-day feature and behaves like a two-quarter liability — event taxonomy, tamper evidence, retention, PII redaction, and reviewer UX all accrete. Using a government-published implementation lets the team spend that budget on domain features instead.
• Compliance roadmap sequencing. In Dutch healthcare/public-sector contexts, audit trails are not optional nice-to-haves — they are the evidentiary layer for GDPR accountability, NEN 7510 / ISO 27001 logging controls, and healthcare data-exchange logging obligations (e.g. WEGIZ-style requirements around who consulted which patient data). If your roadmap has a certification or DPIA milestone, this is a candidate to de-risk it rather than a "later" item.
• Certification and procurement readiness. For a product sold into Dutch government or healthcare, "our audit log is derived from a MinVWS-published component under EUPL-1.2" is a materially easier conversation with a CISO, a DPO, and a tender evaluator than "we wrote our own." That is a positioning decision, not just a technical one.
• Standardisation across the portfolio. If more than one product in the portfolio needs audit trails, adopting a shared schema now avoids three incompatible log formats later — which is exactly the sort of thing that kills a future SIEM integration or cross-product compliance dashboard.
• Packaging and pricing. Audit retention, export, and reviewer access are natural enterprise/government tier boundaries. Deciding to adopt a library that already models audit events lets you put a real, defensible line there instead of inventing one.
• Roadmap de-scoping. Concretely: this closes out "implement audit logging" as a bespoke epic and replaces it with "integrate, verify, and document the integration" — a smaller, better-bounded story with a vendor-style artefact behind it.

When to Consider This Package

Consider it when:

• You are building in PHP in a Dutch government, healthcare, or healthcare-adjacent context, and audit logging is a compliance requirement rather than a product differentiator.
• You need a licence your legal and procurement teams can accept without a six-week review — EUPL-1.2 is designed for exactly this reuse pattern in EU public-sector software.
• You want provenance ("MinVWS-published") as a due-diligence artefact for a DPIA, penetration test response, or tender.
• You are willing to own the integration and verification work yourselves, because there is no vendor SLA behind it.

Look elsewhere, or treat as a research input only, when:

• You are on Laravel specifically. The package is published as nl-rdo-php-audit-logger-bundle — bundle is Symfony convention, and the 1.1.0 release note ("register AuditLoggerInterface in configuration") is a Symfony DI/service-container change. A Laravel team should assume an adapter layer (PSR-3 handler, middleware, or an event subscriber) rather than a drop-in, and should expect this component to track Symfony idioms rather than Laravel ones. Price that work before you commit; if the adapter is more than a sprint, spatie/laravel-activitylog plus your own integrity layer may be cheaper.
• Community maturity is a hard requirement. Still zero stars and zero dependents: no ecosystem, no third-party tutorials, no Stack Overflow corpus, no crowd-sourced bug discovery. Government-backed projects are often maintained but not socialised. That said, 1.1.0 is a modest positive signal here — an external contributor (@wietsewarendorff) got a PR merged and a tagged release cut, so the repo does appear to accept outside input and to have a working release process. Treat that as "the lights are on," not as "there is a community."
• You need throughput characteristics you cannot verify. Audit logging sits on the hot path of every read. Confirm the storage backend and write amplification story before you put it in front of patient-data lookups.
• You need contractual guarantees. There is no vendor to escalate to. If the product cannot tolerate "we fix it ourselves," choose a commercial or in-house option.

Due-diligence questions to answer before adoption (these, not the score, drive the decision): Is the log append-only and tamper-evident (hash chain, WORM storage, or signed batches)? What is the event schema, and does it cover reads as well as writes? How is PII handled — are patient identifiers hashed or pseudonymised? What are retention and purge semantics? Is there an export path to a SIEM in a format an auditor will accept? And what is the actual maintenance commitment from the upstream team?

Note on the packaging metadata: the high composite score (9.70) with a low opportunity score (57.45), zero stars, and zero dependents is best read as licence-and-description-driven, not adoption-driven. Do not present the score to stakeholders as evidence of maturity.

Note on 1.1.0: this release only wires AuditLoggerInterface into the service configuration. It adds no logging capabilities, changes no event schema, and introduces no breaking changes — so it does not move the product decision. It does narrow the "is this project alive?" risk from unknown to "one merged external contribution and one tagged minor release," which is enough to justify the spike and nowhere near enough to skip it.

How to Pitch It (Stakeholders)

Executives / sponsors (30 seconds): Audit logging is a compliance requirement we can either build or adopt. This is a component published by the Dutch Ministry of Health under an EU-friendly open-source licence, which means it is credible in front of our auditors and usable in tender responses. Recommendation: fund a one-sprint evaluation spike to validate it fits our stack and our auditor's expectations, rather than committing to a build. The downside risk is low — it is open source and self-hosted, so there is no lock-in — but it also comes with no vendor support, so the maintenance cost is ours. The decision is not "is this good software" but "is this cheaper than writing and defending our own."

Engineering: Treat this as a reference implementation and schema to adopt, not a turnkey dependency. It is a Symfony bundle in a PHP codebase — the 1.1.0 service-container registration is a reminder of that — so on Laravel expect to write an adapter and own the integration. Ask back for an estimate on (a) adapter work, (b) storage backend and retention, (c) integrity verification, and (d) SIEM export. If that total exceeds roughly one sprint, the buy case weakens considerably and we should re-evaluate against in-house or a maintained alternative. 1.1.0 is a safe upgrade from 1.0.0 with no migration work, so pinning and reviewing the changelog on each minor is a viable operating model for now.

Compliance / DPO: The value here is provenance and a defensible event model, not a certification. We still owe the DPIA its own analysis: what is logged, how identifiers are handled, how long it is kept, and who can read it.

The ask: approve a timeboxed spike with a written go/no-go, and treat the dependency's community size as an accepted, documented risk rather than an unnoticed one.