Why every Magento store doing £1M+ needs better audit logs

Magento Open Source ships with minimal admin audit logging. Adobe Commerce adds more (admin actions log, customer events) but still falls short of what a store doing £1M+ in annual revenue actually needs. Across the 500+ stores we have supported since 2019, weak audit logs have caused real harm three times. This post is the playbook we now recommend to every mid-market customer.

What Magento ships out of the box versus what is needed

The default Magento Open Source admin records exactly two things: who is logged in, and a basic activity log if you have enabled the obscure admin/security/use_activity_log setting. Neither captures the data you need to investigate an incident after the fact.

Adobe Commerce adds an admin actions log that records what admin user clicked what button. Better. Still missing the before-and-after data values that turn a log entry into actionable forensic information.

Working audit infrastructure for a £1M+ Magento store records, at minimum:

• Who did the action (admin user ID, IP address, session ID)
• What action was performed (entity type, entity ID, operation type)
• The state before the change (full prior values of changed fields)
• The state after the change (full new values)
• The timestamp (millisecond precision so events are reconstructable in order)
• The context (admin URL where the change happened, API endpoint if applicable)

Magento records the first two. Working audit infrastructure records all six.

Three real scenarios where it mattered

Anonymized but specific. Each is a real engagement we ran.

Scenario 1: Pricing change with no rollback path. A UK B2C retailer doing £4M annually had a junior admin accidentally apply a 50 percent discount to a product category overnight. The category had 800 SKUs. Orders flooded in. By morning the store had taken £12,000 in orders at the wrong price. The default Magento admin log told them which admin user logged in, but not which SKUs had been changed or what the prior prices were. We rebuilt the price state from a database backup. The investigation cost more than the £12,000 in orders.

Scenario 2: Customer data leak from a former employee. A B2B Magento store discovered after the fact that a recently-departed employee had been exporting customer lists for two months before leaving. The default Magento admin had no record of which customer-list exports had been run, by whom, or how many records each export included. The store had no evidence trail for the GDPR breach notification it then had to file. Working audit logs would have shown every customer-export event including row count and IP address.

Scenario 3: Mysterious tax-rate change causing audit failure. A retailer's accountant flagged that VAT had been undercharged on 800 orders over a three-month window. Investigation showed the VAT rate had been changed in admin from 20 percent to 18 percent at some point in the prior quarter. The default Magento admin had no record of when, by whom, or why. The store had to manually correct 800 invoices and refile a quarterly VAT return. With proper audit logging, the change would have been visible within hours.

The audit log feature checklist

For any Magento store doing £1M+ in annual revenue, the audit log infrastructure should support:

• Entity-level diffs. Not just "product X was updated" but "product X price changed from £49.00 to £24.50".
• Search and filter. By user, by entity type, by date range, by IP address. Logs that cannot be searched are evidence that you collected nothing.
• Retention configurable per entity type. Customer-data exports retained for seven years (GDPR records of processing). Order edits retained for the duration of the consumer-protection refund window plus accounting requirements. Product attribute edits retained for at least 90 days.
• Tamper-resistance. Logs cannot be deleted by admin users, only by superusers, and superuser log-deletion events are themselves logged.
• Export to external systems. SIEM, security event monitoring, or even just S3 buckets for cold storage. Logs that only live in the Magento database are vulnerable to the same outages and intrusions the logs would help investigate.

The Magento default ships none of these. Adobe Commerce ships two.

Build versus buy options

Three paths, depending on store size and engineering capacity.

Extension purchase. Several Magento extension vendors ship audit log modules. Amasty, Aitoc, and others have offerings ranging from £200 to £800 lifetime or subscription. Coverage varies. The strongest of these handle entity-level diffs and search. None we have evaluated handle external SIEM export cleanly.

SaaS integration. Datadog, Splunk, and several security monitoring services have Magento integrations that capture admin events to external storage. The Magento side is usually a lightweight observer module forwarding events. SaaS subscription cost typically £100 to £600 per month depending on event volume.

Custom build. A custom audit log module is roughly two weeks of engineering work for a mid-market store. Covers entity-level diffs, search, configurable retention, and a webhook for external SIEM export. We have shipped this pattern four times. Engineering cost £6k to £15k depending on store complexity. Carries no recurring fees.

For most stores we recommend the custom build. The cost is comparable to two years of SaaS subscription, and the resulting code is yours to evolve as your audit requirements change with growth.

The DIY blueprint

If you are building audit logging in-house, the minimal architecture is:

1. An etechflow_audit_log database table with columns for (event_id, timestamp, user_id, user_ip, entity_type, entity_id, action, prior_state JSONB, new_state JSONB, context).
2. An observer or plugin layer that hooks into Magento's save events for the entity types you care about (products, customers, orders, tax rates, store config).
3. A serializer that captures the entity state before and after the change, diffs them, and writes the audit row.
4. A retention background worker that prunes audit rows older than the configured retention per entity type.
5. An optional webhook fanout that forwards new audit events to your SIEM or external log store in real time.
6. An admin UI for searching and reviewing logs, with permissions gating who can view what.

Plan for two engineering weeks. Test the observer overhead carefully; poorly written audit observers can add 50 to 200 milliseconds to admin save operations.

When to start

If your Magento store is over £500K annual revenue, install audit logging this quarter. If you are over £1M, you should have shipped this already. The cost of being wrong is not theoretical. The three scenarios above all happened to stores that thought their default Magento logging was enough.

Related

• Magento development cost guide covers the cost of custom Magento engineering work like this.
• eTechFlow security policy covers our own audit and logging stance for the marketplace itself.