Skip to main content
Control Institute
Category: Logging and Monitoring

Log Management

Also known as: Log Data Management, Centralized Logging
Simply put

Log management is the ongoing process of collecting, storing, organizing, and analyzing the records (logs) that software, systems, networks, and devices automatically generate about their activity. Centralizing these logs helps teams monitor what is happening across an environment, investigate issues, and turn large volumes of raw data into actionable insights. In a compliance context, well-managed logs typically support the detection, investigation, and evidence needs that auditors and certification bodies expect, though the specific requirements depend on scope and applicable criteria.

Formal definition

Log management is the continuous, end-to-end handling of computer-generated log data, typically encompassing collection, parsing, centralized storage, analysis, and eventual disposal to produce actionable insights. It aggregates logs from diverse sources, applications, systems, networks, and devices, into a centralized repository to enable monitoring, correlation, and retention. In SOC 2 engagements, logging and monitoring practices commonly serve as evidence of operating effectiveness for controls addressed under the Security (Common Criteria) category, though the exact controls tested depend on scoping decisions and the auditor's approach. In ISO/IEC 27001, logging supports ISMS operation and may relate to reference controls selected via the Statement of Applicability and informed by risk assessment; specific control references and their numbering depend on the version of the standard in use. Log management alone does not guarantee freedom from breaches and does not by itself satisfy the requirements of either framework.

Why it matters

Logs are the primary record of what actually happened across an environment, which makes log management foundational to both security operations and compliance evidence. When systems, applications, networks, and devices continuously generate activity records, centralizing and organizing that data is what allows teams to move from raw noise to actionable insight, detecting anomalies, investigating incidents, and reconstructing timelines after the fact. Without disciplined collection and retention, the data needed to answer basic questions about an incident may simply not exist when it is required.

In a compliance context, log management typically underpins the detection, investigation, and evidence needs that auditors and certification bodies expect to see. In SOC 2 engagements, logging and monitoring practices commonly serve as evidence of operating effectiveness for controls addressed under the Security (Common Criteria) category, though the specific controls tested depend on scoping decisions and the auditor's approach. In ISO/IEC 27001, logging supports the operation of the ISMS and may relate to reference controls selected via the Statement of Applicability and informed by risk assessment; the precise control references and numbering depend on the version of the standard in use.

It is important to keep expectations calibrated: log management alone does not guarantee freedom from breaches, and it does not by itself satisfy the requirements of either framework. A well-run logging program improves the odds of timely detection and produces the artifacts an examiner or certification body needs, but it is one component within a broader control environment rather than a standalone assurance of security.

Who it's relevant to

Compliance and GRC managers
Log management produces much of the evidence used to demonstrate detection, monitoring, and investigation capabilities during audits and certification activities. GRC teams rely on centralized, retained logs to respond to evidence requests, but should recognize that the specific controls and retention expectations depend on scope and applicable criteria rather than a fixed rule.
SOC 2 auditors and assessors
In SOC 2 engagements, logging and monitoring practices commonly serve as evidence of operating effectiveness for controls addressed under the Security (Common Criteria) category. The exact controls tested and the sampling approach depend on scoping decisions and the auditor's methodology.
ISO/IEC 27001 implementers and certification bodies
Logging supports the operation of the ISMS and may relate to reference controls selected through the Statement of Applicability and informed by risk assessment. The relevant control references and their numbering depend on the version of the standard in use, and the certificate covers only the defined scope of the ISMS.
Security engineers and operations teams
These practitioners own the collection, parsing, centralized storage, and analysis pipeline day to day. They turn large volumes of computer-generated log data into monitoring, correlation, and investigation capabilities, and manage retention and disposal across the log lifecycle.

Inside Log Management

Log Collection
The aggregation of event records from systems, applications, network devices, and security tools into a centralized location. In most SOC 2 engagements and ISO 27001 implementations, centralized collection supports the ability to demonstrate monitoring activities across the defined scope.
Log Retention
The defined period for which log data is preserved. Retention duration is typically driven by scoping decisions, applicable criteria, and organizational risk assessment rather than a single fixed figure, and it varies across engagements and certification scopes.
Log Review and Monitoring
The ongoing examination of collected logs to detect anomalies, unauthorized activity, or security events. For a SOC 2 Type II examination, evidence that review occurred consistently over the review period is generally relevant, whereas a Type I addresses only the suitability of design at a point in time.
Log Integrity and Protection
Controls that guard logs against unauthorized alteration or deletion, such as access restrictions and tamper-evidence measures. These support the reliability of logs as evidence but do not, on their own, guarantee completeness across systems outside the defined scope.
Alerting and Escalation
The mechanisms that flag notable events to responsible personnel and route them for response. The specific thresholds and escalation paths depend on scope, applicable criteria, and the organization's risk decisions rather than being universally mandated.
Relationship to Framework Criteria
Log management typically supports the Security category (the Common Criteria) under the SOC 2 Trust Services Criteria and can inform ISO 27001 Annex A reference controls selected via the Statement of Applicability. The applicable Annex A control references and counts depend on the version of the standard, and the Trust Services Criteria should not be conflated with Annex A controls.

Common questions

Answers to the questions practitioners most commonly ask about Log Management.

Does implementing log management make my organization SOC 2 or ISO 27001 compliant?
No. Log management is one supporting practice among many, and no single control or approach makes an organization compliant with either framework on its own. In a SOC 2 examination, logging typically supports certain Common Criteria and, depending on scope, other Trust Services Criteria, but a licensed CPA firm evaluates the full set of controls in scope. For ISO 27001, logging may support controls selected through the Statement of Applicability, while certification depends on the overall ISMS requirements in clauses 4 through 10. Log management contributes to, but does not by itself establish, compliance.
Is there a fixed log retention period that both frameworks require?
Not universally. Neither framework prescribes a single mandatory retention duration that applies to all organizations. Retention expectations typically depend on scope, applicable criteria, risk assessment outcomes, and the auditor or certification body's evaluation, as well as any legal or contractual obligations relevant to the organization. It is better to define retention based on those factors than to assume a specific number of days or months applies in every case.
How does log management support a SOC 2 Type II examination differently from a Type I?
A SOC 2 Type I assesses the suitability of the design of controls at a point in time, so logging evidence would typically demonstrate that logging controls are designed appropriately as of that date. A Type II assesses both design and operating effectiveness over a defined review period, so log-related controls would typically need to show consistent operation throughout that period. Because the period length is set by scoping decisions rather than fixed, the volume and continuity of log evidence expected can vary by engagement.
What sources should feed into a log management program for compliance purposes?
The appropriate sources depend on scope and the risks identified during assessment. In most engagements, organizations consider logs from systems and components within the defined scope, which may include authentication events, access to sensitive data, configuration changes, and security-relevant activity. For ISO 27001, the sources relevant to selected Annex A controls would be informed by the risk assessment and documented through the Statement of Applicability. For SOC 2, sources would align with the Common Criteria and any additional Trust Services Criteria selected. The specific set of sources should be determined by scope rather than assumed.
How should we handle review and monitoring of logs to satisfy an auditor or certification body?
Both frameworks generally value evidence that logs are not only collected but also reviewed or monitored in a way consistent with the organization's stated controls. In a SOC 2 examination, an auditor typically looks for evidence that review activities operated as designed over the period covered for a Type II. For ISO 27001, review practices would typically be evaluated against the controls selected and the ISMS requirements. The specific cadence and depth of review depend on scope, risk, and the evaluator, so organizations should document their approach and be able to demonstrate it operated as described.
Does having strong log management for ISO 27001 mean we are covered for SOC 2, and vice versa?
Not automatically. While logging practices can support both frameworks and some mapping between them is possible, satisfying one framework does not automatically satisfy the other. SOC 2 is an attestation examination performed by a CPA firm resulting in a report, while ISO 27001 is a certification issued by an accredited certification body against a management system standard. The criteria, evidence expectations, and evaluation processes differ, so log management evidence may need to be framed and reviewed differently for each. Any overlap is partial and should be validated against the specific criteria in scope.

Common misconceptions

Passing a SOC 2 examination or achieving ISO 27001 certification means log management guarantees no breaches will occur.
A SOC 2 report attests only to the controls and period covered and does not guarantee freedom from breaches, and an ISO 27001 certificate covers only the defined scope of the ISMS. Log management supports detection and evidence but does not eliminate risk.
There is a single mandatory log retention period that satisfies both SOC 2 and ISO 27001.
Retention periods are typically set by scoping decisions, applicable criteria, and risk assessment, and they vary by engagement and certification body. Neither framework prescribes a universal fixed duration for all organizations.
Log management controls that satisfy SOC 2 automatically satisfy ISO 27001, since both cover logging.
Mapping between the two frameworks is possible but partial. SOC 2 is an attestation examination under the AICPA SSAE 18 standard resulting in a report, while ISO 27001 is a certification against a management system standard; satisfying one does not automatically satisfy the other, even for overlapping topics such as logging.

Best practices

Centralize log collection across systems within your defined scope so that monitoring evidence can be demonstrated consistently, recognizing that logs cover only the systems included in the scope.
Define log retention periods based on your risk assessment and applicable criteria, and document the rationale rather than assuming a single fixed duration applies.
For a SOC 2 Type II examination, maintain evidence that log review and monitoring occurred throughout the review period, since operating effectiveness over time is assessed in addition to design.
Protect log integrity with access restrictions and tamper-evidence measures so logs remain reliable as audit evidence.
Where ISO 27001 applies, map logging activities to the relevant Annex A reference controls through your Statement of Applicability, and specify the version of the standard when citing control references.
Treat SOC 2 and ISO 27001 logging requirements as overlapping but distinct, and validate each against its own criteria rather than assuming one framework's satisfaction carries over to the other.