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.
The Audit Log is the first thing you reach for when investigating a compromised site, a suspicious admin action, or a client dispute about what changed and when. It cannot tell you what happened before it was enabled. If audit logging is off when an incident occurs, that evidence is gone permanently.
Enable it now, before anything happens. The performance and storage impact at Standard log level is minimal for almost every WordPress site.
Recommended settings
Go to SiteFort → Settings → Advanced → Data Configuration.
| Setting | Recommended | Watch out for |
|---|---|---|
| Audit Logging | On | Nothing to watch. Enable and leave on. |
| Log Level | Standard | Standard captures everything security-relevant without logging routine WordPress activity that adds volume without value. Use Verbose only if you are actively investigating an issue and need maximum detail. |
| Log Storage | Database and File if storage allows | Database-only is fine for most sites. File logging provides a backup of the audit trail that survives a database issue or targeted database manipulation during an attack. |
| Retention | Long enough to cover your incident response window | Short retention means logs may not reach far enough back when investigating a slow-moving compromise. For agency-managed sites, keep retention long enough to answer client questions weeks after an incident. |
Events worth watching
The Audit Log captures all security-relevant events automatically once enabled. During routine reviews, focus on these categories first:
- 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 "Investigate immediately" events are the ones attackers trigger after gaining access. If you see any of them and did not take that action yourself, open the log entry for the IP address, timestamp, and user, then cross-reference with the Traffic Log and Scanner findings from the same period.
Using the Audit Log during an incident
When something is wrong on a site, the Audit Log is where you establish a timeline. Work backwards from the symptom to the cause.
Finding what changed
- Note when the problem was first noticed or when a scan finding appeared.
- Open the Audit Log and filter by the relevant time window.
- Look for admin account activity, plugin changes, hardening changes, or tool use in that window.
- Cross-reference suspicious IP addresses with the Firewall Traffic Log for the same period.
- If the entry involves a plugin change, check whether a newly installed or updated plugin coincides with the problem.
Before clearing or resetting anything
Export the Audit Log as CSV before clearing entries, resetting plugin data, or restoring from backup. Once cleared, the log cannot be recovered. The CSV export is your evidence record if the incident requires further investigation, a client conversation, or a data breach report.
After an incident is resolved
Once the site is clean and controls are restored, use the Audit Log to confirm the remediation is complete:
- Confirm no unexpected admin accounts remain.
- Confirm SiteFort is active and settings were not changed.
- Confirm 2FA is still enforced for privileged roles.
- Confirm no new plugin installs or activations occurred after the cleanup window.