ISO 27001 Annex A 8.15 logging: record, protect, review

The due-diligence questionnaire asks how you would detect misuse of client data, and the honest answer is "we'd check the logs". Then the auditor asks for sign-in records from three months ago, and the default retention has already erased them.

This guide explains what ISO 27001 Annex A 8.15 requires, how to build a lean logging pipeline from tools you already pay for, and what auditors sample. It is written for security managers and IT heads at UK firms of 25–250 people who need evidence without an enterprise SIEM budget.

What does ISO 27001 Annex A 8.15 logging require?

ISO 27001 Annex A 8.15 requires logs of security-relevant events that you create, keep, protect and actually use. Systems that matter must record sign-ins, privilege use, configuration changes and data access in enough detail to reconstruct an incident, nobody can rewrite their own trail, and someone reviews the output.

The control splits into three legs, and an auditor tests each one separately:

• Record. Systems that matter capture sign-ins and failures, privilege use, configuration changes and data access, in enough detail to reconstruct what happened.
• Protect. Nobody, administrators included, can rewrite or erase the record of their own actions.
• Analyse. Someone or something looks at the output, so anomalies become investigations rather than archive filler.

A.8.15 is a detective control. Logging stops nothing, but it makes violations visible, provable and attributable after the fact, across confidentiality, integrity and availability.

Three neighbouring controls set the boundaries. ISO 27001 A.8.16 monitoring watches events in real time and raises alarms, while logging builds the historical record that monitoring watches and investigators rely on. A.8.17 requires synchronised clocks so events from different systems line up, and A.5.34 brings privacy duties to logs because they are full of personal data.

Without logs, an incident is unanswerable. You cannot scope what was taken, so under UK GDPR you notify the ICO on worst-case assumptions, and an enterprise customer's lawyers assume the worst as well. Your insurer's forensics team then bills days reconstructing what a log query should have answered in minutes.

Which events and fields should every A.8.15 log entry capture?

Each entry should answer four questions: who (the account), what (the event type), when (a trustworthy timestamp) and where (the system and source address). The event set should include authentication successes and failures, privilege elevation, identity changes, configuration changes, sensitive data access and security tooling being switched off.

Most platforms capture these fields by default. The failure mode is switching detail off to save cost, which trades a small saving for blind spots. The NCSC introduction to logging for security purposes lists account names and source IP addresses among the fields to confirm are actually logged, and recommends UTC timestamps throughout.

Check one sampled entry from each in-scope system against four points:

• Account. A named individual or a traceable service identity, not a shared admin login.
• Event type. Success and failure are distinguishable, so a failed sign-in never looks like an ordinary one.
• Timestamp. Recorded consistently, preferably in UTC, from a synchronised clock.
• System and source. The host or application, plus the address the action came from.

If a sampled entry cannot answer "who did what, when, from where", the detail level is set too low. Raise it before the auditor samples it for you.

The event set is a written decision, not a default. Security tooling being switched off deserves its own alert, because an agent disabled or a log setting turned down is itself a top-tier signal that someone wants a quiet window.

What does ISO 27001 logging monitoring Annex A architecture look like across cloud and SaaS?

Start with the logs you already own: the cloud provider's audit trail, the Microsoft 365 or Google Workspace audit log and the identity provider's reporting. Turn retention up, scope by risk rather than by default-on, and pull the sources into one queryable place before buying any additional platform.

Write a short logging policy first. For each in-scope system, it answers three questions: which events are recorded, how long they are kept and how they are protected. That page doubles as the ISO 27001 logging and monitoring policy an auditor will ask to see.

Scope the first wave by risk:

• Identity provider. Sign-ins, failures, MFA changes and role grants.
• Cloud control plane. Who changed what in the AWS, Azure or GCP account.
• Production application. Authentication and access to sensitive data.
• Finance and HR systems. The records most exposed to misuse by insiders.

Tie each row of the policy to an asset register entry, so adding a system to the register prompts the question "does it log?".

Sequence matters more than tooling. Switching native logging on and extending retention is cheap, and the history only exists if you started, so do it in the first weeks of the programme. Centralisation and alerting mature mid-programme, alongside the monitoring work for A.8.16.

The classic mistake is logging everything indiscriminately. Storage cost runs away, alert fatigue sets in and the few signals that matter drown in noise. The risk-scoped policy is what keeps your storage bill and your alert queue proportionate.

Do 25–250 staff firms need an enterprise SIEM to meet ISO 27001 A.8.15?

No. Native cloud, workspace and identity-provider logging with extended retention, pulled into one queryable place, satisfies the control for most firms of 25–250 people. A SIEM or managed detection and response service becomes worthwhile when the analysis burden outgrows the team. Buy the outcome, not the acronym.

The audit tests outcomes: a record that exists, a record nobody can rewrite and evidence that someone looks. A SIEM is one way to deliver the third, not a prerequisite for the first two. Native logging at this size already produces the record, and one queryable store lets a single person run the weekly review.

A SIEM or MDR service starts to earn its cost for reasons that have little to do with the audit:

• Alert volume outgrows the person triaging it.
• Nobody watches outside working hours and your risk assessment says someone should.
• The estate has grown past what native tooling can correlate in one place.

Steady state at this scale is a small monthly storage cost and a couple of hours a week of review, or an MDR subscription that does the watching. Either route passes when the evidence is in place. Buying a platform before you have coverage only gives you an expensive way to aggregate very little.

How do you stop administrators altering or deleting their own logs?

Ship logs off the systems that generate them into append-only or restricted storage, and make sure administrator rights on a source system do not include editing its shipped history. Then alert when a source stops reporting, because a silent forwarder failure leaves a hole exactly where an incident happens.

Four mechanisms make the protect leg demonstrable:

1. Ship off-host. Forward events as they are generated to a separate account, workspace or storage service, so the source system never holds the only copy.
2. Restrict the store. Use append-only or immutability settings, give forwarders write-only permission and limit read access to a named few.
3. Separate the rights. Administrators of a source system get no rights over its shipped history, and the people who administer the log store are not the people the logs record.
4. Alert on silence. Define how often each source should report and raise an alert when it does not. A missed-heartbeat alert costs little, and without one a forwarder that stopped weeks ago is found only when someone queries the gap.

The auditor's challenge is blunt: could one of your administrators delete the record of their own session, and can you prove they cannot? The proof is configuration evidence, meaning storage settings and access control lists, backed by a demonstration that the administrator account is refused.

How long should you keep logs under ISO 27001 and UK GDPR?

Set retention per source against forensic, contractual and regulatory needs. The NCSC recommends holding incident-critical logs for at least six months, and twelve months for access logs is a common working norm. The ICO expects you to justify how long you keep personal data, so document a schedule and mask identifiers before extracts leave.

The NCSC introduction to logging for security purposes ties the six-month figure to your incident questions: hold the logs that answer them for a minimum of six months. Treat that as a floor for incident-critical sources. System noise, such as routine health checks, can be kept far shorter.

There is no single mandated figure for an ISO 27001 log retention period. What the auditor tests is that you have a rationale and that reality matches it.

The ICO guidance on UK GDPR storage limitation is the counterweight. You must not keep personal data for longer than you need it, and you must be able to justify the period. Logs carry account names and IP addresses, so they are personal data, and "just in case" is not a justification.

A defensible retention schedule records, for each source:

• the purpose the log serves, such as forensics, contract or regulation
• the retention period and the reason for that number
• the storage tier and who can read it
• the point of deletion and the automation that performs it

Retention you cannot justify is a liability, not a safeguard.

Masking closes the other leak path. Vendor troubleshooting is the classic one: a support engineer asks for a log extract and receives raw usernames, addresses and tokens. Strip or pseudonymise identifiers before any extract leaves your control, and keep a note of the step as evidence.

The pitfall is treating logs as exempt from privacy rules. With proportionate retention, restricted access and masking in place, logging and UK GDPR coexist without friction.

How do you move from write-only logging to reviews you can prove?

Pair alerts on events that should never happen quietly, such as a new global admin, an impossible-travel sign-in or a disabled security agent, with a short weekly review habit. Record each review and each alert's path from firing to closure, so analysis is demonstrable rather than anecdotal.

A weekly review at this scale looks through four lenses:

• failed sign-in patterns, especially against privileged accounts
• new privileged accounts or role grants
• sources that reported less than expected
• alerts that fired and how each one closed

Record every alert's path in the same shape:

1. Fire. The rule triggers and creates a ticket automatically.
2. Triage. A named person reads it within the agreed window.
3. Decide. Benign, investigate or escalate, with the reason written down.
4. Close. A dated closure note links back to the evidence.

A logging estate nobody queries is an archive with a monthly invoice.

Tune as you go. A rule that fires daily and is always dismissed should become either a sharper rule or a deleted one, because noise teaches the reviewer to stop looking.

Write-only logging is the failure this habit prevents: years of archives, no queries and no alerts, found to be useless or incomplete during the first real incident.

What do auditors sample when they test A.8.15 logging?

Auditors test depth, integrity and analysis. Expect a request for sign-in logs from a day three months ago, a challenge to prove administrators cannot delete their own session record, and a request to follow one real alert from firing to closure. Cloud and SaaS sources are checked against the asset register for gaps.

Expect five questions in the room:

• "Pick a day three months ago and show me the production sign-in logs."
• "Could an administrator delete the record of their own session? Prove they cannot."
• "Who looked at the logs last week, and what did they look for?"
• "Show me the alert that fires when someone gains admin rights, and the last time it fired."
• "What is your retention, and why that number?"

Prepare by running the retrieval yourself. Pick a date ninety days back, pull the identity provider sign-ins and time the exercise. If it takes minutes, you pass the cheapest test in the audit.

Certification bodies grade logging findings by how much of the control is missing. No logging on the systems that matter, or logs demonstrably editable by the people they record, counts as the requirement being absent and grades major. Retention short of your stated policy, a source silently dead for weeks or thin review evidence grades minor. A pattern of minors can aggregate to a major: "we collect but never look".

Bring an evidence pack to the room:

• the logging policy with its per-source scope and retention schedule
• central platform configuration showing sources, retention and restricted access
• sample entries that show who, what, when and where
• tamper-resistance settings, proof of time synchronisation and alert and review records

How do you automate A.8.15 evidence with GRC engineering?

Define log sources, routing, retention and access as code, so coverage is reviewable and rebuildable. Reconcile connected sources against the asset register on a schedule, keep alert rules in version control, and automate retention from hot storage to archive to deletion. Audit questions then become queries rather than projects.

Coverage reconciliation does the most work. A scheduled job diffs the connected-sources list against the asset register, and a system that exists but does not report becomes a ticket. Forwarder health alerting catches a source going quiet between runs.

Detection as content treats alert rules like code: held in version control, tuned through review, with every firing writing its own review trail. Retention lifecycle automation ages hot storage into cheap archive and then into deletion on policy, which resolves the tension between forensics and minimisation mechanically.

The query you write for the auditor is the query you run on the worst day of an incident.

Frequently asked questions