SOC 2 CC2.1: Relevant and Quality Information

When the report leaves something out

You finish an access review, approve the accounts that need access, and file the evidence. Then someone asks about a group of administrators who sign in directly to the application. They never appeared in your export.

You may have made sound decisions about every account you saw. You still need to go back, because the information you relied on left out part of the job.

SOC 2 CC2.1 asks you to obtain or produce relevant, quality information and use it to support internal control. The AICPA Trust Services Criteria provide the authoritative wording. Think about your asset lists, incident timelines, vendor reports, and access exports. Each shapes a decision someone has to make.

This sixth article in our SOC 2 Guide focuses on that information. CC2.2 and CC2.3 follow how it moves inside and outside your organization. The scenarios here are fictional; use them to test your thinking, not as headcount-based control requirements.

Start with the decision the information supports

Pick a control you know well and ask its owner what they need to decide. For an access review, they need the systems in scope, the people and accounts with access, their permissions, and a business owner who can assess the need.

Now trace where those details come from. Your identity provider may cover centrally managed accounts while the application keeps local administrators separately. HR may cover employees but leave contractors to another source. Put those pieces together before treating one export as the whole population.

Timing matters too. If staffing changed between the export and the review, decide how the reviewer will account for it. Give the report enough context that another person can understand it without guessing:

  • Which systems, cloud accounts, business units, and account types does it cover?
  • Which filters or exclusions apply, and why do they fit this control?
  • When was it extracted, what period does it describe, and who owns it?
  • What checks make it dependable, and where do missing or unreliable records go?

Check how the report was produced

Follow a few records from the source through the filters, calculations, joins, and manual edits into the finished report. Then choose records from the source and check that they appear where they should. Starting only with the output makes it easy to miss what never arrived.

For example, your spreadsheet may join application accounts to the employee directory by email address. A contractor using another address becomes an unmatched row. Keep that row visible and investigate it; dropping unmatched entries can hide the accounts that most need your attention.

Where you can, check coverage against a source independent of the report’s query. Compare your scanner’s cloud-account list with your cloud organization’s inventory, while also considering standalone accounts outside that inventory. Equal row counts are useful clues, but they cannot establish that the permissions or individual entries are correct.

When someone changes a filter or a vendor adds an account category, test what that does to the output before your next control relies on it. Keep the export settings or query, the change record, and the check. Spend the most effort where misleading information could cause the greatest harm.

Keep information usable as the service changes

CC2.1’s points of focus cover information needs, sources, processing, quality, and records of assets and data flows. Bring those considerations into your own service. Where does customer information travel? Does a support export leave the main system? Does an outside processor receive it? Who has custody of a device used away from the office, and what business data does it hold?

Assign someone to update those records as the service changes. Check external information with the same care. A provider’s status notice for another region may not explain your incident. NIST SP 800-137 offers supporting guidance on using security information for decisions; it is an additional reference, not a SOC 2 requirement.

Also consider who should see the details. Account exports identify privileged users, and support reports may contain customer information. Give your reviewers enough to decide while restricting sensitive records. Keep summaries traceable to their sources.

A bootstrapped company with two founders and three employees

Imagine you lead operations at a five-person software company. Your cofounder handles engineering, and the three employees work across support and delivery. Before your next access review, you compare the system list with subscription records and ask everyone about new tools.

That conversation uncovers a support application bought for a customer pilot. It never reached your review list. Your cofounder exports its accounts, checks that local administrators are included, and helps you establish where future account lists will come from.

You add the application to the review instructions, save the dated exports separately from review decisions, and record the permissions checked and removals needed. You also look back to assess whether the omission left inappropriate access unresolved.

In Vanta, you could attach the coverage check and dated export as custom evidence linked to the relevant control. Keep the description clear about what you checked and when. Uploading the file cannot settle whether the account population is complete; that is the work you and your cofounder just performed.

Keep: the system list, report instructions, source exports, coverage checks, review decisions, and resolution of the omission. Complex integrations, sensitive data, or significant customer commitments may call for stronger checks or qualified outside help even in a five-person business.

Reliable information at 100 people

At a fictional 100-person provider, your departments own several applications, and security assembles a monthly access report for managers. Monthly is the schedule this company chose for its risks, rather than a frequency set by CC2.1.

One month, a connector fails after a vendor update. The dashboard still looks orderly, but one application’s accounts are a month old. Your report owner spots the extraction date, obtains a fresh export, checks its coverage, and records the temporary method. They also find out whether anyone already used the stale report.

For supported Vanta automated tests, you can review the test criteria and supporting evidence to understand the resources evaluated and available retrieval details. Compare that coverage with the systems your control needs. The available detail varies by test and rollout; keep a separate method for sources the integration does not cover.

Before each review, your owner checks that expected data arrived and investigates material changes against onboarding and offboarding activity. New services trigger updates to inventories and instructions. Keep source descriptions, connector checks, replacement exports, exception records, and report-change reviews so you can explain how the information became fit for use.

Coordinating information across 1,000 people

Now imagine presenting a companywide vulnerability report to leadership at a 1,000-person organization. One region counts a finding as resolved when its patch ticket closes. Another waits for a verification scan. Your combined number gives them a confidence the underlying records do not support.

Bring the regional owners together to agree the measure, exclusions, and supporting dates. Separate confirmed remediation from work awaiting verification. When an acquisition introduces systems outside central reporting, show that coverage gap, its owner, and the interim reporting arrangement. Explain how it limits the conclusions.

Your team could use Vanta’s evidence records to organize the reporting definitions and regional validation results, with clear owners for updates. Keep the operational source records available for tracing the summary. Leadership may need the summary and a route to supporting evidence; investigators may need detailed event data. Distribute each according to its sensitivity.

Keep: agreed definitions, visible exclusions, local checks, acquisition reporting plans, corrections, and material methodology changes. Explain changes that affect comparisons between periods. Your coordination should reflect service complexity and consequences, as well as the number of people involved.

Evidence through the Type 2 period

A SOC 2 Type 2 examination addresses control design and operating effectiveness over a specified period. Keep the information your reviewers actually used then. An export generated today cannot, by itself, explain the accounts available to a reviewer months ago.

For important recurring reports, retain the output, extraction parameters, review date, and checks performed. Write what you checked and what you found instead of leaving a bare “validated” note. Preserve corrections alongside the original records and explain their effect.

When you discover a reporting gap, identify the decisions affected and decide whether they need another review. Record actual investigation and correction dates. Do not quietly replace inaccurate information or present a later reconstruction as contemporaneous evidence.

Agree suitable retention and evidence expectations with your examining CPA firm, taking privacy and sensitivity into account. The AICPA SOC 2 examination guide is the professional reference. These examples do not guarantee an examination outcome.

Trace one report before the next review

Take one report your team depends on and follow it back to its sources. Ask what might be missing, how old the data is, and whether another reviewer could reproduce your reasoning. Fix the most consequential weakness and preserve the check.

Next, CC2.2 Internal Communication looks at getting that information to the people who need to act on it.

Support for your SOC 2 program

Genius GRC can help you work through the reports your control owners rely on and the checks that make them useful. Schedule a free consultation to discuss your program.

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.

More Posts

SOC 2 CC4.1 Ongoing and Separate Evaluations

CC4 Monitoring Activities Imagine you’re looking at your weekly backup report. Every job succeeded. Nothing needs your attention, so you move on. A few weeks later, your team runs a restoration exercise. The backup is there, but nobody running the exercise can retrieve the key needed to decrypt it. Recovery

SOC 2 CC3.4 Identifying and Assessing Changes

Imagine someone on your team removes an approval step to make a routine process easier. The change looks sensible to the people doing the work. Then, at the next risk meeting, you discover that the step was there to protect a customer commitment. Nobody asked the control owner before it

SOC 2 CC3.3: Fraud Risk

Consider deliberate misuse before it happens Imagine your team is gathering evidence for a customer review. Someone notices that several access reviews required by your policy were completed late. A manager suggests changing the dates so the records look consistent with the process. That’s an uncomfortable moment, and it’s worth

SOC 2 CC3.2: Identifying and Analyzing Risks

Give the risk a useful description Imagine opening your risk register and finding an entry labeled “data loss,” rated high. Your engineering team points to the daily backups, and everyone moves on. Then you run a recovery exercise. Restoring a large customer account takes longer than the recovery time you’ve