Control 8.15 asks you to produce, store, protect and analyse records of relevant events. Logs help you spot incidents that are happening or have happened, see trends and detect attempts to compromise information. Your risk assessment decides what counts as relevant, and the logs themselves must be protected.
What the control wants
Four actions on records: produce them, store them, protect them and analyse them. Logs of user activity, exceptions and security events are on the list of records tied to Annex A, and they become mandatory when your risks call for this control.
Decide what to log
The guidance does not list event types. It says what should be logged can be identified through your risk assessment and treatment process. In practice, start from questions you would need to answer after an incident:
- Who logged in, from where, and did it fail?
- Who changed permissions or configuration?
- What did administrators do?
- What touched sensitive data?
- What errors or exceptions suggest an attack?
Write the answer as a short logging standard per system type.
Protect the logs
The control requires protection but the guidance gives no methods. Common choices are restricting who can alter or delete logs, sending copies to a separate system, and keeping a defined retention period. Whichever you pick, record the reason.
Analyse them
Logs nobody reads do little. Set up a process for producing, keeping and reviewing event logs. Smaller companies can often use the built in logging of existing systems. Larger companies usually need software that gathers, analyses and correlates large volumes of data. Decide who reviews, how often, and what triggers action.
Document the process
Recommended, not mandatory: security procedures for the IT department in smaller and mid sized companies, or a logging and monitoring procedure in larger ones.
People
Explain to staff why logging is needed, and train IT staff to set logging configurations and review logs.
What the auditor may ask
Evidence that relevant event records are produced, stored, protected and analysed. Bring:
- The logging standard.
- A sample log extract for a key system.
- Access settings that show who can change logs.
- A record of a review, and an action taken from one.
A privacy note
Logs often hold personal data. Limit what you capture, set retention, and keep access tight so the logging control does not create a new exposure.
Start small
Pick your five most important systems and make sure each logs sign ins, permission changes and administrator actions to a place the administrators cannot edit. Review them on a set schedule, and write down one finding or one clean result each time. You can widen coverage later, but a review habit started early is the evidence auditors value most.
Quick check
How long should we keep logs?
The guidance gives no period. Set one from legal, contractual and risk needs, and document it.
Is a SIEM required?
No. Smaller companies can often use built in logging. Larger companies usually need software to correlate large volumes of data.
Sources
Last reviewed: 19 October 2026.
