You log the events needed to investigate, and you keep them.
What it actually means
Audit logging is, with access control, one of the two areas assessors find most often broken. You have to define which events you log, actually capture them across the in-scope systems, and retain them long enough to investigate an incident. 'We have logs somewhere' isn't it — coverage and retention are the test.
Pass or fail — an assessor needs a "yes" to each
- The events you log are defined and cover the in-scope systems.
- Logs are actually generated on endpoints, servers, identity, and security tooling.
- Logs are retained per a defined policy (and protected from tampering).
- You can produce logs for a given system/time when asked.
What to have ready
- Audit/logging policy defining logged events + retention
- SIEM or log-repository configuration showing coverage
- Sample log export
Where teams trip up
- Logging enabled on some systems but not the whole scope
- Logs that roll over in days, with no retention
- No central collection — logs only live on the box that made them
See where this control puts your score
Run all 110 requirements free in about 10 minutes — or draft your SSP language for this control. No signup.
Calculate your SPRS score →Draft your SSP language →Connected requirements
More in Audit & Accountability (3.3)
3.3.2 — Trace actions to individual users3.3.3 — Review and update what you log3.3.4 — Alert when logging breaks3.3.5 — Correlate and review your logs3.3.6 — Reduce logs and generate reports3.3.7 — Synchronize clocks for time stamps3.3.8 — Protect your logs from tampering3.3.9 — Limit who manages logging