Skip to content

Logging, Monitoring & Detection

You can't respond to what you can't see. This policy sets what Holmes logs, how long it keeps those logs, and how security events get noticed and acted on. The work is largely done by automated detection (Microsoft Defender), and this policy formalises it and points it at a clear response path.

1. Logging

Ref Requirement
LOG.1 Security-relevant events MUST be logged across endpoints, servers, network devices, identity systems, cloud and tenant, email, and code and CI/CD platforms.
LOG.2 Audit logging MUST be enabled and protected against tampering, and administrative and privileged actions MUST be logged (03).
LOG.3 Security logs MUST be retained for at least 12 months, longer where regulation or contract requires.
LOG.4 Agentic-AI actions (05 AI.12) and GitHub Enterprise audit events (09 DEV.16) MUST be in logging scope.

Twelve months (LOG.3) is the practical floor for investigating an incident, since compromises are often discovered well after they begin.

2. Monitoring and detection

Ref Requirement
LOG.5 Endpoint and identity detection and response (Defender XDR or equivalent) MUST be deployed across endpoints, servers, and identity, with automated containment enabled where appropriate.
LOG.6 Security alerts MUST be centralised, triaged, and actioned within defined response times. Detection MUST cover the tradecraft relevant to Holmes: identity-infrastructure abuse, lateral movement, credential theft, data exfiltration, CI/CD anomalies.
LOG.7 Detection coverage MUST be validated periodically, for example via the penetration testing in 10 VULN.2. A control assumed to work but never tested isn't a control.
LOG.8 Break-glass account activity MUST be monitored and alerted (03 IAM.23).

3. The security function / SOC

Ref Requirement
LOG.9 Holmes MUST maintain a defined security-monitoring capability, internal, managed-provider, or hybrid, with clear ownership of alert triage and escalation into 12 Incident Response.
LOG.10 Where the AI policy and others refer to "the SOC", that reference MUST resolve to a real, named capability. If none is currently contracted, the CIO and IT security team hold the function until one exists, and this MUST be stated wherever staff are asked to report to it.

A reporting line to a function that doesn't exist is one nobody uses. LOG.9 and LOG.10 require the capability others depend on to be real and named.

4. Legal & jurisdictional notes

Logging and monitoring are the evidentiary backbone of breach assessment. Whether an incident is notifiable under NZ, AU, GDPR, or US-state law often turns on what the logs can show about what was accessed (12). Insufficient logging can force a worst-case, assume-notifiable posture.

Monitoring of staff activity MUST be proportionate and consistent with employment and privacy obligations across jurisdictions. Confirm the monitoring scope with P+C and counsel, particularly GDPR proportionality for the Netherlands entity.

00 Framework, 03 Identity & Access, 07 Network & Infrastructure, 09 Secure Development, 12 Incident Response.