Generating Compliance Evidence with AI

Audit season is the worst time to be a DBA. An auditor sends a spreadsheet of controls, each one requiring specific evidence from your SQL Server environment, and you have two weeks to produce it all. You spend those two weeks writing one-off queries, taking screenshots, reformatting output into the template your compliance team requires, and wondering if you missed something.

AI agents don’t replace your compliance team or your QSA. But they dramatically reduce the time between “here’s the control requirement” and “here’s the evidence query.” Instead of translating compliance language into T-SQL from scratch, you describe the requirement and get a first-draft query in seconds. I covered this at a high level in Security Audits: Finding What You Missed. This post walks through specific examples for SOX, PCI-DSS, and HIPAA.

The Problem: Compliance Language ≠ SQL Server Language

Auditors speak in control requirements: “Demonstrate that access to cardholder data is restricted to authorized personnel.” You speak in DMVs: sys.database_permissions, sys.server_role_members, sys.dm_exec_sessions. The translation between the two is where all the time goes — not the query itself, but figuring out which metadata answers the auditor’s question.

This is where the AI agent earns its keep. It understands both languages.

Example 1: PCI-DSS — Encryption at Rest (TDE Audit)

PCI-DSS v4.0 Requirement 3.5.1 requires that stored account data is secured with strong cryptography. For SQL Server, that typically means TDE (Transparent Data Encryption) on databases containing cardholder data.

The agent produced a clean script joining sys.databases, sys.dm_database_encryption_keys, and sys.certificates:

What I changed: the certificate backup check was too generic — it was just looking for any master database backup, not specifically a certificate backup. SQL Server doesn’t track certificate backups in msdb.backupset directly (certificate backups go through BACKUP CERTIFICATE, which doesn’t log to backupset). I replaced the OUTER APPLY with a note that certificate backup verification requires checking your backup file system or your certificate backup automation logs. This is important to flag honestly — telling an auditor you have a backup when you’re really checking something else is worse than saying “manual verification required.”

Example 2: SOX — Access Control Evidence

SOX (Sarbanes-Oxley) controls around IT general controls require evidence that access to financial systems is appropriately restricted and reviewed. The specific evidence varies by auditor, but you’ll almost always need to show login inventory and privilege assignments.

The agent’s initial version filtered out service accounts entirely. I kept them in with a flag — auditors want to see everything and then verify that service accounts are appropriately justified. Hiding accounts from an audit report is a bad habit.

Example 3: HIPAA — Audit Trail Configuration

HIPAA’s Security Rule (§164.312(b)) requires audit controls for information systems containing electronic protected health information (ePHI). For SQL Server, this means verifying that auditing is configured and operational.

What I Validated Across All Three

A few things I checked before using any of these in a real audit:

  1. The queries don’t modify anything. All reads, no writes. An auditor should be able to run these without concern — and you should be able to prove they’re read-only.

  2. The output format works for compliance teams. I copy-paste the results into Excel. The column names are descriptive enough that a non-DBA can read them. If your compliance team has a specific template, ask the agent to match it — provide the column headers and it’ll restructure the query.

  3. The agent’s compliance knowledge has limits. It knows the general structure of PCI-DSS, SOX, and HIPAA requirements from training data. It does not know your specific scope, your compensating controls, or your auditor’s interpretation of a requirement. Always have your compliance team or QSA review the evidence before submission.

Try This Yourself

Pick one compliance control you need to evidence next audit cycle. Describe the requirement to the agent in plain English — include the framework name, the specific control number, and what the auditor is looking for. Then compare the agent’s output against what you’ve been producing manually.

The time savings compound. Once you have a working evidence query for each control, save them in a version-controlled repository (we covered that in Version Control for DBAs). Next audit cycle, you run the scripts and update the evidence — instead of rebuilding everything from memory.

The goal isn’t to automate compliance. It’s to automate the evidence gathering so you can spend your time on what actually matters: understanding and improving your security posture. The agent translates compliance language into T-SQL. You verify the results are accurate and the evidence is honest.

For the full security audit workflow, see Security Audits: Finding What You Missed.


Part of the ALTER DBA ADD AGENT series.