Control Definition
Logs recording activities, exceptions, faults, and other relevant events must be produced, stored, protected against tampering and unauthorized access, and analyzed. The control covers the full log lifecycle — deciding what to capture, keeping it safely for as long as needed, and actually looking at it.
Control Objective
To record events and generate tamper-resistant evidence that supports incident investigations and surfaces security events before they become incidents.
What This Really Means
Logs are the flight recorder of your environment: when something goes wrong, they are the only honest witness to what actually happened, in what order, done by whom. The control has four verbs — produce, store, protect, analyze — and organizations reliably fail on a different one than they expect. Producing logs is easy; protecting them from the very administrators they record, and proving someone analyzes them, is where the work lives.
Produce means deciding, per system type, which events are captured: user activities such as log-ons and access to sensitive data, privileged and administrative actions, exceptions and faults, configuration changes, and security events like repeated authentication failures or alerts from protection tooling. Each record needs enough context to reconstruct the event — a reliable timestamp, the identity involved, the source, the action, and the outcome. Two restraint rules apply: do not log secrets (passwords, tokens, full card numbers), and do not hoover up personal data you will then have to govern under privacy law.
Protect is the half auditors probe hardest, because logs are evidence and evidence invites tampering. The standard expectation is forwarding logs in near-real time to a separate, access-controlled platform — a log management system or SIEM — so an attacker or insider who controls a server cannot quietly rewrite its history. Access to stored logs is read-only for almost everyone, and critically, the administrators of a system should not be able to modify or delete the logs of that same system: that is segregation of duties (A.5.3) applied to evidence. Retention is set by two inputs — how far back investigations realistically need to look, and what law or contract mandates.
Analyze is what makes the rest worth paying for: logs nobody reads are a storage bill, not a control. A.8.15 expects logs to feed review and correlation — in practice, the alerting and monitoring activity formalized in A.8.16. At audit time the heart of the control is threefold: coverage (in-scope systems demonstrably send logs), protection (tampering is technically prevented, not just forbidden), and life signs (alerts fire, get triaged, and leave tickets).
Why It Matters
Almost every security capability degrades without logs. Incident response becomes guesswork: you cannot answer when the attacker got in, what they touched, or whether they are still present — and breach notification decisions, which run on legal clocks, end up made blind. Attackers know this, which is why clearing or disabling logs is a standard early move in real intrusions; a copy already forwarded to a separate platform is the difference between an investigation and an apology.
Logging is also the control that watches the watchers. Privileged users — system administrators, DBAs, cloud platform owners — operate above most preventive controls, and their actions are only governable if independently recorded. The same records carry legal weight: in disciplinary processes, disputes, and regulatory investigations, log evidence stands or falls on whether its integrity can be defended.
Weak logging exposes the organization to:
- •Blind incident response – no reliable answer to "what happened, when, and how far did it spread", so containment and notification decisions are made on guesses
- •Evidence that does not survive challenge – logs an administrator could have edited carry little weight in disciplinary, legal, or regulatory proceedings
- •Invisible insider and privileged misuse – without independent recording of admin actions, your most powerful accounts are also your least accountable
- •Extended attacker dwell time – intrusions that would surface in reviewed logs instead run for months, multiplying impact
- •Regulatory exposure – log retention mandates carry direct penalties, and an unscopeable personal data breach is treated far more harshly than a well-evidenced one
Regional Compliance Context
India. CERT-In's directions make log retention a legal mandate, not a judgment call: organizations with India-connected ICT systems must enable logs of all their ICT systems, retain them securely for a rolling period of 180 days, maintain them within Indian jurisdiction, and be able to furnish them to CERT-In when reporting an incident or when directed. Design your retention floor and storage location with this in mind. The DPDP Act 2023 adds an indirect driver — scoping and notifying a personal data breach is only possible if access logs existed in the first place — and a reflexive one: logs themselves often contain personal data, so they belong in your data inventory with their own retention limits. RBI-regulated entities and SEBI CSCRF market intermediaries face further supervisory expectations around centralized log collection and security monitoring.
Implementation Guidance
Define a Logging Standard
Document, per system class, which events must be captured: authentication successes and failures, privileged and administrative actions, access to sensitive data, configuration and permission changes, exceptions, faults, and security tool alerts. Specify required fields — timestamp, identity, source, action, outcome — and the restraint rules: no secrets in logs, and personal data minimized or masked.
Inventory Log Sources and Enable Logging Across Scope
Map the asset register to log sources: operating systems, applications, databases, network and security devices, cloud control planes (CloudTrail and Azure Activity Logs are the canonical examples), and the audit logs of in-scope SaaS platforms. Maintain a coverage matrix and record every gap with a reason — undocumented gaps are findings waiting to be sampled.
Forward Logs to a Separate, Access-Controlled Platform
Ship logs in near-real time to a central log management system or SIEM that sits in its own administrative domain. Forwarding is the protection mechanism: once events have left the source system, whoever compromises that system can no longer rewrite its history. Verify forwarding end-to-end with test events, not just agent install counts.
Protect Log Integrity and Restrict Access
Make stored logs effectively append-only: read-only roles for analysts, no modify or delete rights for the administrators of source systems (segregation per A.5.3), and immutability or WORM retention where the platform supports it. Alert on the tampering signals themselves — audit logging disabled, logs cleared, retention settings changed, a source falling silent.
Set Retention by Need and by Law
Combine the operational lookback your investigations need with every legal and contractual mandate — CERT-In's 180-day rolling retention for India-connected systems is a hard floor, and other frameworks set their own (PCI DSS, for example, expects 12 months). Tier storage hot and cold to control cost, document the schedule per source type, and apply secure disposal at end of retention.
Establish Analysis and Review
Stand up automated correlation and alerting for the events that matter most — privileged group changes, log clearing, repeated authentication failures, anomalous access patterns — feeding the monitoring activity under A.8.16. Define who triages alerts, in what timeframe, and where the outcome is recorded; an alert queue without an owner is decoration.
Test the Pipeline and Audit the Control
Periodically prove the system works end-to-end: generate a test event and watch it land; reconcile the coverage matrix against the asset register quarterly; retrieve a months-old log to prove retention is real; and confirm timestamps align across sources (clock discipline per A.8.17). Include these checks in the internal audit program.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.15:
Documentation
- Logging standard or policy defining events captured, required fields, protection, and retention per system class
- Log source coverage matrix reconciled against the asset register, with justified exclusions
- Access control configuration for the log platform showing read-only analyst roles and segregated administration
- Retention configuration plus a sample retrieval of aged logs proving the schedule holds in practice
- Alert triage records — tickets raised from log alerts with owners, timestamps, and outcomes
Interviews
- SOC analyst or engineer who handles log alerts, on what fires, who triages it, and within what timeframe
- System or platform administrator, on whether they can modify or delete the logs of systems they administer
- CISO or IT manager, on how retention periods were derived from investigation needs and legal requirements
Observations
- Live log platform or SIEM console showing in-scope sources actively reporting and recent event flow
- Demonstration that source-system administrators lack delete rights on stored logs, or immutability settings in effect
- Alerting configuration for tampering signals — audit logging disabled, logs cleared, or a source going silent
Practitioner Insights
When I sample this control, I take the asset register and ask the log platform which of those systems it has heard from in the last 24 hours — the silence is where the findings live. A pattern across audits: a critical application that was never enrolled, or stopped forwarding months ago, with no alert configured to notice. The second probe is privilege: if the administrators of a system can clear or edit that system's logs, your evidence is only as trustworthy as your most disgruntled admin. Coverage reconciliation and segregated log administration are what I look for before anything else.
Small companies talk themselves out of this control because they price it as an enterprise SIEM and a 24x7 SOC, and neither is required. Cloud-native audit trails switched on, forwarded to a separate log workspace the engineers cannot edit, with a handful of alerts that matter — admin role changes, audit logging disabled, repeated authentication failures — satisfies A.8.15 at startup scale. The two mistakes to avoid are logging everything at maximum verbosity, which buries signal under cost, and logging secrets or personal data you then have to govern. Start from one question: which events would you need to reconstruct your worst plausible incident?
Common Challenges & Solutions
Challenge
Log volume and platform costs explode, and the response is to quietly switch sources off.
Solution
Manage volume by design instead of by amputation: log the events your standard defines rather than everything at debug level, filter known noise at the source, and tier storage — recent logs hot and searchable, older logs in cheap cold storage that still satisfies retention. Review the top-volume sources quarterly; one chatty load balancer often costs more than every security log combined.
Challenge
Administrators can edit or delete the logs of the systems they manage, so the audit trail proves nothing.
Solution
Forward logs off the source system in near-real time to a platform under a different administrative domain, give source-system admins no write access to it, and enable immutability or WORM retention where available. Then alert on the tampering signals — audit policy changes, cleared logs, silent sources. The goal is that erasing history requires compromising two separately controlled systems.
Challenge
Coverage silently decays — new systems launch without log enrollment and nobody notices until an investigation hits a blank.
Solution
Make log enrollment a go-live gate in change and release management, reconcile the coverage matrix against the asset register quarterly, and alert when an enrolled source stops sending. Treat a silent source with the urgency of a failed backup: both are controls that only reveal their absence when you need them.
Challenge
Logs are collected diligently and analyzed never — the platform is a write-only archive.
Solution
Start with a small, high-signal alert set: privileged group membership changes, audit logging disabled, log clearing, repeated authentication failures, first-time admin access from new locations. Route each alert into the ticketing system with a named owner and a triage deadline, and tune monthly to keep false positives survivable. Ten alerts that get read beat ten thousand that do not — and the triage tickets become your audit evidence for the "analyze" verb.
Challenge
Retention is misaligned with legal mandates, or old logs technically exist but cannot actually be retrieved.
Solution
Derive retention from the legal register (A.5.31) — in India, CERT-In's 180-day rolling retention for ICT system logs is the explicit floor — plus your own investigation lookback needs. Then prove it semi-annually by actually retrieving a log from deep in the retention window; archived-but-unretrievable storage fails both the auditor and the regulator at the same moment.
