Audit Evidence for Software Systems: What Counts and How to Keep It

TL;DR — To an auditor, "evidence" is the proof behind a control claim: not "we do backups," but the backup policy, the job history, a restore test, and who reviewed it. The most likely fix for audit pain is to stop treating evidence as screenshots collected at the last minute and instead keep a simple, dated evidence pack: policy, system export, logs/report, and review record for each important control. Reading time: ~7 min

What it is and where it sits

In compliance work, a control (a rule or practice you say you follow) needs evidence (proof you actually followed it). Auditors are not mainly checking whether your intentions are good. They are checking whether your process exists, operated during the period under review, and can be trusted.

For a software business, evidence usually sits in four places:

1. Documents — policies, procedures, risk assessments, approval records.
2. System configuration — what your cloud, identity, code, and database settings are right now.
3. Operational records — logs, tickets, change history, backup reports, access reviews.
4. Human sign-off — who reviewed, approved, tested, or investigated something, and when.

What talks to it? Usually your day-to-day systems already produce the raw material:

• your identity provider (login system) for user access and MFA (multi-factor authentication)
• your cloud platform for network, server, and storage settings
• your code platform for pull requests and deployment history
• your ticketing system for approvals and incidents
• your backup and monitoring tools for job results and alerts
• your document repository for policies and review dates

What does this replace? Ideally, it replaces the painful pattern of scrambling before an audit: taking ad hoc screenshots, asking staff what happened six months ago, and exporting whatever happens to still exist.

Where does it live in a typical flow? Evidence is not one system in the request path like a database or cache. It is a layer around your operations: systems generate records, someone preserves the useful ones, and auditors sample them later.

[Daily Work Systems] ---- 1. generate logs/config/history ----> [Evidence Pack]
[Team Reviews] ------ 2. approvals/tests/sign-off -----------> [Evidence Pack]
[Policies] ---------- 3. rules and review dates -------------> [Evidence Pack]
[Auditor] ----------- 4. requests sample --------------------> [Evidence Pack]
[Evidence Pack] ----- 5. proof of design + operation --------> [Auditor]

A good way to think about it: evidence sits between your operational reality and your audit claim. If you claim "production access is reviewed quarterly," the evidence is not the sentence. It is the access review export, the reviewer’s decision, the date, and the follow-up removals.

How it actually works

The mechanism is simpler than it sounds: for each important control, keep a repeatable bundle of proof that answers four questions:

1. What is the rule? — policy or procedure.
2. How is it configured? — system settings or screenshots/exports.
3. Did it operate during the period? — logs, reports, tickets, job history.
4. Who checked it? — review, approval, or test record.

One realistic end-to-end example: backup evidence

Imagine your company says: "Production database backups run daily, are encrypted, and are tested monthly."

An auditor will usually test that claim in three layers.

Step 1: They ask for the control description

You provide a short procedure document stored in your shared docs folder, for example:

• "Production Backup Procedure"
• owner: Engineering Manager
• review date: every 12 months
• says daily backup schedule, retention period, encryption expectation, monthly restore test

This proves the control is designed.

Step 2: They ask how the system is configured

You go to your provider’s dashboard and export or capture the settings.

Typical path: in your cloud provider’s dashboard, open the production database, then the Backups or Maintenance/Backups section. Save:

• backup enabled status
• schedule or backup window
• retention period
• encryption status if shown

If the dashboard supports export, use that. If not, take a screenshot that includes:

• the system name
• the date/time on your computer
• the visible settings

This proves the control is implemented.

Step 3: They ask whether it actually ran during the audit period

Now you need operating evidence, not just settings. In the same dashboard, open backup job history or event history and export the last 2-3 months. If your provider has no export button, save a PDF print of the history page.

Useful items here:

• successful backup timestamps
• failed jobs and whether they were resolved
• retention/deletion events if relevant

This proves the control operated.

Step 4: They ask whether restores are tested

This is where many teams fail. A backup is not strong evidence if nobody has shown it can be restored.

You provide one monthly restore test record, for example from your ticketing system:

• ticket title: "Monthly restore test - prod db - 2026-08"
• linked runbook used
• who performed the restore
• where it was restored (staging or isolated test environment)
• result: success/failure
• any follow-up actions
• manager review or comment

This proves the control is effective enough to trust.

Step 5: You store the bundle together

Instead of leaving these in five different tools, create one evidence folder structure such as:

• Compliance/Evidence/2026/Q3/Backups/
  • Backup Procedure.pdf
  • ProdDB-backup-settings-2026-08-31.pdf
  • ProdDB-backup-history-2026-07-to-2026-08.csv
  • Restore-test-ticket-4821.pdf
  • Reviewer-signoff.txt

That final folder is what lets you answer an auditor in hours instead of weeks.

When to use it (and when not to)

You need a deliberate evidence process whenever you expect an external party to rely on your controls: auditors, enterprise customers, regulators, insurers, or due diligence reviewers.

You probably do not need a heavyweight evidence program if you are a very small team with no formal audit target yet. But even then, keeping a light version now prevents expensive cleanup later.

You probably do not need this in full depth if:

• you are not making compliance claims to customers
• no contract requires an audit or control attestation
• the system is internal, low-risk, and not handling sensitive data
• the cost of preserving detailed evidence is higher than the business risk

Even then, backups, access changes, and incident records are worth keeping.

Trade-offs

Evidence discipline has real benefits, but each one costs something.

• Benefit: faster audits and customer questionnaires
  Cost: someone must collect, label, and review evidence on a schedule.

• Benefit: stronger credibility with auditors
  Cost: informal practices become visible; you may need to formalize approvals and ownership.

• Benefit: less dependence on employee memory
  Cost: more records to store and organize.

• Benefit: easier incident and change reconstruction
  Cost: longer log retention can increase storage cost and privacy obligations.

• Benefit: proof that controls operated over time, not just today
  Cost: recurring exports or automation work.

• Benefit: reusable evidence across audits
  Cost: naming conventions and folder structure need consistency, or the archive becomes a mess.

There is also a lock-in angle. If your evidence depends entirely on one vendor dashboard with short retention and weak export options, changing vendors or answering historical questions gets harder. A simple mitigation is to export key reports to your own document repository on a schedule.

In practice

Below are two practical patterns you can adopt immediately.

Example 1: Evidence folder checklist

Use a plain text checklist in your shared docs or repository. It is boring, which is exactly why it works.

Compliance/
  Evidence/
    2026/
      Q3/
        Access-Reviews/
          README.txt
          idp-user-export-2026-09-30.csv
          admin-group-members-2026-09-30.csv
          reviewer-signoff-2026-10-02.txt
        Backups/
          README.txt
          backup-procedure-v3.pdf
          prod-backup-settings-2026-09-30.pdf
          backup-job-history-2026-07-01_to_2026-09-30.csv
          restore-test-ticket-4821.pdf

What it does: gives every control a predictable home and naming pattern. Gotcha: if filenames do not include dates in YYYY-MM-DD format, sorting becomes painful and people upload duplicates.

Example 2: Simple evidence manifest in JSON

If your agency or internal team wants a machine-readable index, keep a small manifest next to each evidence set.

{
  "control_id": "BK-01",
  "control_name": "Production backups run daily and are restore-tested monthly",
  "period": "2026-Q3",
  "owner": "engineering-manager@example.com",
  "artifacts": [
    {
      "type": "procedure",
      "file": "backup-procedure-v3.pdf",
      "covers": "design",
      "reviewed_on": "2026-07-02"
    },
    {
      "type": "configuration-export",
      "file": "prod-backup-settings-2026-09-30.pdf",
      "covers": "implementation",
      "captured_on": "2026-09-30"
    },
    {
      "type": "job-history",
      "file": "backup-job-history-2026-07-01_to_2026-09-30.csv",
      "covers": "operation",
      "captured_on": "2026-09-30"
    },
    {
      "type": "restore-test",
      "file": "restore-test-ticket-4821.pdf",
      "covers": "effectiveness",
      "performed_on": "2026-08-15"
    }
  ]
}

What it does: makes it obvious whether a control has design, implementation, operation, and review evidence. Gotcha: do not let the manifest become the only thing you maintain; auditors care about the underlying artifacts, not the index.

Example 3: CLI export when a dashboard is not enough

If your team does have command-line access, exporting evidence can be more reliable than screenshots.

⚠️ Do not run commands against production systems unless you understand what they do. Read-only listing commands are usually safe; change commands are not.

aws rds describe-db-instances --db-instance-identifier prod-db > prod-db-config-2026-09-30.json
aws rds describe-db-snapshots --db-instance-identifier prod-db > prod-db-snapshots-2026-09-30.json

What it does: saves database configuration and snapshot history to dated files you can archive. Gotcha: JSON exports are excellent evidence, but only if someone can explain them; keep a short README saying what fields matter.

What good evidence looks like

Use this quick test before saving anything:

• Dated — can someone tell when it was true?
• Scoped — does it clearly refer to the production system, account, or group in question?
• Repeatable — could another person collect the same artifact next month?
• Tamper-resistant enough — export, PDF, ticket, or system report is better than a cropped image in a slide deck.
• Linked to a control — if you cannot say what claim it proves, it is probably just documentation noise.

A final practical rule: screenshots are acceptable when a system offers no export, but they are the weakest common form of evidence. Prefer exports, reports, tickets, and logs first; use screenshots as support, not the whole story.

Further reading

• AICPA Trust Services Criteria
• ISO/IEC 27001 Annex A
• NIST SP 800-53 Rev. 5
• The "Logging" and "Access Control" sections of the OWASP Security Testing Guide
• The "Audit Logging" guidance in the CIS Controls documentation

This article was written by an AI system and published pending human review. Verify anything you intend to act on.