The compliance audit’s evidence request lands on a Monday: “Provide the audit trail of administrative access to the production environment for the audit period.” The company has 18 months of AWS CloudTrail logs sitting in storage — 2 million entries, mostly noise, with the events that matter buried inside. The auditor wants a readable narrative: who had access, when, what they did, were there anomalies, were they handled.
Translating raw logs into that narrative has historically been a multi-week project that pulls security engineers off everything else. The fix is a pipeline that runs continuously — pulling the relevant log slice per compliance control, summarising with AI into a narrative paragraph, flagging anomalies, and producing an evidence package the auditor accepts.
This piece is that pipeline: continuous summarisation, anomaly detection, and the audit-readable output that satisfies SOC 2, ISO 27001, HIPAA, and similar frameworks without the eight-week prep cycle.
Where this fits — and where it doesn't
Use this if you’re maintaining compliance certifications (SOC 2 Type II, ISO 27001, HIPAA, FedRAMP), you have meaningful log volume (millions of entries per audit period), and your team currently does manual log-narrative compilation. Common fits: B2B SaaS post-series-A, healthcare-adjacent companies, financial-services and fintech, government contractors.
Don’t use this if your compliance burden is small enough that manual log review works (very early stage, narrow compliance scope), your log infrastructure is too thin to provide useful narratives (no centralised logging, scattered events), or your auditor explicitly requires raw-log review rather than AI-narrative summaries.
What you'll need before starting
- Centralised log infrastructure — Splunk, Datadog, Snowflake-on-logs, AWS CloudTrail with searchability, Azure Monitor, or similar.
- A defined audit scope — which systems, which event types, which time periods, which compliance controls the narratives support.
- A model API key with long-context support. Audit narratives summarise large log windows; large-context models handle this comfortably.
- Familiarity with the compliance framework’s evidence requirements — auditors want specific things, and the narrative should match.
- A security or compliance owner to review generated narratives before they go to auditors. The pipeline produces drafts; the human review is non-negotiable for audit-bound work.
Six steps to audit narratives that hold up
- Define the narrative shape per compliance control
For each compliance control that needs evidence (CC6.2 logical access, CC7.1 security monitoring, CC8.1 change management for SOC 2 trust services), define the narrative shape — what events need summarising, what time window, what metadata. The shape is the spec; without it, the summarisation produces output the auditor can’t use.
- Build queries that pull the relevant log slice per control
For each control’s narrative, build a query that pulls the relevant events from your log infrastructure. CC6.2: production-environment access events, broken down by user, with role context. CC8.1: production deployment events with PR references, approvals, and timestamps. The query design is what makes the narrative possible; without targeted queries, the AI is summarising too much data.
- Run AI summarisation with the narrative shape as instructions
For each control’s log slice, pass to the LLM with explicit narrative-shape instructions: “Produce an audit narrative covering the period from X to Y; describe the access patterns by role; flag any unusual access; cite specific log events for each claim.” The output is a structured narrative with verbatim event references; the verbatim references are the audit anchor.
- Run anomaly detection — events worth flagging in the narrative
For each log slice, run anomaly detection: events outside business hours from unusual locations, access patterns deviating from established norms, deletion or modification of audit logs themselves, privilege escalations. The anomalies become explicit callouts in the narrative; even if they were handled correctly, the auditor wants to see they were noticed.
- Generate per-control evidence with cross-references
The output is per-control: the narrative paragraph, the source-query for verification, the log events cited, the anomalies surfaced. Auditors can read the narrative and drill into the underlying events when they need to. This is the format that satisfies modern audit standards — narrative summary backed by drillable evidence.
- Review with the security and compliance team before audit submission
Generated narratives go to internal review first, not directly to auditors. The reviewer checks: does the narrative accurately describe what happened, are the flagged anomalies presented honestly, is the language defensible if challenged. After review, the narrative is part of the audit evidence package. Auto-submission to auditors without review is the failure mode that produces “wait, that’s not quite right” follow-ups.
What it costs and what to expect
The audit-prep time savings are the operational ROI; the strategic value is the security team’s freed capacity for actual security work rather than evidence compilation.
Other ways to solve this
Compliance-platform automation (Drata, Vanta, Secureframe). Increasingly bundle audit-evidence generation. Right answer for SMB compliance programmes. Trade-off: less customisation of narrative shape.
Specialised audit-evidence tools (Anecdotes, Hyperproof). Mid-market focused; deeper customisation than the SMB platforms.
Manual narrative compilation by the security team. Traditional approach. Doesn’t scale; pulls security engineering off operational work. The AI pipeline displaces this.
Don’t generate narratives — submit raw logs. Some auditors accept this; many don’t. Where raw-log submission is acceptable, the question is just one of evidence retention. Most modern audits expect summarised narratives with drillable evidence.
Related work
For the broader compliance-evidence-collection pipeline, see Compliance evidence collection for SOC 2 / ISO 27001. For the document-classification side of audit work, see Document classification at scale. For the broader risk-and-compliance framework, see AI risk assessment for legal and compliance teams. For the federated-search pattern that complements log narrative generation, see Federated search across your tools.
FAQ
Do auditors accept AI-generated narratives?
Increasingly yes, with verification. The narrative needs to be reviewed by your team; the underlying raw events need to be retained and drillable; the anomalies flagged should be honestly presented. Auditors care that the narrative is accurate and verifiable; the generation method matters less than the verification quality.
How do we handle PII / sensitive data in logs that we don't want to share with AI vendors?
Redact at the input boundary or use enterprise-tier APIs with appropriate data-handling agreements. For very sensitive log content (PHI in healthcare contexts), consider self-hosted models. The redaction work is one-time; the long-term audit-prep savings dwarf the upfront privacy work.
What about logs from systems we don't fully control (third-party SaaS)?
Pull what you can via API; for systems without API log access, the narrative covers what's available with explicit notes about what isn't. Auditors increasingly accept that not all third-party logs are accessible; the documented effort to obtain available logs is what matters.
How is this different from a SIEM?
A SIEM (Splunk, Datadog Security, Sumo Logic) is the underlying log infrastructure; the pipeline is a layer that produces audit narratives on top of it. Many SIEMs now bundle some narrative-generation features; for compliance-focused work, the dedicated narrative pipeline often offers more control. The two layers compose well.
