Audit Logger Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for audit trails. This package is a decision input, not a product in itself. It gives us a concrete, government-authored reference point for what a "good enough" audit logger looks like, which sharpens the build-vs-adopt conversation before we sink sprint capacity into a bespoke implementation. Release 1.1.0 sharpens this further: the new AuditLoggerInterface is exactly the seam we would have had to invent to keep our application code decoupled from whichever implementation wins.
• Compliance roadmap sequencing. Audit logging is a recurring line item in GDPR Art. 30 (processing records), NEN 7510, ISO 27001/BIO, and increasingly AI Act traceability requirements. Adopting or forking this package is a way to close an audit-trail gap with a known-good shape rather than inventing schema and event semantics from scratch.
• Scoping the audit feature itself. The package forces the right product questions: what do we record (actor, action, resource, timestamp, outcome, before/after), how long do we retain it, is it tamper-evident or just append-only, is it PII-minimized, and who is allowed to read it. Those answers belong in a PRD regardless of which library we pick.
• Exit strategy and lock-in posture. 1.1.0's interface means we can bind our own implementation in the container and swap the package out without touching call sites. That converts "fork or depend" from a one-way door into a reversible decision, and it is a reason to code against the interface even if we never ship the package itself.
• Licensing and distribution strategy. EUPL-1.2 is a copyleft license (GPL-compatible, weaker than GPL in practice). That is fine for an internal or SaaS-delivered product; it becomes a legal review item the moment we ship on-prem or embed into a distributed binary. This drives a real go-to-market decision. Note the interface addition does not change the license analysis — copying the interface into our own code is still copying EUPL-licensed source.
• Supplier and dependency risk policy. One star, zero dependents, and a single maintainer org means we would be the de facto maintainer. The 1.1.0 release does not change that read: Dependabot action bumps and a single CI-adjacent PR are housekeeping, not a support path. That is a portfolio-level decision about how much unmaintained open source we are willing to carry in a compliance-critical path.
• Data sovereignty and procurement positioning. Dutch Ministry of Health provenance plus an EU license is a meaningful signal in EU public-sector and healthcare tenders — a sourcing decision, not a technical one.

When to Consider This Package

Consider it when:

• You are a PHP/Laravel team in Dutch or EU public sector, healthcare, or a regulated supplier and need to demonstrate BIO/NEN 7510-aligned audit logging.
• You need a reference implementation to copy or fork — the schema, event taxonomy, and now the AuditLoggerInterface contract are more valuable than the runtime dependency. An interface we did not have to design is a cheap, defensible artifact.
• You want to program against a small, stable contract today and defer the backend decision (package, in-house table, or external sink) until after the spike.
• Your audit needs are genuinely generic (record who did what, when) and you do not yet need WORM storage, cryptographic chaining, SIEM streaming, or long-term archival.
• You are comfortable owning the code: vendoring or forking is the expected operating model, not a fallback.
• EUPL-1.2 is compatible with your distribution model (internal use and SaaS generally are).

Look elsewhere — or budget for a fork — when:

• You need an actively maintained dependency with a support path, CVE response, and a release cadence you can put in a contract. One star and zero dependents should be read as "no community safety net" — 1.1.0's changelog is CI maintenance plus one interface, not evidence of a maintenance commitment.
• You require tamper-evidence, hash chaining, or regulatory-grade immutability. A "generic audit logger" almost certainly stops at structured append-only logging; you will be building the integrity layer yourself. Nothing in 1.1.0 moves this needle.
• You need first-class SIEM/SOC integration or retention policy tooling.
• The license is a problem for how you ship (proprietary on-prem appliance, embedded distribution).
• You are outside the Dutch/EU public-sector context — the provenance advantage evaporates and you are left with an unmaintained dependency.
• You are a non-PHP stack. There is nothing here to port beyond the design.
• Mature alternatives already satisfy the requirement — Laravel's ecosystem has well-adopted activity-log packages, and in many products a thin Monolog channel plus an append-only table is the correct answer and cheaper than any dependency.

How to Pitch It (Stakeholders)

To executives: this is not a "buy this vendor" recommendation. It is a compliance-cost argument. Audit logging is mandatory for us under GDPR and our security frameworks, and we will pay for it either way. This package — authored inside the Dutch Ministry of Health — gives us a credible, EU-licensed blueprint for the capability, plus an option to adopt it outright. The 1.1.0 release adds a logger interface, which matters commercially: it means we can start against a stable contract and change our minds later without rework, so the evaluation cost is low and reversible. The upside is a shorter path to an auditor-defensible audit trail and a defensible "built on a government reference implementation" line in EU tenders. The risk is unchanged and equally clear: near-zero adoption means no community, no support contract, and maintenance landing on us — and a minor version bump driven by CI housekeeping does not change that. The ask remains a timeboxed two-week evaluation and a fork-and-own decision, not a production commitment today.

To engineering: the surface area is small and the integration cost is low — it is a generic logger, so it slots into an existing Laravel service without architectural surgery. 1.1.0 gives us AuditLoggerInterface; type-hint that rather than the concrete implementation, and our own logger can be swapped in behind it at any point. You should still assume we own the code from day one: clone it, pin the version, run our own security review, and treat upstream as a source of ideas rather than a dependency. Two things to verify in the spike: whether our event schema and PII-minimization rules fit theirs, and whether EUPL-1.2 obligations are compatible with our packaging. There is no upgrade risk here — the release is additive and the remaining changes are GitHub Actions version bumps with no runtime impact.

Recommendation: evaluate, do not depend. If the evaluation succeeds, either fork it and add tamper-evidence and retention ourselves, or implement AuditLoggerInterface against an in-house logger informed by its event taxonomy. Either outcome gives us the compliance artifact; neither leaves a one-star package in the critical path of an audit system.