Audit Failure Alerting

An alert is something that arrives without anyone asking.

Objective [c] is met by a notification that reaches a named person or role on its own: an email, a text, a ticket. A procedure where someone checks whether logs arrived is monitoring, not alerting, and it fails the moment nobody checks.

The requirement has three parts, and the technical alert is only one of them.

Name who gets alerted for [a], write down which failure types generate an alert for [b], and prove delivery works for [c]. An alert rule with no documented recipient and no defined failure list covers one objective out of three.

Define failure as logs stopping, plus storage filling.

A log source that sends nothing for a defined window has failed, whatever the cause. Add capacity alerts as well, because the assessment guide names audit record storage capacity being reached as a failure type. A rule that fires when a source goes quiet and a rule that fires when the log store nears its limit cover the defined types.

Match the alert window to the device's duty cycle.

A firewall or server that goes silent for an hour is an incident. A laptop that goes silent over a weekend is a weekend. Set per source alerts for systems that run around the clock, and a multi-day reporting threshold for endpoints that power off. Write the distinction into your failure type definitions.

For SaaS platforms, the platform's internal logging is the provider's to keep running and yours to verify.

The audit logging Microsoft 365 performs inside the service is the provider's responsibility under FedRAMP, the federal cloud authorization program. Do not assume it. Obtain the provider's customer responsibility matrix, the document that splits security duties between the provider and you, and cite where it covers audit process failure. Alert on the parts you still own, such as the connector that pulls tenant logs into your own log store.