Run an Audit-Evidence Gap Analysis Before the Auditor Does

This is an Advanced task because it's reasoning over incomplete, messy evidence against precise requirements, and the stakes are a failed audit or a qualified opinion. AI accelerates the cross-reference — matching evidence artifacts to the requirements they satisfy and flagging requirements with thin or missing proof — but the evidence corpus is imperfect and "adequate" is a judgment call, so every gap and every "covered" is a hypothesis you confirm against the real artifact and the auditor's actual bar.

When to reach for this

• •
  An audit (SOC 2, ISO 27001, internal) is coming and you need to know which controls lack sufficient evidence.
• •
  You're doing readiness/pre-assessment work and want a prioritized remediation list of evidence gaps.
• •
  You maintain evidence continuously and want a periodic check that each control's proof is current and complete.

The workflow

1. 1.

   List the controls in scope and the evidence you hold. For each control: the requirement, and the artifacts you can produce (policy, ticket, log export, screenshot, config). Precision about what each artifact demonstrates matters.

2. 2.

   Prompt for a per-control evidence assessment biased toward finding gaps:

   Copy

   You are performing an audit-evidence gap analysis. For each control, assess
   whether the listed evidence adequately demonstrates the control OPERATES,
   not just that it exists on paper.
   
   For each control:
   - classify: ADEQUATE / PARTIAL / GAP
   - state exactly what an auditor would accept and whether the evidence meets
     that bar (existence of a policy is NOT evidence of operation)
   - if PARTIAL or GAP, name the specific missing artifact
   When in doubt, classify toward the weaker rating — I would rather
   investigate a false gap than be surprised in the audit.
   
   CONTROLS + EVIDENCE:
   - AC-01 MFA on admin access | evidence: IdP policy doc
   - CM-03 change approval | evidence: 5 sample change tickets, Q1
   

   Expected output: per-control ratings that distinguish "policy exists" from "control demonstrably operated over the period" — e.g., flagging that an IdP policy doc alone doesn't prove MFA was enforced, or that Q1-only tickets don't cover the full audit period.

3. 3.

   Prioritize the gaps by audit weight and closability. Ask the model to rank gaps by how central the control is to the audit and how quickly the missing evidence can be produced — so you spend the runway on what matters.

4. 4.

   Confirm each gap and each ADEQUATE against the real artifact and the real bar. Open the actual evidence; does it cover the full audit period, the full population, operation not just design? An "adequate" that only samples one quarter of an annual period is a gap.

5. 5.

   Drive remediation before the audit. Turn confirmed gaps into evidence-collection tasks with owners and dates — the whole point is to close them while there's time.

Verify before you trust it

• Confirm each GAP is real by inspecting the evidence. The model works from your description of the artifact; the artifact itself may cover more (or less) than you said. Open it before you spin up remediation.
• Interrogate every ADEQUATE hard. This is where surprises live. Confirm the evidence covers the full period, the full sample population, and demonstrates operating effectiveness — not just that a document exists. Auditors test operation; design evidence alone fails.
• Check the model applied the auditor's bar, not a lenient one. "A policy says we do MFA" is design evidence; "IdP logs show MFA enforced on every admin login across the period" is operating evidence. Confirm the assessment held the right standard.
• Validate period and population coverage. Sampled evidence for part of the audit window, or for a subset of systems, is a common hidden gap the model may rate adequate.

Pitfalls

• Design evidence mistaken for operating evidence. The classic audit failure: a policy proves intent, not that the control ran. Force the distinction in the prompt and verify it.
• Optimistic ADEQUATE ratings. Bias toward "gap" for ambiguous cases; a false all-clear is exactly the pre-audit surprise this exercise exists to prevent.
• Period and population blind spots. Evidence covering one quarter of a year, or 5 of 500 changes, may look adequate and isn't. Check coverage explicitly.
• Trusting the evidence description over the artifact. Confirm against the real file — descriptions drift from what the artifact actually shows.
• Finding gaps but not closing them. The analysis only pays off if confirmed gaps become dated remediation tasks with owners before the audit.

Tools

• An LLM (Claude-class)performs the control-to-evidence assessment and the gap prioritization; the core reasoning engine.
• OSCAL (NIST)structuring controls and evidence in OSCAL makes the mapping machine-checkable and reusable across audit cycles.
• NIST CSF / your audit frameworkdefines the requirements and the evidentiary bar each control must meet, the standard you validate the assessment against.

Client-safe variant

An evidence gap analysis is a map of where a client's compliance program is weakest — acutely sensitive before an audit. Run it over abstracted control and evidence descriptions ("change-approval tickets for Q1", not the tickets themselves), and never paste actual log exports, screenshots, or customer data into an external tool. Where the client bars public AI, use a local model over their in-house evidence. Keep gap findings and remediation tasks inside the client's own GRC system, share them only with the accountable owner, and confirm per-client approval and data-handling terms before any evidence detail leaves their boundary.