11.03 Compliance Evidence Export

Why this matters

Audits, regulatory examinations, and customer security questionnaires all ask for the same things in slightly different forms: "show me your risk register, show me the controls you have in place, show me the tests you've run, show me the changes you've made over the audit period." Producing this evidence from SimpleRisk is the program's audit-readiness metric — programs that can produce it in hours pass audits cleanly; programs that take weeks lose audit confidence.

The evidence is in SimpleRisk; the work is extracting it in the form auditors expect. This article walks through the common patterns.

The honest scope to know up front: SimpleRisk Core has limited native export beyond what's available in the per-record UI. The Dynamic Risk Report supports CSV export, but only when the Import-Export Extra is active. Most other reports don't have one-click export; the path is API or direct database query. For programs that produce evidence frequently, scripting the extraction once produces a repeatable workflow.

Before you start

Have these in hand:

• Admin or auditor access to the SimpleRisk install (typically a read-only auditor role).
• A clear list of evidence requirements from the auditor or framework. Don't guess; ask. Common requirements:
• "Risk register as of [date]."
• "List of risks closed during the audit period."
• "Audit trail for the audit cycle that occurred during the period."
• "Control test results with evidence attachments."
• "User access reviews completed during the period."
• "Configuration changes made during the period."
• "Documents approved or expired during the period."
• The Import-Export Extra activated, if you'll use the Dynamic Risk Report's CSV export.
• API access with appropriate read permissions, if you'll script extraction.
• A file-storage destination for the evidence: shared drive, audit folder, document management system.

Step-by-step

Pattern 1: Export the risk register as of a specific date

Auditors want to see "the register on December 31."

Option A: Dynamic Risk Report CSV export (Import-Export Extra)

1. Sidebar: Reporting → Reports → Dynamic Risk Report.
2. Configure the filters to match what the auditor wants (status, date range, etc.).
3. Click Export (the button is added by the Import-Export Extra).
4. Save the CSV.

The CSV captures the current state of matching risks; for "as of a past date," you'd need to retrieve from a database backup taken at that date or use the audit trail to reconstruct.

Option B: API extraction

curl -H "X-API-KEY: 
  
   " \ -H "Accept: application/json" \ "https://your-simplerisk.example.com/api/v2/risks?status=open" \ > risk_register.json 
  

The JSON response is the current state. Convert to whatever format the auditor wants (CSV via jq, Excel via a script).

Option C: Database backup at audit period end

If your backup procedure includes monthly snapshots, the December backup is the December register state. Restore to a non-production environment for read-only inspection.

Pattern 2: Export risks closed during the audit period

Auditors want to see "what was closed and how" for the period.

API extraction:

# Risks closed in 2026-Q1 (adjust date format to your install)
curl -H "X-API-KEY: 
  
   " \ "https://your-simplerisk.example.com/api/v2/risks?status=closed&closed_after=2026-01-01&closed_before=2026-03-31" \ > closed_risks_q1.json 
  

For each closed risk, the auditor may want the close reason, the responsible user, the closure date, and any audit-trail entries from the closure event. Combine the risk data with audit trail entries (see Pattern 5).

Pattern 3: Export audit cycle results

Auditors want the results of audits run during the period.

The compliance audit pages show per-audit details with linked tests, evidence, and verdicts. To export:

• Per-audit PDF: many audit detail pages support a Print or PDF button that produces a self-contained document.
• API extraction: GET /api/v2/compliance/audits?started_after=...&ended_before=... returns the audit list; per-audit details come from the per-record endpoint.
• Direct SQL query for raw data: query audits, audit_tests, and related tables for the audit window.

The auditor typically wants both the metadata (when, who, what was tested) and the results (pass/fail/findings) plus any evidence attachments.

Pattern 4: Export control test results

Test execution records show that controls were actually tested and what the results were.

• Per-control test history: each control's detail view shows its test history.
• API: GET /api/v2/compliance/tests?control_id= returns the control's test runs.
• Bulk extraction: query tests and test_results tables for the audit window.

For each test run, the auditor expects: the test definition, the date executed, the executor, the result (pass/fail), and any evidence attached.

Pattern 5: Export the audit trail for a specific period

The audit trail is the running record of changes; for compliance evidence, the relevant period's slice is what auditors want.

-- All audit entries during the audit period
SELECT timestamp, user_id, risk_id, message
FROM audit_log
WHERE timestamp BETWEEN '2026-01-01' AND '2026-03-31'
ORDER BY timestamp ASC;

The output is typically large. Filter by relevant entity types or user IDs as the auditor requires:

-- Configuration changes only (system-level events have risk_id = 0)
SELECT timestamp, user_id, message
FROM audit_log
WHERE risk_id = 0
  AND timestamp BETWEEN '2026-01-01' AND '2026-03-31'
ORDER BY timestamp ASC;

-- User-management changes
SELECT timestamp, user_id, message
FROM audit_log
WHERE message LIKE '%user%'
  AND timestamp BETWEEN '2026-01-01' AND '2026-03-31'
ORDER BY timestamp ASC;

If the Encryption Extra is active, audit_log.message is encrypted; export via the application or API for human-readable output.

Pattern 6: Export user access review evidence

Auditors want "you reviewed user access during the period and the result was X."

If your program uses SimpleRisk's audit trail to record user-access reviews:

• Query audit_log for entries indicating access reviews completed.
• Combine with user-management entries showing role/team changes during the period.

If your program's user-access reviews happen outside SimpleRisk: those records live elsewhere; SimpleRisk's role is to record the related authorization changes.

Pattern 7: Export documents approved or expired during the period

The document management workflow records approvals and expirations.

• API: GET /api/v2/governance/documents?approved_after=...&approved_before=....
• Per-document detail: includes approval and expiration history.
• Direct SQL: query documents table with date filters; cross-reference with audit_log for the approval events.

For each document, the auditor expects: the document content (or attachment), the approver, the approval date, the next-review or expiration date.

Pattern 8: Custom evidence reports

Auditors sometimes want bespoke views: "show me all High and Critical risks in the Engineering team that have a mitigation overdue more than 30 days." For these:

• Combine multiple API queries in a script that produces the custom report.
• Direct SQL with joins across the relevant tables.
• Build a custom report if the request recurs (Reports → Reports Hub may have custom report support; check your install version).

The investment in scripting custom evidence reports pays back when the same request comes from the next auditor next year.

Pattern 9: Provide read-only access to the auditor

For auditors who want to verify directly:

1. Create a user account specifically for the auditor with appropriate read-only permissions.
2. Grant access to the relevant team(s) the audit covers.
3. Configure the account to expire at the end of the audit period.
4. Provide credentials securely.

Auditors typically prefer this — they can verify directly rather than trusting your extraction. Some auditors require it.

Pattern 10: Package and deliver

After extracting evidence, package for delivery:

• Organize by audit request — a folder per request from the auditor.
• Include a README documenting what each file is, when it was extracted, and from which install.
• Sign or hash the evidence files for tamper-evidence (some audits require this).
• Deliver via secure channel — encrypted file transfer, secure document portal, or in-person.

Common pitfalls

A handful of patterns recur with evidence export.

• Producing evidence ad-hoc each time. The first audit takes weeks; the second should take days; the third hours. Script repeatable extractions.

• Not coordinating with the auditor on format. A 50,000-line CSV when the auditor wants a 1-page summary is a lot of work for the auditor (and for you, if they then ask for the summary). Confirm format upfront.

• Exporting more than the auditor needs. Privacy / scope. Auditors don't need every risk's details if they only asked about the Critical ones.

• Forgetting to coordinate with the encryption layer. Direct SQL against an encrypted install returns ciphertext. Use the application or API for human-readable output.

• Producing evidence that excludes important context. A list of closed risks without close reasons is incomplete. Include the why, not just the what.

• Not version-controlling evidence extraction scripts. A script that produced last year's evidence is useful for this year — if you can find it.

• Exporting without a documented procedure. When a different operator runs the export, they should produce the same result. Document.

• Not testing the export against representative data. The script worked in dev; the production data has edge cases (long descriptions, special characters, missing fields) that break the export.

• Storing evidence files insecurely. Audit evidence often contains sensitive content (risk descriptions naming systems, audit findings citing vulnerabilities). Treat the files like the database itself.

• Not retaining evidence after the audit. Some regulations require evidence retention; the auditor may want it again next year. Archive properly.

• Producing evidence under time pressure without verification. A misstated number or missing record looks like sloppy program. Verify before delivery.

• Not anonymizing for non-confidential audiences. Sharing audit reports with broader stakeholder groups may require anonymizing user names, customer references, etc.

Related

• The Audit Trail
• The Debug Log
• Scheduled Reports
• Using the API for Integrations
• Building a Script Against the API
• Database Backup and Restore
• The Encryption Extra Overview

Reference

• Permission required: View permissions on the entities being exported (typically auditor-role or admin).
• API endpoint(s): All read endpoints under /api/v2/... (risks, audits, tests, documents, etc.); per-entity audit endpoints for history.
• Implementing files: The Dynamic Risk Report's CSV export lives in the Import-Export Extra (simplerisk/extras/import-export/). The per-audit and per-control export lives in the relevant compliance pages.
• Database tables: audit_log, risks, mitigations, audits, audit_tests, tests, test_results, documents, users, user_to_team, etc. — depending on the evidence requested.
• Encryption: If the Encryption Extra is active, encrypted fields require application-level access for decryption. Direct SQL returns ciphertext.
• External dependencies: The Import-Export Extra for Dynamic Risk Report CSV; an API key for scripted extraction; a file-storage destination for delivery.