Skip to main content
Control Institute
Category: Logging and Monitoring

Logging

Also known as: Event Logging, Audit Logging, Log Management
Simply put

Logging is the practice of recording events and activities that happen within an organization's IT systems, such as user logins, file changes, or system errors, so they can be reviewed later. These records, called logs, help teams understand what happened, when, and who was involved. In a compliance context, logging provides the evidence that controls are actually operating over time.

Formal definition

Logging is the systematic capture, generation, and retention of timestamped records documenting events across systems, applications, network devices, and security tools (e.g., authentication attempts, configuration changes, access to sensitive data, and error conditions). In SOC 2 examinations, logging typically supports the Common Criteria (Security) and, depending on scope, other Trust Services Criteria, serving as evidence of the design and, in a Type II engagement, operating effectiveness of monitoring and access controls over the defined review period. Under ISO/IEC 27001, logging-related activities support ISMS requirements in clauses 4 through 10 and are commonly addressed through reference controls selected via the Statement of Applicability and informed by risk assessment (Annex A control counts and identifiers vary by edition, so the applicable version should be specified). The specific events logged, retention periods, and review cadence depend on scope, applicable criteria, the auditor or certification body, and organizational risk decisions rather than a single universal rule.

Why it matters

Logging is foundational to security compliance because it produces the durable, timestamped evidence that controls are actually functioning, not merely designed on paper. In a SOC 2 examination, particularly a Type II engagement that assesses operating effectiveness over a defined review period, logs are frequently the primary artifact an auditor relies on to confirm that monitoring, access, and change-management controls operated consistently throughout that period. Without reliable logs, an organization may be unable to demonstrate that a control worked on any given day, which can weaken the resulting report.

Beyond attestation and certification, logging matters because it enables detection and reconstruction of events. When an incident is suspected, logs allow teams to answer what happened, when it occurred, and who or what was involved. This investigative value is why logging typically supports the Common Criteria (Security) in SOC 2 and is commonly addressed among the reference controls an organization selects under an ISO/IEC 27001 ISMS. It is important to keep expectations realistic, however: the presence of logging does not by itself prevent breaches, and a SOC 2 report attests only to the controls and period covered while an ISO 27001 certificate covers only the defined scope of the ISMS.

The practical stakes are that gaps in logging, events not captured, logs not retained long enough, or reviews performed inconsistently, can surface as exceptions during an examination or nonconformities during a certification audit. Because the specific events logged, retention periods, and review cadence depend on scope, applicable criteria, and organizational risk decisions rather than a single universal rule, organizations should align their logging practices to the criteria and scope actually in play for their engagement.

Who it's relevant to

Compliance and GRC Managers
Compliance managers rely on logging to demonstrate that controls operate over time, especially for SOC 2 Type II engagements where operating effectiveness is assessed across a defined period. They are typically responsible for ensuring that retention periods and review cadences align with the applicable criteria and scope, and for confirming that logging evidence maps to the controls in scope for the report or the ISMS.
Security Engineers and Operations Teams
Security engineers configure the systems, applications, network devices, and security tools that generate logs, and they operate the collection and retention mechanisms that make those logs usable. Their work determines whether events such as authentication attempts, configuration changes, and access to sensitive data are captured completely and consistently enough to support both detection and later review.
Auditors and Assessors
In a SOC 2 examination performed by a licensed CPA firm, auditors use logs as evidence of control design and, in a Type II engagement, operating effectiveness over the review period. In an ISO/IEC 27001 certification audit conducted by an accredited certification body, assessors evaluate logging-related activities against the ISMS requirements and the reference controls the organization has selected via its Statement of Applicability.
Incident Response Teams
Incident responders depend on logs to reconstruct what happened, when it occurred, and who or what was involved during and after a suspected event. The usefulness of logs to this audience is directly tied to their completeness, integrity, and retention, and it is worth noting that logging supports investigation but does not by itself guarantee freedom from breaches.

Inside Logging

Event Records
Time-stamped records capturing system, application, and user activity. In a compliance context, logging refers to the recording of security-relevant events such as authentication attempts, access to sensitive resources, configuration changes, and administrative actions, so that activity can be reconstructed and reviewed.
Log Sources
The systems that generate log data, which typically include operating systems, applications, databases, network devices, firewalls, identity providers, and cloud platform audit trails. The set of in-scope sources depends on the boundary of the SOC 2 examination or the ISO 27001 ISMS scope.
Centralized Aggregation
The practice of collecting logs from multiple sources into a centralized store or log management/SIEM platform. Aggregation supports correlation across systems and is commonly implemented to make review and monitoring practical, though the specific tooling varies by environment.
Retention Configuration
Settings that determine how long logs are kept and how they are protected from alteration or deletion. Retention periods are set by scoping decisions, organizational policy, and any applicable obligations rather than by a single universal rule; the SOC 2 Type II review period and the ISO 27001 risk assessment often inform these choices.
Review and Monitoring
The process of examining logged data, whether through periodic manual review or automated alerting, to detect anomalous or unauthorized activity. Logging on its own records events; monitoring is the activity that turns those records into detection of potential issues.
Integrity and Access Controls
Mechanisms that protect log data from tampering and restrict who can view or modify it, such as restricted access, write-once storage, or integrity verification. These controls help preserve the evidentiary value of logs during a SOC 2 examination or ISO 27001 assessment.
Framework Relevance
Within SOC 2, logging and monitoring activities commonly support the Security category (the Common Criteria), which is the only required Trust Services category. Within ISO 27001, logging is addressed by reference controls in Annex A that are selected via the Statement of Applicability and informed by risk assessment; the specific control identifiers and count depend on the edition (for example, the 2022 revision restructured Annex A into 93 controls across four themes).

Common questions

Answers to the questions practitioners most commonly ask about Logging.

Does having comprehensive logging mean my organization is protected from breaches?
No. Logging captures records of events but does not, on its own, prevent security incidents. In the context of security compliance, logging is a detective control that supports investigation, monitoring, and accountability after events occur. Its value depends heavily on whether the logs are actually reviewed and acted upon. A SOC 2 report or ISO 27001 certificate that reflects logging controls attests only to the controls and, for a SOC 2 Type II, the review period covered, and does not guarantee freedom from breaches. Logging typically works alongside monitoring, alerting, and response processes rather than replacing them.
Do SOC 2 and ISO 27001 require the exact same logging controls, so satisfying one covers the other?
Not exactly. Both frameworks address logging, but they do so through different structures and mapping between them is partial. In SOC 2, logging-related expectations are generally addressed within the Security category (the Common Criteria), while under ISO 27001 logging is treated as one of the reference controls in Annex A, selected via the Statement of Applicability and informed by the organization's risk assessment. Because the frameworks differ in how they scope, assess, and evidence controls, satisfying logging requirements under one does not automatically satisfy the other. The specific controls implemented also depend on scope and the decisions of the auditor or certification body.
What kinds of events should typically be logged?
The specific events depend on your scope, risk assessment, and applicable criteria, so there is no single universal list. In most engagements, organizations aim to capture events that support security monitoring and accountability, which can include authentication activity, access to sensitive systems or data, administrative and privileged actions, and changes to configurations. The appropriate set is generally determined by the risks you have identified and the systems within the defined scope of your SOC 2 examination or ISO 27001 ISMS, rather than a fixed checklist.
How long should logs be retained?
Retention periods vary and are typically set by scoping decisions, organizational policy, applicable obligations, and risk considerations rather than a single fixed duration. Neither framework prescribes one universal retention figure that applies to every organization. For a SOC 2 Type II, retention should generally be sufficient to demonstrate operating effectiveness across the defined review period, and for ISO 27001 it should align with the ISMS and the organization's own documented requirements. Because requirements depend on context, retention should be documented and justified rather than assumed.
How is logging evidenced during a SOC 2 or ISO 27001 assessment?
Evidence expectations depend on the framework and the assessor. For a SOC 2 Type I, evidence typically demonstrates that logging controls are suitably designed at a point in time, while a SOC 2 Type II typically requires evidence that logging operated effectively over the defined review period, such as samples of logs and records of log review activity. For ISO 27001, evidence generally shows that the selected logging controls are implemented consistently with the Statement of Applicability and the ISMS requirements in clauses 4 through 10. The precise artifacts requested vary by auditor, certification body, and scope.
Should logs be protected, and how is that typically handled?
Yes, protecting logs is generally important because logs can be a target for tampering and can contain sensitive information. In most engagements, organizations restrict access to logs, protect their integrity against unauthorized modification, and consider confidentiality where logs contain sensitive data. Under ISO 27001, these protections are selected as part of the applicable reference controls and informed by risk assessment, and under SOC 2 they are addressed within the relevant Trust Services Criteria in scope. The specific safeguards depend on your scope, risk profile, and the applicable criteria.

Common misconceptions

Enabling logging automatically satisfies a SOC 2 examination or ISO 27001 requirements.
Generating logs is only part of the expectation. In most engagements, an auditor or certification body also looks for evidence that logs are protected, retained, and actually reviewed or monitored. A SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined ISMS scope; neither is achieved by log generation alone.
Logging controls implemented for SOC 2 automatically meet ISO 27001's logging expectations, and vice versa.
Mapping between SOC 2's Trust Services Criteria and ISO 27001's Annex A reference controls is possible but partial. Satisfying logging expectations under one framework does not automatically satisfy the other, because scope, selected criteria, and the certification body's or auditor's judgment differ.
There is a fixed, mandatory log retention period that applies to every organization.
Retention periods depend on scope, policy, the applicable criteria, and, for SOC 2 Type II, the defined review period, which itself varies by scoping decisions. Rather than a single universal figure, retention is typically set based on organizational and risk considerations.

Best practices

Define the in-scope log sources to align with the boundary of your SOC 2 examination or ISO 27001 ISMS scope, so that security-relevant events across systems, applications, and infrastructure are captured.
Centralize and correlate logs where practical, so that activity across multiple systems can be reviewed and analyzed together rather than in isolation.
Protect logs from unauthorized access and tampering using restricted access and integrity controls, preserving their evidentiary value during an examination or assessment.
Set retention periods based on organizational policy, risk assessment, and applicable criteria, and, for SOC 2 Type II, ensure retention covers the defined review period rather than assuming a fixed universal duration.
Pair logging with active monitoring or alerting and document a defined review cadence, since recording events is only effective if the records are examined for anomalous or unauthorized activity.
Retain evidence of review activity (such as records of who reviewed logs, when, and what actions followed) to demonstrate operating effectiveness, which is particularly relevant for a SOC 2 Type II engagement.