When the report leaves something out
An access review shows that every account has an approved owner. The reviewer signs off, and the company records the task as complete. Later, someone discovers that the export excluded a separate group of administrators who sign in directly to the application.
The reviewer made reasonable decisions about the accounts they could see. The missing information limited what the review could accomplish.
SOC 2 CC2.1 addresses the information used to perform internal controls. In plain language, the organization needs to obtain or produce information that is useful and dependable, then use it in its control processes. The AICPA Trust Services Criteria provide the authoritative wording.
An outdated asset list can leave systems outside a vulnerability scan. An incomplete incident timeline can lead managers to underestimate an outage. Information quality matters wherever a control owner relies on a report, record, or external source to make a decision.
This is the sixth article in our SOC 2 Guide. CC2.1 focuses on the information itself. CC2.2 and CC2.3 address communication within the organization and with outside parties. The fictional examples below illustrate possible approaches, not required controls or headcount-based rules.
Start with the decision the information supports
Choose an important control and ask what its owner needs to know. For an access review, that includes which systems are covered, who can access them, what permissions each account has, and which business owner can assess the need.
Write down where those details come from. An identity provider may list centrally managed accounts, while an application maintains local administrators separately. HR records may identify employees who have left, but contractors could require another source. Reconcile those sources before assuming one export represents the whole population.
Set expectations for timing. A report generated before a significant staffing change may be unsuitable for a review performed afterward. Specify the date or period the information covers and how the reviewer handles changes between extraction and approval.
A short report description can answer the questions a reviewer would otherwise have to guess:
- Which system, cloud account, business unit, and account types are included?
- What filters or exclusions apply, and why are they appropriate for this control?
- When was the data extracted, what period does it represent, and who owns the report?
- How is the report checked, and what happens when information is missing or unreliable?
Check how the report was produced
Follow selected records from the underlying system through to the report people use. Look for filters, calculations, joins between datasets, and manual changes that could alter the result. Also work in the other direction: choose records from the source and check that they appear in the output when they should. Looking only at the finished report may never reveal what was omitted.
Suppose a spreadsheet matches application accounts to the employee directory using email addresses. A contractor may use a different address, or a renamed employee may have two records. Keep unmatched entries visible for investigation. Dropping them automatically could hide precisely the accounts that need attention.
Where feasible, compare coverage with a source that does not depend on the same query. A vulnerability dashboard may show no overdue findings because its connector never included a newly created cloud account. Comparing the scanner's account list with the cloud organization's account inventory can expose the gap. Check relevant standalone accounts too; one inventory may have boundaries of its own.
Totals can help identify unexpected changes, but equal row counts do not prove that the entries or permissions are correct. Investigate exceptions and check selected details. A scheduled report can consistently reproduce the same incomplete query, so successful automation alone provides little assurance about coverage.
Treat changes to report logic as changes that can affect the control. If a vendor adds an account category or an analyst changes a filter, test the effect before relying on the next output. Keep the relevant query or export settings, the change record, and the results of the check. Scale the review to the consequences of a misleading report.
Keep information usable as the service changes
CC2.1's points of focus consider information needs, data sources, processing, and quality. They also address records of assets and data flows. These considerations help apply the criterion; they do not prescribe one reporting system or require an identical checklist for every organization.
Describe important paths that customer information takes through the service. Include a support export or outside processing service when it affects how information is handled. For devices used away from the office, record who has custody and which business data may be stored there. Assign an owner to update these records when the service changes.
Information from outside the company needs context too. A provider's status notice may concern a different region from the one you use. Check its coverage and timing before relying on it to explain an incident. NIST SP 800-137 offers supporting guidance on using information about assets, threats, vulnerabilities, and control performance for security decisions. It is an optional reference, not an additional SOC 2 requirement.
Protect reports according to their contents. An account export can reveal privileged users; a support report may contain customer information. Give reviewers enough context to make the decision, restrict access to sensitive details, and preserve a way to trace summaries to their supporting records.
A bootstrapped company with two founders and three employees
Consider a five-person software company. One founder handles engineering, while the other manages operations and customer relationships. They use a small number of hosted applications and maintain a shared list of systems.
Before their next access review, the operations founder compares that list with subscription records and asks the team about newly introduced tools. They discover a support application purchased for a customer pilot. Its accounts were absent from earlier reviews.
The engineering founder exports accounts from the application, checks the available account categories, and confirms that local administrators appear. The founders add the application to the review instructions and document which source provides each account list.
They save the exports with extraction dates and keep review decisions separately so later edits do not obscure the original data. A brief note records the gap, the access checked, and any removals required. They also assess whether earlier omissions left inappropriate access unresolved.
Evidence to keep: the system list, report instructions, dated exports, coverage checks, review decisions, and records resolving the omission. This arrangement may suit a simple service. Complex integrations, sensitive customer data, or significant contractual commitments may justify stronger checks or qualified outside help even with five people.
Reliable information at 100 people
A hypothetical 100-person provider has several department-owned applications and a central identity platform. Its security team receives an automated access report each month, while department managers make the business decisions. The monthly schedule is this company's choice, not a frequency specified by CC2.1.
The report owner documents which applications feed the report and which require a separate export. Before managers begin, the owner checks that expected data arrived, compares material changes with onboarding and offboarding activity, and investigates missing feeds.
Suppose an application's connector fails after a vendor update. The dashboard still displays last month's accounts. The team adds a visible extraction timestamp and a warning when expected data has not arrived. For the affected review, it obtains a fresh application export, checks its scope, and records the temporary method. It also checks whether anyone already relied on the stale output.
When a department launches a new service, the security team checks whether inventories and review instructions cover the new application before relying on the next scheduled report. A named report owner coordinates these changes with the people who operate the source systems.
Evidence to keep: source descriptions, connector checks, exception records, validated replacement exports, report-change reviews, and updated system records. Automation can reduce repetitive work, but someone still needs responsibility for detecting failures and resolving gaps.
Coordinating information across 1,000 people
At a hypothetical 1,000-person organization, regional teams produce reports for a central risk committee. One unit counts a vulnerability as resolved when a patch ticket closes; another waits for a follow-up scan. Combining those figures gives leadership a misleading view of progress.
The central owner works with the units to define the measure and its exclusions. Each unit identifies the systems covered and the date of its latest supporting data. Reports distinguish confirmed remediation from work awaiting verification, with links to the underlying records.
During an acquisition, management identifies systems that are not yet connected to central reporting. Those exclusions remain visible, with an owner and an interim reporting arrangement. A favorable companywide average should not conceal an unassessed part of the business. The report explains how the missing coverage limits its conclusions.
Access to detailed information is also tiered. Committee members may need a summary and the ability to request supporting records, while investigators require detailed event data. The organization checks that summaries remain traceable without distributing sensitive operational records to every reader.
Evidence to keep: agreed reporting definitions, documented exclusions, checks performed by contributing teams, acquisition reporting plans, and corrections to inaccurate figures. Preserve significant changes in methodology so comparisons between periods remain understandable. A large organization may need more coordination, but headcount alone does not determine the right design.
Evidence through the Type 2 period
A SOC 2 Type 2 examination addresses control design and operating effectiveness over a specified period. Retain the information people actually used during that period. A freshly generated account report may describe today's access while providing little support for a review completed months earlier.
For important recurring reports, keep the relevant output, extraction parameters, review date, and evidence of the checks performed. A note saying only "validated" leaves the reader unable to tell what was checked or what happened. Retain corrections alongside the original records with an explanation of their effect.
If a report gap is discovered, determine which decisions may have been affected and whether those decisions need another review. Record the investigation and actual correction dates. Do not silently replace an inaccurate report after someone has relied on it or present a later reconstruction as evidence captured at the time.
Discuss evidence expectations and appropriate retention with the examining CPA firm, taking account of privacy obligations and the sensitivity of the records. The AICPA SOC 2 examination guide is the professional reference for these engagements. These examples do not guarantee an examination outcome.
Trace one report before the next review
Take a report used in an important control and follow it back to its sources. Ask what could be missing, how old the information is, and whether another reviewer could understand how the result was produced. Correct the most consequential weakness and preserve the check.
The next article, CC2.2 Internal Communication, considers how people receive the information they need to carry out their responsibilities.
Support for your SOC 2 program
Genius GRC helps organizations develop practical controls and organize supporting evidence. Schedule a free consultation to discuss the information your control owners rely on and where clearer reporting or validation would help.
Explore the SOC 2 Guide for the full series.
This article provides general guidance. Adapt the examples to your risks, examination scope, and obligations with your advisers and auditor.