An online store should log sign ins, admin changes, access to sensitive data, payment and refund actions, plugin or app changes and failed requests, while keeping card numbers and secrets out of the logs. The goal is to answer who did what, when and from where.
What OWASP says to record
OWASP's Logging Cheat Sheet says the application itself is the primary source of events, because it knows the user's identity, roles and the context of an action. It lists events worth logging, including actions by privileged users, use of default, shared or break glass accounts, access to sensitive data such as payment cardholder data, creation and deletion of system level objects, data import and export, submission of user generated content, and network connection failures such as TLS certificate validation errors.
A store focused list
| Area | Events to log |
|---|---|
| Accounts | Sign in success and failure, password reset, MFA change, new device |
| Admin | New staff user, role change, plugin or app install and removal, theme publish |
| Orders | Price override, manual discount, refund, order edit after payment |
| Data | Customer or order exports, bulk API reads, report downloads |
| Integrations | API key creation, webhook failures, signature check failures |
| Content | Reviews or messages rejected by a filter |
What to keep out
Do not log full card numbers, card verification codes, passwords, session tokens or secret keys. Logs are copied around and read by many tools, so a secret in a log line becomes widely exposed. Record references, such as an order ID or the last few digits where policy allows, rather than the sensitive value.
Steps to put this in place
- Pick a central place for logs outside the web server, so an attacker who gains the server cannot easily erase them.
- Use consistent fields: time with timezone, user or key, source address, action, target and result.
- Turn on the platform's activity or audit log for admin actions.
- Set alerts for a short list: a new admin, a bulk export, a burst of failed sign ins, a refund above a limit.
- Test by performing a safe action, such as creating a test user on a staging store, then confirm you can find it in the logs.
- Decide retention with your legal and finance contacts, and write it down.
Why it pays off
During an incident, the first question is usually whether customer data was touched. Without logs, the honest answer is that you do not know, and that tends to force the widest possible notification. Good logs let you narrow it.
Quick check
Is logging the full request body a good idea?
Usually not. It may capture passwords or card data. Log the fields you need and mask the rest.
Who should review the logs?
Assign a named person or team, and rely on alerts for the short list of events that need a fast response.
Sources
Safeguard provides compliance and evidence automation that can help you keep records of controls, with a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
