What Threat Intelligence Evidence Do Auditors Look for in SIEM Logs?

Auditors look for threat intelligence audit evidence siem logs that proves your organization collects relevant threat information, analyses it, turns it into detectable or actionable use cases, and reviews whether that process works. For ISO 27001 Annex A control 5.7, a feed subscription or a screenshot of an alert is not enough: assessors need a traceable chain from threat source to SIEM ingestion, analyst decision, operational response, and retained records.

ISO 27001 control 5.7 requires that “Information relating to information security threats shall be collected and analysed to produce threat intelligence.”[1] As the internal auditor preparing the evidence pack, your task is to show that this is a repeatable control rather than an informal activity performed when an analyst happens to see a news report. The most persuasive evidence is time-bound, attributable, and internally consistent across the SIEM, ticketing platform, threat-intelligence source, and governance records.

What does an assessor actually check for under ISO 27001 control 5.7?

An assessor normally samples evidence from the audit period and follows it end to end. Prepare these concrete artifacts before the external assessment:

• Threat-source inventory and selection rationale. Provide the approved list of commercial feeds, government advisories, sector alerts, vendor bulletins, and internal incident sources. Include who owns each source, how often it is reviewed, and why it is relevant to your technology stack and risk profile.
• SIEM ingestion and normalization evidence. Show feed connector settings, enabled collections, ingestion-health dashboards, parser mappings, and timestamped log searches proving that indicators, threat reports, or enrichment data entered the SIEM during the sample period.
• Detection and correlation evidence. Produce active rule configurations that use intelligence data, such as malicious-IP matching, suspicious-domain lookups, hash reputation enrichment, or detections mapped to a threat campaign. Include rule owner, severity, last modification date, and test results.
• Analysis and decision records. Supply analyst case notes, intelligence assessments, Jira or ServiceNow tickets, and change records demonstrating that the organization evaluated relevance and chose an action: block, monitor, tune a rule, notify a business owner, or document why no action was needed.
• Management and review records. Show periodic reviews of feed quality, expired indicators, false-positive rates, use-case coverage, and assigned responsibilities. Meeting minutes, metrics packs, and control-owner attestations are useful when they connect directly to the operational records.

Do not present these as disconnected screenshots. An assessor should be able to select one threat indicator or advisory and see the full evidence trail. For example, a malicious domain received from a trusted source should be visible in the intelligence platform, enriched or matched in the SIEM, triaged in a case, and either blocked in DNS security tooling or recorded as not observed in the environment.

At Harrow & Keene LLP, a 430-person legal, accounting, and professional services firm, the security team uses Microsoft Sentinel for Microsoft 365, Defender for Endpoint, Palo Alto firewall, and VPN logs. Its external assessor selected a credential-phishing advisory from the audit period. The team demonstrated the advisory in Recorded Future, Sentinel’s matching analytics rule, three resulting incidents, analyst comments in ServiceNow, and a DNS block-list change approved by the network lead. That sequence was stronger evidence than the team’s monthly threat newsletter because it established collection, analysis, and action.

How do you map threat intelligence audit evidence siem logs before the audit?

Build an evidence map that identifies the authoritative tool, the exact location or query, and the person who can explain it. This prevents a common audit-day problem: the control owner knows the process, but the SIEM administrator is unavailable to retrieve the records.

Export the map as part of the evidence index, but retain live access as well. Screenshots are useful for preserving point-in-time configurations; live demonstrations are useful when the assessor asks for a different date range, a raw event, or the rule logic behind an alert.

What are the top three gotchas that fail threat-intelligence evidence reviews?

1. The feed exists, but nobody can prove it influenced analysis or detection

A subscription invoice, portal login, or vendor report proves procurement, not operation. Assessors often ask, “What did you do with this intelligence?” If the answer is that analysts read it, prepare dated records showing a decision. A documented conclusion that an advisory did not apply is valid evidence when it explains the affected technologies checked, the analyst’s rationale, and the reviewer where required.

2. SIEM detections match indicators, but the indicator data is stale or ungoverned

Threat feeds can create misleading evidence if expired indicators remain active indefinitely or if ingestion failures are unnoticed. Demonstrate time-to-live handling, confidence thresholds, de-duplication, connector monitoring, and periodic source-quality review. SIEM threat intelligence evidence is more credible when the team can explain why a high-confidence feed is automatically correlated while low-confidence indicators require analyst enrichment.

3. Case records show alerts, but not intelligence analysis

Generic closure notes such as “false positive” or “resolved” do not demonstrate the analysis required by control 5.7. Require analysts to capture the intelligence source, observed entities, relevance to the organization, validation steps, disposition, and resulting action. If a case was closed because no endpoint contacted the indicator, the search scope and time range should be evident in the record.

What should the seven-day pre-audit countdown include?

1. Day 7: Confirm the control statement, audit-period boundaries, system scope, evidence owners, and external assessor agenda. Identify one primary and one backup presenter for each platform.
2. Day 6: Reconcile the threat-source inventory against active SIEM connectors and subscriptions. Record any inactive or retired sources and the approved reason for their status.
3. Day 5: Select two to three representative intelligence-to-action examples from the audit period, including at least one case with a blocking, tuning, or detection-engineering outcome.
4. Day 4: Export key SIEM searches, analytics-rule configurations, ingestion-health views, and retention settings. Verify timestamps are visible and use a consistent time zone.
5. Day 3: Review sampled ServiceNow or Jira cases for complete analysis notes, approver details, linked changes, and closure evidence. Correct missing links where the underlying activity occurred.
6. Day 2: Conduct a 30-minute evidence walkthrough with the SIEM engineer, threat-intelligence lead, and SOC manager. Ask each person to retrieve evidence without relying on personal folders.
7. Day 1: Freeze the evidence index, validate permissions for live demonstrations, prepare sanitized exports for confidential client or matter data, and document any known gaps with remediation owner and target date.

For a firm handling client financial records and confidential legal matters, sanitize examples without removing the evidence needed to establish the chain of custody. Replace client names in exported case notes where possible, but preserve incident IDs, timestamps, analyst identities, rule names, and the technical indicators that support the audit conclusion.

What should you do during the assessor interview?

Start with the control narrative in one sentence: the organization collects relevant threat information, analyses it against its environment, and uses the result to improve monitoring or protection. Then demonstrate one complete sample rather than opening multiple dashboards at once. Let the assessor choose a date or indicator when practical; this increases confidence that the threat intelligence logging evidence was not assembled solely for the audit.

• State the evidence owner before sharing each artifact, distinguishing operational ownership from control accountability.
• Explain what the SIEM record proves and what it does not prove. For example, an indicator match proves correlation; the associated case proves analyst analysis and disposition.
• Use precise language for exceptions. If a connector failed for six hours, show the monitoring alert, impact assessment, remediation, and whether the gap affected control operation.
• Avoid claiming that every intelligence report results in a new detection. Explain the triage criteria and show records for actions, monitoring decisions, and justified non-actions.
• Capture every assessor request, including follow-up evidence, requested format, responsible owner, and due date. Treat these notes as part of your post-audit corrective-action record.

If the assessor identifies a gap, do not try to fill it with retrospective narrative. Acknowledge the condition, show the actual evidence available, explain the risk and scope, and present a specific corrective action with accountable ownership. That response generally supports a more accurate finding and makes remediation easier to verify.

Next step: Schedule a control-5.7 evidence walkthrough this week and require each evidence owner to demonstrate one traceable intelligence-to-SIEM-to-action record before the external assessor arrives.