An admin action log: why you need it before an incident

After a strange event everyone remembers that the password was strong. Almost nobody can say who signed in to the admin on Thursday and what they clicked. An action log is not there for an auditor in peacetime. It is there so an incident can be reconstructed at all.

What to record so the log does not become noise

• Sign-in, sign-out and failed attempts. With an IP, and without the illusion that an IP always equals a person.
• Creating users, changing roles, exporting the database, installing plugins and modules.
• Changes to payment and mail settings. Those are quiet and expensive edits.
• Retention of at least a few months, and a place from which an admin cannot wipe the log with one button.

A log that lives in the same admin and is deleted with it only helps against an honest mistake. For a hostile case, a copy of events has to go somewhere the compromised account cannot delete. That does not have to be a heavy system: sometimes a separate receiver and a ban on wiping is enough.

On Lexora portals the log is part of the role matrix from the start. On a site that is already live it can be added during an audit: first the list of events you actually need, then retention.