MMPlugs Logo

Docs / MMCRA Toolkit / Audit log

Audit log

Audit log

Every artifact the toolkit produces and every significant event it observes is recorded to a tamper-evident audit log. This is your CRA Article 31 record-keeping evidence — proof you generated what you generated, when you generated it.

Where it lives

A custom WordPress database table: wp_mmcra_audit_log (the prefix matches your install). One row per event. The table is created on plugin activation and never schema-migrated except by toolkit updates that explicitly bump the version.

What gets logged

  • SBOM generation (installed + zip uploads)
  • Plugin Scanner runs (installed + zip uploads)
  • VDP saves and exports
  • DoC saves, deletes, and HTML exports
  • Vulnerability Check runs
  • Weekly Monitor runs (including "nothing new" runs and "skipped: license expired" runs)
  • Compliance Bundle builds
  • License activations, deactivations, transfers

For each event the row records:

  • Timestamp (UTC, microsecond precision)
  • Event type (TYPE_SBOM, TYPE_VDP, TYPE_DOC, TYPE_PLUGIN_EVENT, etc.)
  • Plugin slug (when applicable)
  • Artifact path (when applicable)
  • SHA-256 hash of the artifact content at write time
  • WordPress user ID that triggered the event
  • Notes (human-readable summary)
  • Meta (structured JSON for event-specific details)

The SHA-256 hash is the key field. It binds a specific row to a specific artifact byte-for-byte. If the artifact gets edited later, the hash on disk no longer matches the hash in the log, and you can prove the original.

View the log

CRA Toolkit → Audit Log shows the most recent 100 entries with sortable columns. Filter by plugin slug or event type.

For longer history or for handing off to a regulator, use the export.

Export as CSV

Click Export CSV on the Audit Log page. You get a CSV with every row in the log:

id,timestamp,artifact_type,plugin_slug,artifact_path,artifact_hash,user_login,notes
1,2026-05-26T14:30:10Z,sbom,mm-table-pro,...,e3b0c4...,admin,CycloneDX 1.6 SBOM generated

This is the audit log file included in every Compliance Bundle (scoped to the plugin slug).

What you can't do

  • You can't edit rows. The toolkit has no UI for amending the log.
  • You can't delete rows. There's no "Clear log" button.
  • You can't disable logging. Every artifact write is logged unconditionally.

This is by design. The audit log is meant to be inconvenient to tamper with. A determined attacker with database access can of course UPDATE rows directly — that's not what this protects against. It protects against accidental loss of evidence and against the "did we actually generate that SBOM last March?" question.

Backup advice

The audit log is in your WordPress database — your normal backup strategy covers it. If your DB host doesn't keep weekly backups, fix that before worrying about the audit log itself.

For long-term Article 31 evidence (10 years), the Compliance Bundle's audit-log CSV is what you archive. Move bundles to cold storage; the live audit log can rotate after some years if disk pressure is real.