SOC 2

SOC 2 Type 2: run the evidence period before the auditor asks

A Type 2 report tests whether controls operated throughout a stated period. Set the dates with the CPA firm, keep complete event populations and fix missing evidence while there is still time.

SOC 213 October 20269 min read

SOC 2 Type 2 is a CPA firm’s report on whether your described controls were suitably designed and operated effectively throughout a specified period. The period is the hard part. A policy approved on the last day does not show that people followed it for the months before. An access review you never performed cannot be reconstructed from a current screenshot. If a buyer has asked for Type 2, the practical question is not which tool to buy. It is which controls you can prove ran on every date the report will cover.

The AICPA’s SOC suite describes assurance reports provided by CPAs, and its Trust Services Criteria set the criteria used to evaluate controls. Both primary sources are linked in Keep reading. This guide turns that distinction into an operating plan for a first compliance hire or engineering lead. It is not an audit opinion: your independent CPA firm decides scope, testing and the wording of the report.

What does a SOC 2 Type 2 report test?

Type 1 answers a point-in-time design question. Type 2 adds an operating question across the stated period. In either case, management describes the system and its controls; the CPA firm examines that description and the controls against the applicable Trust Services Criteria. Security is the Common Criteria base. Availability, processing integrity, confidentiality and privacy are selected when they fit the service and the buyer’s request.

The criteria are not a vendor checklist. AICPA CC6.1 addresses logical access security; CC7.2 concerns monitoring for anomalies; CC8.1 addresses change management; CC9.2 concerns risks from vendors and business partners. You choose controls that meet the criteria in your environment, and the auditor tests the controls you claim. The evidence examples below are ways to demonstrate operation, not prescribed AICPA artefacts.

  • CC6Approved access and timely removalKeep the full joiner and leaver population, approval records, system access logs and dated reviews.Access
  • CC7Security alerts investigatedKeep the alert population, investigation tickets, owners, decisions and closure dates.Operations
  • CC8Production changes reviewed before releaseTie the complete change population to pull requests, approvals, tests and deployments.Changes
  • CC9Critical vendors assessed and monitoredKeep the inventory, risk tiers, dated reviews, exceptions and follow-up decisions.Vendors

These are illustrative records for selected Common Criteria. Agree the actual control wording and test approach with the CPA firm before the period begins.

A passing configuration check is one moment of evidence. A Type 2 examination asks whether the control operated as described over time. If your policy promises quarterly access reviews, a current user list is not a substitute for the reviews from the quarters inside the period.

Agree scope and dates with the CPA firm first

Choose the service and systems the report will cover, which Trust Services Categories apply, whether subservice organisations are carved out or included, and the beginning and end dates. Write down the exact system boundary: production environments, identity provider, code repository, support system, staff groups and vendors. A buyer who needs assurance over one product will not be helped by a report scoped to a different one.

There is no honest universal observation period you can buy from a platform. The CPA firm and management agree a period that permits meaningful testing, and buyers may have their own expectation of how much history they want to see. Ask the auditor what period it will accept for your controls and ask the buyer what report it requires. Do this before announcing a delivery date to sales.

Name an owner for the system description and management assertion as well as for the controls. Those are management’s words in the report, not text the CPA firm can invent for you. The broader SOC 2 compliance guide covers scoping and the report sections; the SOC 2 audit guide covers choosing and engaging the auditor.

Build an evidence calendar before the period starts

For each control, record the owner, the promised frequency, where evidence is generated, how long it is retained and who checks it. A calendar is useful only if it follows the wording of the control. If the policy says reviews happen every quarter, the calendar needs a dated review in each quarter covered. If the control says every production change needs approval, a monthly screenshot of branch settings is not enough; you need a complete change population.

  • DailyCollect event recordsKeep alerts, deployments, access changes and other events with original timestamps and stable identifiers. Do not rely on a dashboard that overwrites history.Raw population
  • WeeklyReconcile gapsCompare the event source with the evidence store. Find missing tickets, broken integrations and changes that bypassed the usual path while the people involved still remember them.Owner review
  • MonthlyRead control healthReview overdue evidence, exceptions, staff changes and vendor changes. Record the decision and the person who made it.Management trail
  • Period endFreeze the populationsExport the full sets the auditor may sample: people who joined or left, production changes, incidents, access reviews and vendors in scope.Sample base

These are suggested working intervals, not frequencies mandated by CC6, CC7, CC8 or CC9. Your own control description and risk decide the frequency. A slower control can be valid if it meets the criterion and your auditor accepts it; a promised fast control that nobody performs will fail its own test.

Run the controls through the whole period

The audit period starts only when controls are actually operating. A readiness checklist can show that an access review process exists. It cannot create evidence that the review occurred three months ago. Start by testing one cycle yourself: select a leaver, a production change, an alert and a vendor review. Follow each from the original event to the approval or decision, then to the record you would hand to the auditor.

Keep the population as well as the selected examples. If the auditor asks for all production changes in the period, a folder of ten attractive pull requests is not the full population. Preserve the export or query that produced the list, the time range and any exclusions. The same principle applies to people who left, incidents, access grants and vendor renewals. Completeness is what lets a sample say anything about the period.

  • Access: reconcile HR departures against identity and application accounts, including contractors and service accounts where your control covers them.
  • Changes: reconcile deployments with review and test records, and document the emergency path separately.
  • Alerts: retain both the alerts and the investigation outcomes, including a reason when an alert was closed as benign.
  • Vendors: preserve review decisions and the report or certificate period you examined, not just the file itself.

When a gap appears, record it, its cause, who approved the remedy and the dates affected. Fixing it promptly may reduce the period of a control failure, but it does not erase the failure. Quietly backfilling a review or changing a timestamp makes the evidence less trustworthy and gives the auditor a larger problem to resolve.

Prepare for samples and exceptions

The CPA firm chooses its procedures and samples. There is no universal sample count that proves a Type 2 control. Ask the auditor for its request list early and deliver a population that can be reconciled to the underlying systems. For each selected item, provide the original record, the control owner’s action and the date. Give context for a missing or unusual item before the auditor has to infer what happened.

An exception is a test result, not an automatic failed report. Its effect depends on the control, how often it failed, the period affected, compensating controls and the auditor’s judgement. A single late review and a pattern of unapproved production changes are not the same finding. Management should explain exceptions accurately and describe remediation without claiming that a later fix changed the historical test result.

If a provider operates part of your system, the report must explain the treatment of its controls. Under a carve-out, read the provider’s report and identify the complementary subservice organisation controls and the user entity controls on which your own controls depend. A cloud provider’s SOC report is evidence about that provider’s scoped service, not a replacement for examining your own operations.

Read the report before you share it

The final document should identify the system, the period, the categories in scope, management’s assertion, the service auditor’s opinion, the controls tested, the procedures and results. Before it goes to a buyer, compare those items with the promise made in the RFP. A clean opinion over the wrong system or period will still leave the buyer’s question unanswered.

Read the exceptions, complementary user entity controls and subservice organisation section as carefully as the opinion. The buyer’s security team may ask about them. Agree a distribution process with your CPA firm because a SOC 2 report is generally shared with intended users under controlled terms, unlike a public marketing badge. Do not say that Evidr issued or certified the report. Only the independent CPA firm can issue the SOC 2 attestation report.

Where software helps, and where it stops

Evidr’s product pages describe evidence uploads with review and control mapping, monitoring that flags evidence approaching expiry, and scoped read-only access for external auditors to approved evidence. These can reduce clerical work and make a missing record visible during the period. The SOC 2 framework page shows how the platform organises controls for Type I and Type II. Pricing is published separately, so check the current plan before assuming a feature is included.

The case against buying software is real. A small team with few systems, a disciplined owner and reliable exports can run an evidence calendar in a spreadsheet and shared drive. Evidr cannot choose the scope, perform a missed review, decide whether an exception is material or write the CPA opinion. If those are your gaps, a platform does not shorten the observation period; assign owners and book the auditor first.

02Questions

Common questions.

Ready to get audit-ready?

Start on the free Starter plan, or talk to us about SOC 2, ISO 27001, HIPAA or any framework and see the platform on your own stack.