ISO 27001 A.8.15: Create logs that can support investigation

What A.8.15 requires in practice

A.8.15 requires the organisation to produce, store, protect and analyse logs capturing activities, exceptions, faults and other relevant events. Four verbs matter. Producing means the right events are actually recorded. Storing means they are kept. Protecting means they cannot easily be altered or deleted by the people whose actions they record. Analysing means someone looks at them for a purpose.

In practice the organisation decides which systems and events matter, what detail each record needs, such as who, what, when and from where, how long records are kept and who can read or change them. It also decides how logs will be examined, whether routinely or when an investigation requires it.

Outputs include defined logging for the relevant systems, protected storage and evidence that records have been used. The control does not specify events, retention periods or a central tool. Sterling's teams often test the complete path from an event to a readable record, which is a method and not a stated obligation.

Collect events for a defined purpose

Decide what questions the organisation may need to answer. For an important application, these might concern who changed a permission, whether an attempted action was rejected or when a service fault began. Select relevant sources and fields so the records support those questions without collecting unnecessary sensitive content.

Include enough context to connect an event with the relevant identity, system, action and time. A record that states only that an error occurred may be insufficient to investigate it. Conversely, recording credentials or entire sensitive submissions can create another exposure. Review logging design alongside the application's information-handling requirements.

Protect the record from inappropriate change

Restrict access to logs and the settings controlling them. Someone whose activity needs accountability should not have unrestricted ability to erase the only record of that activity. Consider separation, central collection or other suitable safeguards according to the environment and the risk.

Operational protection matters too. Storage exhaustion, failed forwarding or unexpected overwriting can remove evidence without deliberate interference. Determine how the organisation recognises missing sources and interruptions. Connect the design with capacity management and the protection of privileged access.

Why logging matters to the business

When something goes wrong, logs are often the sole reliable account of what happened. Without them the business cannot tell which customers were affected, how an intruder got in or whether a suspicious action was genuine. That uncertainty is costly: notifications become broader, investigations take longer and clients lose confidence. Logs also deter misuse, because people behave differently when their actions are recorded, and they support disputes about who did what. Good logging does not mean collecting everything; unfocused collection hides the useful events and creates storage and privacy burdens. A deliberate approach gives the business evidence it can rely on, and auditors place considerable weight on whether records exist, are protected and have actually been used.

How to implement A.8.15

Decide what questions your logs must be able to answer, and let those questions drive what is recorded. A defined purpose makes the volume manageable.

1. List the systems that matter and the events that would help investigate misuse, faults or incidents, such as sign-ins, privilege changes and failed actions.
2. Make sure each record identifies who or what acted, what happened, when and from where.
3. Send records to storage that the people being logged cannot change, and restrict who can read or alter them.
4. Set how long records are kept, balancing investigation needs, storage and privacy obligations.
5. Decide who reviews logs, how often and what they do with unusual entries, including how a suspicious pattern is escalated to incident handling.
6. Test the whole path by performing a harmless action and finding it in the stored records.
7. Review coverage when systems, suppliers or threats change, and when an investigation reveals a question the logs could not answer.

Illustrative software example: an event without a usable identity

Illustrative manufacturing example: local logs lost with a workstation

A hypothetical manufacturer keeps relevant maintenance events only on a workstation used to support production planning. When the device is replaced after a fault, the available records do not cover the period needed for an investigation. The team had treated local storage as a complete logging arrangement.

The organisation reviews the relevant event sources, preservation needs and collection options. It implements an appropriate protected route and tests retrieval for a selected period. It also verifies what happens when a source stops reporting. This improves the evidence lifecycle without claiming that every low-value device message must be retained indefinitely.

Make analysis and retention deliberate

Logs should support analysis, whether performed directly or through a monitoring service. Define who can interpret the records and how significant findings reach the appropriate response process. Monitoring activities build on useful events, but forwarding everything to a dashboard does not establish meaningful review.

Set retention using the organisation's purposes and applicable obligations. Consider how long records need to remain readily accessible and how retained records will be protected. Log data can contain personal or confidential information, so access, sharing and deletion need appropriate governance. A request from a supplier for diagnostic logs should be assessed before the material is transferred.

Build evidence that remains useful when needed

Common nonconformities with A.8.15

Logging findings often show records that exist but cannot answer a real question.

• Events recorded without a usable user identity, so actions cannot be traced to a person.
• Logs held only on the system being monitored, and lost if that system fails or is tampered with.
• Administrators able to edit or delete the logs of their own activity.
• Logs collected in volume but never reviewed.
• Retention set without considering investigation needs, so records are gone when an incident is discovered.