ISO/IEC 27001:2022 · derived mapping target
A.8.15Logging
Produce, store and protect logs that record activity, errors and security-relevant events, so you can investigate problems and detect misuse.
Mapping at a glance
A.8.15LoggingISO/IEC 27001:2022
A.8.15 is covered by 31 Sekit CSF controls. +26 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0021Metrics & reporting · TechnicalrelatedAutomating security metrics into a dashboard depends on the same underlying event data A.8.15 requires be logged, but the dashboard reports on posture rather than producing or protecting the logs.RCF-0024Internal audit · TechnicalrelatedAutomated audit evidence collection draws on the logs A.8.15 requires exist, supporting audit efficiency rather than the logging practice itself.RCF-0027Third-party risk management · TechnicalsupportsLogging and reviewing what third parties do with their attributable accounts is a direct application of the activity logging A.8.15 requires, focused on external access.RCF-0036Issues management · TechnicalrelatedA tool that timestamps and tracks security issues shares the record-keeping discipline of A.8.15, but the entries it keeps are remediation tickets, not the system activity events A.8.15 requires logged.RCF-0051Ownership & custodians · TechnicalenablesRecording asset ownership as structured metadata lets alerts generated from logs reach the right owner automatically, a precondition for A.8.15's logs to be actionable.RCF-0071Privileged access management · ProcesssupportsLogging every use of privileged access as part of day-to-day operation is a specific, high-value instance of the activity logging A.8.15 requires.RCF-0072Privileged access management · TechnicalsupportsTechnical controls that log and alert on privileged session activity implement A.8.15's logging requirement for the accounts capable of the most damage.RCF-0087Access reviews (recertification) · TechnicalrelatedGenerating access listings from system exports depends on the same identity data A.8.15's logs capture, but serves periodic review rather than event logging.RCF-0111Data retention & disposal · TechnicalrelatedA verifiable record of secure disposal is a specific log type that shares A.8.15's evidentiary purpose without covering general system activity.RCF-0144DevSecOps governance · TechnicalrelatedAggregating pipeline security findings into one dashboard depends on logged pipeline events, extending A.8.15's logging into the development environment.RCF-0196Centralized logging · PolicyenablesStating in writing which systems must send events to a central platform and who is accountable is the policy foundation A.8.15's centralized logging depends on.RCF-0197Centralized logging · ProcesssupportsOnboarding new log sources and closing gaps on a recurring routine keeps the centralized logging A.8.15 requires complete rather than slowly incomplete over time.RCF-0198Centralized logging · TechnicalsupportsAggregating logs from servers, endpoints, network devices and cloud services into one searchable platform with retention covers the production and storage half of A.8.15, alongside the tamper-protection A.8.15 also requires.RCF-0208Log protection & retention · PolicyenablesDefining in writing how long logs are kept and what protects them from tampering is the policy precondition for A.8.15's protection and retention requirement.RCF-0209Log protection & retention · ProcesssupportsRecurring checks that retention settings match policy and stored logs remain complete verify that A.8.15's protection requirement is holding in practice.RCF-0210Log protection & retention · TechnicalsupportsWriting logs to storage ordinary admin accounts cannot alter and enforcing retention automatically covers the protection half of A.8.15, which also requires producing and storing the events in the first place.RCF-0214Telemetry coverage · PolicyenablesDefining which systems must produce security telemetry turns visibility gaps into a documented decision, the scoping step A.8.15's logging coverage depends on.RCF-0215Telemetry coverage · ProcesssupportsAssessing telemetry coverage on a recurring basis and remediating gaps keeps A.8.15's logging complete before an incident exposes a blind spot.RCF-0216Telemetry coverage · TechnicalsupportsAlerting automatically when an expected log source goes quiet closes the practical gap between A.8.15's logging requirement and a source that silently stopped working.RCF-0258Runbooks for recovery · TechnicalrelatedTooling that records what was done during an incident produces a response log that shares A.8.15's evidentiary purpose without being general system logging.RCF-0270Forensics readiness · TechnicalsupportsConfiguring systems to capture and retain forensic data automatically, through EDR telemetry and tamper-resistant log shipping, extends A.8.15's logging into incident investigation readiness.RCF-0279Post-incident review (lessons learned) · TechnicalsupportsRetaining incident timelines and response records in tooling depends directly on the activity logs A.8.15 requires, so a review can reconstruct what happened.RCF-0303Visitor management · TechnicalrelatedRecording visitor arrivals and departures produces a reviewable log, applying A.8.15's logging discipline to physical access rather than system activity.RCF-0343Cloud logging · PolicyenablesStating in writing which cloud activity must be logged and who is accountable gives A.8.15's logging requirement its scope in cloud environments.RCF-0344Cloud logging · ProcesssupportsKeeping audit logging switched on in every cloud account and reviewing logs on a schedule operationalizes A.8.15's logging requirement for cloud services.RCF-0345Cloud logging · TechnicalsupportsShipping cloud activity logs to a central store the logged users cannot alter delivers A.8.15's protected, centralized logging objective for cloud activity specifically, a slice of the servers, endpoints and network devices A.8.15 also covers.RCF-0375Control evidence management · TechnicalrelatedAutomating evidence capture into an organized library depends on the same logged activity A.8.15 produces, but the library holds compliance artifacts, not the system logs A.8.15 requires be produced and protected.RCF-0384Audit readiness · TechnicalrelatedA live view of control status and evidence completeness is built from logged data, sharing A.8.15's underlying record-keeping without being the logging control itself.RCF-0399Executive briefings · TechnicalrelatedA leadership dashboard of posture indicators is downstream of the logs A.8.15 requires, reporting on them rather than producing or protecting them.RCF-0410Availability management · ProcesssupportsRecording and reporting every availability incident depends on the activity logging A.8.15 requires, applied specifically to service availability.RCF-0417Problem management · TechnicalrelatedSurfacing incident patterns from ticketing and monitoring data depends on the logs A.8.15 produces, but serves root-cause analysis rather than logging itself.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Logging and monitoring configuration
How the company collects and keeps activity logs from its systems, and how security alerts are generated and handled.
From the Sekit evidence catalog
In practice
Logging for an SME succeeds or fails on one distinction: are logs centralized and protected, or scattered across each system's local storage where an attacker with admin rights can delete them. What works: ship logs from servers, endpoints, network devices and key cloud services into one platform, write them somewhere ordinary admin accounts cannot alter, and define retention up front. Alert on silent sources; a log feed that stops without anyone noticing looks identical to a safe system until an incident proves otherwise. Auditors ask which systems are missing from the central log platform, and how you would know if a feed went dark.
Common gaps
Logs are collected centrally for the main servers, but several cloud services and network devices were never onboarded to the platform, leaving blind spots.
Retention periods are set to defaults from the vendor rather than the values the log protection policy requires, and nobody has checked.
Administrators can delete or modify logs on the systems they manage, so an insider or attacker with admin rights could erase evidence of misuse.
Questions your auditor will ask
Which systems send their logs to the central platform, and which do not?
The centralized logging policy names every in-scope system, and a recurring onboarding review closes the gap whenever a new source is missing.
Can an administrator delete or alter logs after the fact?
No, logs are written to storage that ordinary admin accounts cannot modify or delete, and retention periods are enforced automatically by the platform.
How would you know if a log source stopped sending data?
Log source health is monitored automatically and an alert fires the moment an expected source goes quiet, rather than being discovered during an investigation.
How long are security-relevant logs kept, and is that documented?
The log protection and retention policy sets a defined period per log category, checked on a recurring basis against what is stored on the platform.
Where regulation demands it
NIS2 art. 3.2 requires monitoring and logging as part of incident detection capability. ENS op.exp.8 specifically expects activity to be logged and retained for review.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.15?”
Also via MCP, free with account