Home · Synthesis · cl-logging

Centralised logging with retention, tamper protection, and integrity

CERT-In ISO 27001 RBI CSF RBI ITGRCA NIST CSF 2.0 PCI DSS SEBI CSCRF CIS Controls v8.1 CSA CCM v4 IRDAI 2026 MeitY CSP NIST 800-53 SEBI Cloud

Primary statement

Logs of activities, exceptions, faults, and security events shall be: (1) produced on ALL ICT systems including servers, network devices, cloud instances, applications, databases, IoT, and OT/SCADA; (2) centrally collected with tamper protection (write-once or cryptographic hashing); (3) time-synchronised via NTP; (4) retained for a minimum operationally-meaningful period (12 months active, longer per sectoral expectations); (5) analysed in near-real-time via SIEM for security events. The logging fabric is the foundation for detection, incident response, audit, and forensic investigation.

Audit-fatigue payoff

A unified logging fabric — SIEM with coverage matrix, retention configuration, tamper protection evidence, NTP synchronisation — satisfies logging requirements across all 13 contributing frameworks. The strictest specification draws coverage scope from CERT-In Direction 20 (all ICT including IoT/OT), tamper protection from RBI ITGRCA IM.10, retention from SEBI CSCRF DE.3. Without unification, the auditor asks 13 different "do you log this" questions across system classes; with it, one logging architecture diagram + one coverage matrix answers all.

Strictness matrix

Scope

Logging scope: ALL ICT systems — servers, network devices, cloud instances, applications, databases, IoT devices, and OT/SCADA systems. No category is exempt. CERT-In Direction 20 specifies the broadest scope with the explicit IoT and OT/SCADA inclusion that closes a common gap (industrial control systems often excluded from enterprise logging). Ceiling source: cert_in:CERTIN.20 Rationale: CERT-In Direction 20 is the strictest scope articulator, explicitly enumerating IoT and OT/SCADA. Other frameworks address subsets. The CERT-In scope is mandatory for any organisation operating ICT infrastructure in India.

Threshold

Logging threshold: activities, exceptions, faults, AND security events — all four categories. The threshold for inclusion in logging is any event with operational, security, audit, or forensic significance. Specific event categories per system class: authentication events (success + failure), privilege escalation, configuration changes, data access (especially privileged), system errors, network connections, application errors. Ceiling source: iso27001:A.8.15 Rationale: ISO 27001 A.8.15 specifies four event categories explicitly. Other frameworks address subsets (e.g., "security events" alone). The four-category specification is the audit-defensible threshold.

Method

Method: (1) automated log generation enabled on all in-scope systems; (2) centralised collection via SIEM or equivalent; (3) tamper protection — write-once storage OR cryptographic hashing with separate-custody hash store; (4) time synchronisation across all log sources via NTP (Stratum 1 or 2); (5) privileged-access logging specifically called out for database systems and high-value applications; (6) automated alerting on critical security events; (7) sample integrity verification at periodic intervals. Ceiling source: rbi_itgrca:ITGRCA.IM.10 Rationale: RBI ITGRCA IM.10 is the most prescriptive method specification, with the privileged-access-logging element being uniquely strict. Other frameworks require logging; ITGRCA requires the change-auditing + privileged-access-logging discipline that catches insider risk.

Frequency

Logging frequency: continuous (real-time or near-real-time) event capture from all sources. Retention: minimum 12 months active for most events; longer for sensitive systems (24 months typical for critical-system logs; 5+ years for incident-relevant logs). Integrity verification: continuous via hash validation; periodic sample integrity audit (quarterly minimum). Ceiling source: iso27001:A.8.15 Rationale: Real-time / continuous log capture is the universal expectation. The 12-month minimum retention is the consistent floor; SEBI / RBI sectoral expectations push to 24 months for critical systems. Integrity verification cadence is the audit-defensible periodicity.

Evidence

Required evidence per RBI ITGRCA IM.10: (1) database security standards documenting logging requirements; (2) encryption configuration screenshots; (3) audit log samples showing recorded events; (4) privileged access matrix documenting who has privileged access and when; (5) DB vulnerability assessment reports; (6) direct-access review records. Additional cluster evidence: (7) log source inventory mapping all in-scope ICT systems (per CERT-In Direction 20 scope); (8) SIEM configuration showing parsing + alerting rules; (9) tamper protection evidence — WORM storage configuration or hash-chain integrity proof; (10) NTP synchronisation evidence. Ceiling source: rbi_itgrca:ITGRCA.IM.10 Rationale: RBI ITGRCA IM.10 carries the most specific evidence enumeration among cluster members. Database privileged-access logging is the sharpest test of an organisation's actual logging discipline — a logging programme that omits DB privileged access is failing the highest-value use case.

Auditor test pattern

Step 1: Inspect the log source inventory; verify coverage of all ICT system classes (servers, network, cloud, applications, databases, IoT, OT). Step 2: Sample 3 critical systems and trace their logs through to the SIEM. Step 3: Inspect tamper protection — verify WORM storage configuration or hash-chain integrity proof; attempt (in a controlled way) to demonstrate logs cannot be tampered with by privileged users. Step 4: Inspect NTP synchronisation across log sources; verify time skew is within tolerance. Step 5: Sample 3 alerting rules and trace each from rule definition to a recent triggered incident with response action. Step 6: Verify retention meets the policy by examining oldest available logs from a critical system.

Common findings

Common 2024–26 findings: (1) SIEM coverage incomplete — payment switches and ATM channels logged but not feeding the SIEM in real time; (2) Log retention 90 days, missing the 12-month minimum; (3) Tamper protection claimed but logs writable by the storage admin (not true WORM); (4) NTP synchronisation absent or drift undetected — timestamps unreliable for forensic reconstruction; (5) Privileged-access logging absent — DBAs and system admins operate without recorded activity; (6) Cloud / IoT / OT explicitly excluded from the SIEM coverage matrix; (7) Logs collected but never analysed — no alerting rules, no review cadence.