SOC 2 information produced by the entity: why auditors test your reports

Auditors rely on lists and reports you produce, such as user lists, ticket exports and log extracts. Before using them they check that the report is complete and accurate. You can make that easy by documenting where each report comes from, the filters used and a way to verify it against the source.

The idea

For a sampled control, the auditor first needs the full population: all new hires, all production changes, all terminated users. If the list is missing someone, the sample is wrong and the test means nothing.

This is often called testing information produced by the entity. The auditor checks the source, the query or filters, and the completeness.

Common populations

• Employees and contractors, from HR and your identity provider.
• Production changes, from the repository and deployment tool.
• Access grants and removals, from the identity provider and key systems.
• Security incidents, from the ticket system.
• Vulnerabilities and fixes, from scanners and tickets.
• Vendors, from procurement and finance.

How to make a report credible

• Name the source system and the date and time of extraction.
• Save the query, filters or report definition with the export.
• Show the total count and how it ties out to something else, for example headcount from HR against accounts in the identity provider.
• Use the same method each time, so results compare across the period.
• Have someone other than the control performer extract the report when possible.

Where reports go wrong

• A filter that silently hides some records, for example only active users.
• Different date ranges used across exports.
• Manual edits in a spreadsheet before sharing.
• Deleted or archived items that no longer appear in the live view.
• Two sources that disagree, such as HR and the directory, with nobody reconciling them.

Reconcile as a habit

A monthly check helps. Compare the HR roster with accounts in the directory and key apps. Compare the deploy log with merged pull requests. Note differences and the explanation. When the auditor asks how you know your population is complete, you have a record.

Document the lineage

Add a short table to your evidence folder: report name, system, who runs it, steps, and a note on known gaps. Update it when tools change. See evidence folder structure.

Why this matters for automation

If a tool collects evidence for you, confirm what it covers. A connector that only sees one cloud account or one repository organization gives a partial population. Check scope before relying on it.

A quick example

Say the auditor samples ten leavers from your terminated user list. They will ask how you know the list holds every leaver. You show the HR export for the period with the count, the identity provider export of disabled accounts with the count, and your reconciliation note explaining the two extra service accounts. The sample then rests on a population that ties out. If you cannot explain the difference, expect extra testing or an exception.

Quick check

Last reviewed: 19 October 2026.