Audit season turns DBAs into archivists: change logs, access lists, backup attestations, screenshots at midnight. This playbook flips the workflow — raw exports collected once, AI-drafted narratives linked to each exhibit — producing evidence packs auditors accept because every sentence points at a file, and every file has a date and a source.
Tier: Core · Workflow area: Security & Compliance · ~30 minutes
Auditors do not accept assertions; they accept evidence with provenance. The chronic failure of database audit responses is mismatched altitude: the DBA hands over raw logs the auditor cannot read, or a narrative the auditor cannot verify. The pack that works has both layers, welded together — a plain-language control narrative where every claim carries an exhibit reference, sitting on top of dated, sourced raw exports. AI is excellent at the welding: it drafts narratives from the exhibits, in auditor register, and it never gets to state anything the exhibits do not show.
Get the request list into a control matrix first. Paste the auditor's request list (or the certification's control set) and have AI structure the campaign:
Below is the auditor's evidence request list for our database estate
(PostgreSQL + SQL Server). Build a matrix: request ID, what control
it tests, the concrete artifact that evidences it from a database
estate, the query/command that produces the artifact, the owner role,
and typical auditor follow-ups. Flag any request where a database
team is likely NOT the right owner (e.g., HR termination process).
The mis-ownership flags matter: half of audit pain is the DBA team absorbing requests that belong to identity or infrastructure teams.
Produce the raw exhibits with provenance stamped in. Every exhibit is generated by a command, and the command is part of the exhibit:
# Exhibit A3: database change history, last quarter
{
echo "-- Generated: $(date -u +%FT%TZ) by $(whoami)"
echo "-- Source: flyway_schema_history, proddb"
psql -d proddb -c "COPY (SELECT installed_rank, version,
description, installed_by, installed_on, success
FROM flyway_schema_history
WHERE installed_on >= '2026-05-01') TO STDOUT CSV HEADER"
} > A3-change-history-q2.csv
sha256sum A3-change-history-q2.csv >> pack-manifest.txt
The pattern repeats for each family: access lists (the pb-21 dump), backup attestations (pgbackrest info plus the last restore-test record from pb-17), configuration evidence (SELECT name, setting FROM pg_settings WHERE name IN (...)), encryption and TLS settings. The manifest with hashes and generation timestamps is what makes the pack self-authenticating.
Draft narratives from exhibit summaries — altitude: auditor, not DBA. For each control, feed AI the summary of the exhibit (row counts, date ranges, notable values — not the raw file) and request the narrative:
Control: "Changes to production databases are authorized and logged."
Exhibit A3 summary: 47 schema changes in Q2; all 47 have Flyway
version IDs; 45 link to change tickets (list of 2 exceptions:
hotfix-0619, hotfix-0704, both with retroactive tickets filed within
24h per policy §4.2). Exhibit A4: change-approval workflow export.
Write a one-paragraph control narrative in audit register: what the
control is, how it operates, what the exhibits show, exceptions and
their disposition. Every factual claim cites (A3) or (A4). Do not
claim anything absent from the summaries. British restraint; no
adjectives like "robust" or "comprehensive".
Banning confidence adjectives is practical, not stylistic — auditors read "robust" as a flag to dig.
Handle exceptions with disposition, never silence. Every pack has them: the emergency change without prior approval, the service account with a stale password rotation. The drafting rule is fixed — exceptions appear in the narrative with their disposition (policy provision, compensating control, or remediation ticket with date). An exception the auditor finds that your narrative omitted converts the whole pack from evidence into a credibility problem.
Run the adversarial pass — AI as the auditor. Before submission, reverse the roles:
You are a skeptical SOC 2 auditor reviewing this evidence pack
(narratives + exhibit manifest below). For each control: what
follow-up would you ask? Which narrative claims are weakly
evidenced? Where would you request a live screen-share to re-derive
an exhibit? Rank your five hardest questions.
Every question it lands is one you now answer on your schedule instead of live in the audit room. Strengthen the exhibit or pre-write the response; both go in the pack owner's briefing notes.
Freeze, index, and reuse. Final pack: index page (control → narrative → exhibit IDs), narratives, exhibits, manifest with hashes. Freeze a copy — auditors return with follow-ups months later, and "the file changed since submission" is a finding. Then bank the whole structure: next cycle the commands rerun, the narratives update against new summaries, and assembly drops from weeks to days.
sys.database_principals joins; SERVER AUDIT file exports carry their own tamper-evidence, which auditors like — reference it in the narrative.UNIFIED_AUDIT_TRAIL) with the audit-policy definitions themselves as exhibits — the auditor's first follow-up is always "show me what you audit."An evidence pack aggregates your security posture into one convenient document — access lists, configurations, known exceptions. Share it through the auditor's portal or an access-controlled room, never email attachments, and apply your highest handling class to the frozen copy.
Auditors accept packs where narrative and evidence are welded: every sentence cites, every exhibit is dated, hashed and reproducible by the command stamped inside it. AI drafts the weld and plays the skeptical auditor in rehearsal — the controls themselves, and the honesty about their exceptions, remain entirely yours.