SOC 2

SOC 2 certification: what buyers ask for and how to get the right report

There is no SOC 2 certificate. A CPA firm issues a report on a defined system and period. Here is the evidence path a founder can put in front of a buyer and an auditor.

SOC 27 November 20269 min read

SOC 2 certification is a common search phrase, but the outcome is a SOC 2 report, not a certificate. A licensed CPA firm examines a service organisation’s described system and issues an assurance report. No compliance platform can issue it, and a readiness badge cannot stand in for it. If a customer says “send your SOC 2 certificate”, clarify whether they need a Type 1 or Type 2 report, which service they are buying and the period they expect it to cover.

That distinction changes the buying decision. You need an assessor for the independent opinion, people who operate the controls and a way to preserve evidence. Software can reduce repeated collection, review and sharing work. It cannot create a missing quarterly review after the quarter ends. Turn the procurement request into a work plan with named owners and records.

Document or claimWho creates itWhat it tells a buyer
Readiness dashboardYour team or its softwareCurrent management view of controls, owners and gaps; no independent opinion
SOC 2 Type 1 reportIndependent CPA firmOpinion on the described system and relevant control design at a point in time
SOC 2 Type 2 reportIndependent CPA firmOpinion that also addresses control operation over the period in the report
ISO 27001 certificateAccredited certification bodyCertification of an information security management system within its stated scope

The words “certified” and “audit ready” do not identify the document a buyer may rely on.

Is SOC 2 certification the right term?

In conversation, people often say “SOC 2 certified”. For a contract, security questionnaire or sales page, name the report and its issuer instead. The AICPA describes SOC as a suite of assurance services CPAs provide, and its Trust Services Criteria are used in attestation or consulting engagements. This is not a programme in which a software vendor awards a universal pass certificate. The report concerns a particular described system, selected criteria and an examination date or period.

If procurement sends a checklist with a certification field, ask what evidence satisfies it. A useful answer is: “Our SOC 2 Type 2 report for the named service covers the period shown in the report; we can share it under the appropriate terms.” If your examination is still underway, say so and give the anticipated milestone only if your CPA firm has agreed it. Do not describe a readiness score or an auditor engagement letter as a completed report.

ISO 27001 is different. It is a certification scheme for an information security management system, and an accredited certification body issues the certificate after its process. A company may pursue both because a customer asks for both, but a SOC 2 report does not automatically grant ISO 27001 certification. The SOC 2 compliance guide explains the criteria and the evidence the team must operate.

What report does your buyer actually need?

Before buying software or setting a deadline, ask the buyer four things: which service and environments are in scope, whether Type 1 or Type 2 is required, which Trust Services Criteria matter, and whether the report must cover a particular period. A buyer of one hosted product may not accept a report whose system description covers an unrelated corporate service. A report for a date cannot demonstrate operation through a later period merely because your dashboard is now green.

Type 1 and Type 2 answer different questions. Type 1 addresses control design and implementation at a specified point. Type 2 also addresses operation throughout the report period. If a buyer requires a Type 2 report, a Type 1 report may help with an interim review, but only the buyer can say whether it meets the contract. The CPA firm sets its examination procedures and decides what opinion it can support.

Agree how the final report will be shared. Some report material is meant for specified users and may include a description of your system, control tests and exceptions. Your sales team should not upload the report to a public page by default. Decide who approves release, which recipients are authorised and how a buyer can ask a follow-up question about scope.

Which criteria and system are in scope?

The AICPA Trust Services Criteria cover security, availability, processing integrity, confidentiality and privacy. The examination does not become more persuasive just because you select every category. Pick the criteria relevant to the service and customer promise with your CPA firm. Then write a system description that identifies the service, boundaries, infrastructure, people, data and significant dependencies. The AICPA publishes separate description criteria for this task.

Under CC6.1, show how logical access controls operate for the users and systems inside the described boundary. Retain the records that demonstrate each control. A screenshot that multifactor authentication is on today cannot by itself prove who had privileged access during the past period, who reviewed it or how an exception was resolved. For each control, name its owner, frequency, source population, review decision and retained record.

  • ScopeDescribe the serviceList production systems, relevant environments, third parties and the customer-facing commitments the report is meant to address.Boundary
  • CC6.1Prove logical accessKeep user populations, access grants and removals, reviewer decisions and exceptions for the systems in scope.Access
  • ChangeTrace production changesRetain the change record, approval, testing and deployment event that together show the control operated.History
  • VendorReview dependenciesRecord which service providers matter to the boundary, the review performed and any unresolved risk decision.Dependency

How do you get the SOC 2 report step by step?

Start with the buyer request and the system boundary, then engage a CPA firm early enough to challenge the proposed scope. A readiness adviser or software vendor can help organise the work, but neither should be presented as the independent issuer. Ask the CPA what complete populations it expects, how exceptions are treated and what period the engagement will address. Do not promise a standard number of weeks; the time depends on controls already operating and the examination agreed.

  1. Write the service boundary and select the criteria with the CPA firm and business owner. Keep the buyer’s actual requirement beside the scope decision.
  2. Inventory controls and assign named owners. Record the action, cadence, source system, expected evidence and a way to identify missed work.
  3. Run a readiness review with real records. Test a complete access population, a change and an exception, rather than only a sample of successful screenshots.
  4. Operate the controls and retain contemporaneous evidence. For Type 2, preserve the history throughout the agreed examination period.
  5. Give the CPA complete requested populations and explain exceptions. The firm performs its own procedures and issues its own opinion and report.
  6. Review the issued report for the service, period and distribution terms, then create an approved buyer-sharing process.

The plan is deliberately sequential. A Type 2 period cannot be reconstructed from a later dashboard. If a review was missed, record and remediate the lapse; do not fabricate an approval. The SOC 2 audit guide on this site deals with the examiner’s request list, while the Type 2 guide develops the period and population questions in more detail.

What evidence will the CPA test?

Expect the auditor to ask for the full population from which documents were selected. For access, that may mean all relevant users, privileged accounts, joins, moves and departures during the period. For changes, it may mean the production changes from which a sample is chosen. For recurring reviews, it means records for each scheduled review and any exception. The exact procedures are the CPA firm’s decision under its engagement; a platform should make the original records and their dates findable.

A useful evidence record connects a control claim to a source identifier, collection time, system in scope, reviewer and decision. Preserve rejected and replaced versions where they explain the history. If an integration failed, show the gap and how it was covered or remediated. A green status after reconnection does not prove that collection was complete while it was broken.

How should you evaluate readiness software?

Use a control the CPA will actually test. Connect a source with minimal permissions, collect a complete population, map it to the scoped control, reject an inadequate record, approve a valid one and export the decision trail. Then break the source connection and check whether the product surfaces stale evidence. This is more useful than comparing counts of integrations or an overall readiness percentage.

Evidr’s evidence collection workflow supports uploads, AI-assisted review with confidence scoring, sensitive-data detection, approval and control mapping. Its continuous monitoring page describes evidence expiry alerts, and its auditor access page describes scoped read-only access to approved records. Those are the functions to test if your team repeatedly chases evidence and sends it to assessors. Your team decides relevance and exceptions, operates the controls, and gives the CPA firm the records it needs for its opinion.

Compare that trial with a controlled spreadsheet and source exports. For a narrow service with a small number of controls and an attentive owner, the simpler system may be enough. Software earns its cost when it removes repeated collection and review work while keeping the history more reliable. Check the current pricing page for the plan and usage terms that apply to your scope; do not make a budget from a generic SOC 2 cost estimate.

How do you answer a buyer after the report is issued?

Answer with the exact report type, covered service, report period and issuer. If the buyer asks whether an exception affects its use of your service, route the question to the security owner and the CPA firm where appropriate. Do not edit the report language in a sales summary. Keep a record of who approved sharing and which version the buyer received.

When the next report period begins, continue operating controls and reviewing exceptions. A report is evidence about the scope and period it states; it is not a permanent guarantee about every future system change. If you add a product, a cloud provider or a material data flow, ask whether the system description or controls need to change. That is where continuous evidence collection helps a small team, provided someone reads the exceptions.

How Evidr helps prepare a SOC 2 evidence pack

Evidr can organise control mappings, collect and review evidence, show expiry and give an external auditor scoped access to approved material. Use its SOC 2 framework and evidence collection pages to see the advertised workflow, then test it with your own access review and one failing case. This is a practical way to reduce the clerical work between a buyer request and a reviewable evidence pack, especially if the same records support another framework.

Evidr organises reviewed evidence for control owners and gives an external auditor scoped access to approved material. Management operates the controls and fixes missing records; a qualified CPA firm performs the examination and issues the SOC 2 report. Test a real access review and a failing case, then decide how much repeated collection the platform removes.

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.