Audit Log Monitoring
The Audit Log answers the question every incident starts with: what changed, when, and who did it. It only helps if it was running before the incident happened.
Enable it now
Go to SiteFort → Settings → Advanced and turn on Audit Logging.
This is the page you end up on during a compromise, a suspicious admin action, or a client asking exactly what changed and when. And it has one unforgiving property: it can't tell you anything about the time before it was switched on. If audit logging was off when the incident happened, that evidence isn't hiding somewhere, it simply never existed.
So turn it on now, today, before there's any reason to. At Standard log level, the performance and storage cost is small enough that there's really no good reason to be running any WordPress site without it.
Recommended settings
Go to SiteFort → Settings → Advanced → Data Configuration.
| Setting | Recommended | Watch out for |
|---|---|---|
| Audit Logging | On | Nothing to watch. Turn it on and leave it alone. |
| Log Level | Standard | Standard catches everything actually security-relevant without drowning the log in routine WordPress noise nobody's ever going to read. Reach for Verbose only while you're actively mid-investigation and need every last detail. |
| Log Storage | Database and File if storage allows | Database-only works fine for most sites. Adding File logging gives you a copy of the trail that survives a database problem, or a database that got deliberately tampered with as part of the same attack you're trying to log. |
| Retention | Long enough to cover your incident response window | Set retention too short and the logs won't reach back far enough for a slow-moving compromise that took weeks to surface. If you manage sites for clients, keep retention long enough to still answer their questions weeks after the fact, not just days. |
Events worth watching
Once it's on, the Audit Log captures every security-relevant event on its own, no extra configuration needed. During a routine check, though, your attention is better spent on some categories than others:
- New administrator account created
- SiteFort deactivated
- 2FA settings changed
- Sensitive tool used
- Unexpected administrator sign-in
- Password changed on a privileged account
- Plugin installs and activations
- Theme changes
- Hardening setting changes
- Failed login patterns
- Repeated login failures from the same IP
- Site setting changes
The left-hand list is where a real compromise shows up first, that's more or less the exact playbook an attacker runs right after gaining access. If you spot any of these and you're certain you didn't do it yourself, don't wait, open that log entry for the IP, timestamp, and user, then cross-reference it against the Traffic Log and Scanner findings from the same window before assuming anything.
Using the Audit Log during an incident
When something's clearly wrong on a site, the Audit Log is where you build the actual timeline, not the theory of what probably happened. Work backwards from the symptom you noticed to the change that caused it.
Finding what changed
- Pin down when the problem was first noticed, or when a scan finding first appeared.
- Open the Audit Log and filter to that window.
- Look for admin account activity, plugin changes, hardening changes, or tool use sitting inside it.
- Cross-reference any suspicious IP against the Firewall Traffic Log for the same period, patterns rarely show up in just one place.
- If a plugin change turns up, check whether a recent install or update lines up with when the problem actually started.
Before clearing or resetting anything
Export the Audit Log as a CSV before you clear entries, reset plugin data, or restore from backup. Once it's cleared, it's gone, there's no undo waiting on the other side of that button. That export is your evidence record if this ever needs to go further, a deeper investigation, a client conversation, or a data breach report you'd genuinely rather not have to file without documentation behind it.
After an incident is resolved
Once the site is clean and controls are back in place, use the Audit Log to actually confirm that, rather than assuming it:
- Confirm no unexpected admin accounts remain.
- Confirm SiteFort is active and its settings weren't quietly changed somewhere along the way.
- Confirm 2FA is still being enforced for privileged roles.
- Confirm nothing new was installed or activated after your cleanup window closed.