How do we decide what to log and monitor, and who reviews it, for an ISO 27001 audit?

Start

We must show we log and review security events

Logging records what happens so incidents can be detected, investigated and proven. Monitoring watches for unusual behaviour while it can still be stopped. The auditor asks what is logged, where, for how long and who looks at it, and the pack names logs that nobody reviews as the usual gap.

• Then: Do you have a list of the systems and cloud services in scope?

Decision

Do you have a list of the systems and cloud services in scope?

Logging is decided system by system, so you need the list first. Cloud consoles and software-as-a-service tools are the ones most often missed. If you do not have the list, answer no.

• Yes: Decide the events that matter for each system, from your risks
• No, or not known: Build the asset list first, then return

Outcome

Build the asset list first, then return

Without a list you cannot say which systems should produce logs, and the sample will find systems that do not. Build the list from the systems that already know, then come back.

Step

Decide the events that matter for each system, from your risks

Start from what would show a compromise or misuse: sign-ins and failures, administrator actions, security alerts, access to sensitive data and changes to the logging itself. Let your risk assessment set how much more. NCSC's introductory guidance starts the same way, by listing the logs that could show whether you have been compromised.

• Then: Does every system produce those logs, including cloud consoles?

Decision

Does every system produce those logs, including cloud consoles?

Logs kept only on the system that made them, and no logs from cloud services, are the mistakes the Library names. If you have not checked a cloud console, a software-as-a-service tool or a network device, answer no.

• Yes: Send logs to a central store and keep them for a set period
• No, or not known: Turn the logging on, or record the gap and who accepts it

Step

Turn the logging on, or record the gap and who accepts it

Turn it on where the system can do it. Where it cannot, or the cost is out of proportion, record the gap as an exception with a compensating control, approved by the person with authority to accept the risk.

• Then: Send logs to a central store and keep them for a set period

Step

Send logs to a central store and keep them for a set period

A central store lets you search across systems and keeps evidence if one system is lost. Point every system, including cloud services and network devices, at the same time source and record the time zone in the logs (UTC is common), so events from different systems can be put in order. The pack's privileged access standard sets a default of at least 12 months for privileged events, and the Library gives 12 months as an example. Pick a period from your own investigations, contracts and law.

• Then: Can the people who administer a system alter or delete its logs?

Decision

Can the people who administer a system alter or delete its logs?

A log the administrator can edit proves little against that administrator. The pack asks for logging to a store that administrators cannot change or delete. If you do not know the store's rights, answer yes.

• Yes, or not known: Move them to a store the administrators cannot change
• No: Do the logs contain personal data?

Step

Move them to a store the administrators cannot change

Use a write-once setting, a separate account held by someone else, or a service owned outside the team. Where one person does both jobs, add a review by an independent person and record it.

• Then: Do the logs contain personal data?

Decision

Do the logs contain personal data?

Logs of sign-ins, addresses and activity often identify people. Privacy law limits how long you keep them and who reads them. Decide the purpose, the retention and the access with whoever advises on data protection. If you are not sure, answer yes.

• Yes, or not known: Limit who can read them, set the purpose and shorten the period
• No: Define what should raise an alert, from your threats

Step

Limit who can read them, set the purpose and shorten the period

Name the purpose of the logs, restrict access to those who investigate, and keep each type no longer than the purpose needs. Record the decision, as it is one an auditor and a regulator may both ask about.

• Then: Define what should raise an alert, from your threats

Step

Define what should raise an alert, from your threats

Choose a short list that you will act on: impossible sign-ins, administrator changes, malware detections, large data movements and changes to logging. A long list that nobody can follow produces ignored alerts, which the Library names as a mistake.

• Then: Does each alert go to a named person or service who acts on it?

Decision

Does each alert go to a named person or service who acts on it?

Alerts sent to an unread mailbox are the first mistake the Library names. The pack's generative AI standard, for one, names a person who looks at each alert within a stated time. If a mailbox rather than a person receives them, answer no.

• Yes: Do alerts reach someone outside office hours?
• No, or not known: Name the owner, the response time and the route to an incident

Step

Name the owner, the response time and the route to an incident

Pick a person or a managed detection service, set how fast each class of alert is looked at, and say when an alert becomes an incident. Use the incident questions for that line.

• Then: Do alerts reach someone outside office hours?

Decision

Do alerts reach someone outside office hours?

Monitoring that works only in office hours is a mistake the Library names. Whether you need cover at night depends on how fast an attacker can do damage to your services. If you have not decided, answer no.

• Yes: Make a test event and follow it from system to alert to action
• No, or not known: Choose cover, or accept the gap in writing

Step

Choose cover, or accept the gap in writing

Options are an on-call rota, a managed detection service or a stated acceptance that alerts wait until the morning, signed by the risk owner. Any of the three can be defended. An unrecorded gap cannot.

• Then: Make a test event and follow it from system to alert to action

Step

Make a test event and follow it from system to alert to action

Do something that should be logged, such as a failed sign-in or a change to an administrator group, and trace it. Does it appear in the store, raise the alert, reach the person and get a recorded response? The Library lists a sample of log entries for a test event as evidence.

• Then: Did the test event appear, raise an alert and get a recorded response?

Decision

Did the test event appear, raise an alert and get a recorded response?

Follow the event the whole way: was it logged, did it reach the store, did the alert rule fire, did it reach a person, and did someone act and write it down? One break anywhere means monitoring would miss the real event. If you could not run the test, answer no.

• Yes: Does someone review logs and alerts on a schedule, with a record?
• No, or not known: Fix the gap, then repeat the test

Step

Fix the gap, then repeat the test

Find where the chain broke: logging off, event not forwarded, no alert rule, alert to nobody, or nobody acted. Fix that, then make a new test event. Repeat until one event runs from system to recorded response.

• Then: Make a test event and follow it from system to alert to action (back to an earlier step)

Decision

Does someone review logs and alerts on a schedule, with a record?

The auditor looks for logs that are collected but never reviewed. The privileged session review record is a model: a schedule by scope, a reviewer without rights in the area, and a follow-up for each anomaly. If the review is by habit with no record, answer no.

• Yes: Logging and monitoring decided, tested and reviewed
• No, or not known: Set a schedule, a reviewer and a record for each review

Step

Set a schedule, a reviewer and a record for each review

Weekly or monthly by risk, by someone independent of the area reviewed, with each anomaly followed up and written down. Keep the records for the whole operating period.

• Then: Logging and monitoring decided, tested and reviewed

Outcome

Logging and monitoring decided, tested and reviewed

Keep the event list, the retention decision, the alert rules, the test result and the review records. Do not claim full coverage, or that you have a security operations service, unless the sample shows every in-scope system logging and every alert handled.