Logging, the control that dies quietly.
ISO 27001:2022 A.8.15 (logging) expects security-relevant events (logins, errors, faults, access to sensitive data) to be recorded, kept for a defined period, and protected from tampering. It is load-bearing for A.8.16 (monitoring) and for any later investigation: you cannot detect or reconstruct what was never recorded. And it is easy to weaken without noticing, because a log is the kind of line that gets tidied away.
The shapes the same control failure takes.
A.8.15 rarely breaks with a dramatic change. It breaks when a security-relevant event stops being recorded. The recurring shapes:
A security log is removed
A log call for an authentication event, a privilege change, or access to sensitive data is deleted in a cleanup because it looked noisy.
A log level drops below production
A security event is moved to a level (debug) that is not emitted in production, so it silently stops being recorded where it matters.
The actor is dropped from the record
A log keeps firing but stops including who did it, so the event can no longer be attributed during an investigation.
A new privileged action ships unlogged
A new admin or destructive operation is added with no audit record at all, so there is nothing to sample later.
Retention is shortened
A log's retention or rotation is reduced below what the control expects, so the record is gone before anyone needs it.
Auth failures dropped below the production log level.
Authentication-failure logs are noisy in development, so a change moves them from a warning to a debug level. In production the log level is set to info, so those failures now vanish from the record entirely, exactly the events you most want when investigating an intrusion.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}With production at info level, dropping auth failures to debug means they are no longer recorded in production. A.8.15 expects security-relevant events, including failed authentication, to be logged and retained, and A.8.16 (monitoring) depends on them. Keep them at warning or route them to the security log rather than silencing them in production.
Logging is sampled against real events.
An auditor checks that security-relevant events are actually logged, retained for the period your policy states, and protected from tampering, and they will sample specific event types (logins, privilege changes, access to sensitive data). A change that silently stopped emitting one of those, by deleting it or dropping it below the production level, is the gap they find. The change that introduced it was usually an ordinary pull request that looked like noise reduction.
A review, not your SIEM.
heygrc flags changes that touch A.8.15 and cites the control so the fix happens in the pull request. It does not run your logging pipeline or your monitoring. It catches the moment a security event stops being recorded, at the diff. heygrc is in early access.