logging-and-monitoring-evidence-pack
Use this before an audit or a customer review, and again after any change to the logging stack. You get an evidence pack in a new folder, ./logging-and-monitoring-evidence-pack/: a spreadsheet you can open in Excel showing, per system, what is logged, where, for how long and who can delete it (coverage.csv); a short list of the alert rules that matter and who receives them (alert-rules.md); one page per real alert traced from firing to closure, with times (walkthroughs/<n>.md); and a list of gaps with an owner and a fix each (gaps.md). This skill drafts for a human to review and sign; this skill never marks a control effective.
Inputs to gather
Read the system inventory, the logging and monitoring policy (it states what the company promised to log, keep and review), the architecture overview, and, read-only, the logging configuration, the alert rule list from the monitoring or detection tool, the on-call rota and the alert or incident tickets for the period. Ask the reader, in one message: which systems are in scope, where logs end up, who receives alerts out of hours, and which alerts they consider critical.
Step 1: map coverage per system
One row per in-scope system in the coverage spreadsheet (coverage.csv): which event types are logged (sign-in success and failure, administrator actions, access to sensitive data, configuration changes, security tool events), where the logs go, retention as configured, retention as the policy states, who can read the logs, who can delete or alter them, the time source the system syncs to, the control id from the company's own control matrix or statement of applicability, and the source of each answer. Read retention from the settings, not from the policy. Check that administrators of a system cannot quietly delete that system's audit log; logs stored in a separate account or with write-once settings answer that question, logs on the same host do not. Read access matters too: logs hold personal data and credential fragments, so broad read access is a finding in its own right. Check that systems sync to a common time source; every timestamp in Step 4 depends on it.
Step 2: list the alert rules that matter
From the rule list, keep in the alert rule list (alert-rules.md) the ones tied to real risks: repeated sign-in failures and impossible travel, new administrator accounts or privilege changes, logging switched off, unusual data export, malware detections, changes to network exposure. For each: what it detects, the control id it evidences, who receives it, the expected response time, and how often it fired in the period. Flag three patterns:
- Routed nowhere: the alert goes to an unread mailbox or a channel nobody owns.
- Never fired: a rule silent for the whole period may be broken; propose a safe test the owner can run.
- Noise: a rule firing hundreds of times a day is not being read; propose tuning.