LOG-01 — Logging and Monitoring Policy and Procedures

Every framework that asks this

Answer LOG-01 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer is establishing whether your logs would surface a real compromise before the buyer's data is exposed, and whether that evidence would survive an attacker or an audit. They map three things. Coverage: are security-relevant events captured, meaning authentication and authorization outcomes, privileged and administrative actions, access to customer data, and configuration or security-control changes? Durability: how long are logs retained, and are they protected against modification or deletion, including by insiders and by the very accounts that generated them? Response: is anything actually watching, with alerts tuned to meaningful conditions and routed to a named owner or on-call rotation that has a defined reaction time? Frameworks make this explicit: NIST SP 800-53 separates AU (audit record generation, protection, retention) from SI-4 (system monitoring), and SOC 2's CC7.1 to CC7.2 ask both that you detect anomalies and that you configured detection deliberately. A reviewer reading your answer checks that all three legs are present, because a gap in any one makes the others worthless: logs nobody reads, alerts with no retention behind them, or complete collection an attacker can wipe. They also probe whether monitoring covers the systems that actually touch their data, not just the corporate network.

What a truthful, defensible answer contains

A defensible answer names the categories of events you log rather than claiming completeness: authentication and authorization outcomes, privileged and administrative actions, access to customer data, and configuration or security-control changes. It states a specific retention period, and where hot and cold or archive tiers differ, both. It describes how log integrity is protected: centralized or aggregated storage separated from the systems that produce the logs, write-once or access-controlled retention, and restrictions so operators cannot silently edit their own trail. It describes the alerting layer concretely: which conditions generate alerts, where alerts are routed, who owns the response as a named team or on-call rotation, and the expected time to acknowledge. Crucially it scopes coverage to the systems in the buyer's data path, meaning production infrastructure, the identity provider, and the datastores holding customer data, not just endpoints or the corporate network. Where coverage is partial or a capability is planned, a truthful answer says so and gives the boundary. It should map to the control the questionnaire references, such as CCM LOG, SOC 2 CC7.x, or ISO 27001 A.8.15 and A.8.16, without overstating. The point is to let the reviewer see the shape of your program, not to recite that everything is covered.

Make it traceable

Point each assertion at proof the reviewer can verify without taking your word. Reference the specific artifact behind each leg: a logging and monitoring standard for coverage and retention, citing the section that states the retention number; a sample or redacted screenshot of your SIEM or aggregation dashboard for collection; an alert-routing or on-call configuration for response; and the relevant control mapping in your latest SOC 2 or ISO report. Name the source system rather than describing it in prose, for example "authentication events are exported to [SIEM] and retained N days per [Logging Policy §X]," so the claim resolves to a document under change control rather than a sentence written for this questionnaire. Where an audit report already tests the control, cite the criterion (CC7.2) and the report date so the buyer can confirm a third party examined it. The goal is that every sentence traces to an artifact you could attach, and that the artifact would say the same thing on the day the buyer asks.

Answer patterns that hold up

• Event-coverage list, then retention period, then integrity protection, then alert-and-owner: four clauses, each naming a concrete mechanism rather than an adjective.
• Scope statement first (which systems in the data path are monitored) before any capability claim, so coverage boundaries are explicit.
• Each capability paired with the policy or system that governs it and a section reference, e.g. 'retention = N days per [Logging Policy §X].'
• Alerting described as condition, then route, then owner, then acknowledgement target, not 'we have 24/7 monitoring.'
• An explicit 'not yet / partial' clause for any leg still maturing, with the boundary stated.

Evidence that backs the answer

Red flags reviewers catch

• 'We log everything' with no retention period, integrity control, or named responder.
• A retention number with no statement that logs are protected from modification or deletion.
• Alerting described as '24/7 monitoring' with no conditions, routing, or response owner.
• Coverage described for endpoints or the corporate network but silent on production and the customer-data store.
• The answer asserts full coverage but cites no policy, system, or audit criterion behind it.

Sources

• CSA Cloud Controls Matrix (CCM) v4 — LOG domain
• NIST SP 800-53 Rev. 5 — AU (Audit and Accountability), SI-4 (System Monitoring)
• AICPA Trust Services Criteria (SOC 2) — CC7.1–CC7.2
• ISO/IEC 27001:2022 — A.8.15 Logging, A.8.16 Monitoring activities

Other Logging and Monitoring controls