grcskills
Menu

Logging and monitoring evidence pack

Use this skill when an auditor, customer or regulator will ask how security events are logged and watched, and someone says "prepare logging evidence", "show we monitor alerts", "what do we log and for how long", "who looks at the SIEM", "prove an alert was handled" or "our monitoring evidence is just dashboard screenshots". Maps log coverage and retention per system, lists the alert rules that matter and where they go, traces real alerts end to end with timestamps, and writes an evidence pack with the gaps stated plainly.

EvidenceISO 27001SOC 2NIS 2

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.

Step 3: show how review is recorded

Find the record that a human looked at alerts: a ticket per alert, a triage note, an acknowledgement in the paging tool, a weekly review log. "We watch the dashboard" leaves nothing an auditor can sample. Where review is real but unrecorded, propose the lightest record that fits the team, such as acknowledging in the paging tool with a one-line outcome.

Step 4: trace real alerts end to end

Agree the period first (the audit period, or the last 90 days when none is set). Pick at least three alerts from it: one closed as a false positive, one escalated to an incident, and one picked at random from the full ticket list, with the method recorded so the pick can be repeated. For each, write a one-page walkthrough (walkthroughs/<n>.md) with timestamps: rule fired, who acknowledged and when, what they checked, the decision and why, closure, and any follow-up such as a rule change. Compare response time with the target. A single real trace convinces an auditor more than a dozen configuration screenshots.

Step 5: assemble the pack and the gaps

Put configuration extracts, rule descriptions and walkthroughs together with the source of each. Replace user names, IP addresses and other personal data in log extracts with roles or placeholders unless the reviewer needs them. Write the gap list (gaps.md): systems without logs, systems logged but covered by no alert rule, retention shorter than promised, alerts routed nowhere, review not recorded, each with an owner role and a proposed fix. Where a framework sets expectations on retention or review frequency, run a framework lookup rather than assuming a number.

If the output folder exists, ask before overwriting and offer a new subfolder instead.

What good looks like

  • Retention is read from configuration and compared with the policy; mismatches are listed, not smoothed over.
  • Every critical alert has a named receiver and a recorded human response.
  • The common mistake is a pack of screenshots of the detection tool's dashboard and rule settings. The tell: nothing in the pack shows a person doing something with an alert on a given day.
  • Log integrity is addressed: who could erase the trail, and why they cannot.
  • The gap list is honest and short, and each line can become a ticket the same day.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-logging-and-monitoring-evidence-pack

Rules

  • MUST trace at least one real alert from firing to closure with timestamps.
  • MUST cite the configuration, ticket or log behind every claim in the pack.
  • MUST write outputs only inside ./logging-and-monitoring-evidence-pack/ and ask before overwriting.
  • NEVER change logging, retention or alert configuration; propose changes for the owner.
  • NEVER trigger a test alert or simulated attack without the owner's explicit go-ahead.
  • NEVER copy secrets, tokens or unredacted personal data from logs into the pack.