For a small security or operations team

SOC 2 readiness for a small team

Updated 7 November 2026. Published by GRCompliance.

SOC 2 is an attestation report. An independent auditor examines the controls you describe and issues an opinion. It is not a certification, and buying software does not produce the report. This page is a readiness checklist for a small team: what to scope, who owns the evidence, and how Type I differs from Type II.

What the report is

A SOC 2 report uses the Trust Services Criteria published by the American Institute of Certified Public Accountants. Security is the category almost every report includes. Availability, processing integrity, confidentiality, and privacy are included only when you and the auditor put them in scope.

The auditor is independent of your team. You prepare a description of the system, operate the controls, and keep evidence. The auditor tests that description and writes the opinion. Calling the outcome "SOC 2 certified" describes the wrong thing. Say that you received a SOC 2 report, and name the type and the period or the date.

GRCompliance can store the policies, the risk register, and the evidence. It does not perform the examination and it does not issue the report.

Agree the scope before you collect files

Write down the system the report will describe: the product or service, the teams who operate it, the main suppliers, and the criteria in scope. A file collected outside that boundary will not help the reader of the report, and a control with no named system is hard to test.

• Name the services and environments the description covers, and the ones it leaves out.
• Name a person who owns the system description and can explain a change to it.
• List the criteria. Do not add privacy or availability because a template included them.
• Ask the customer who requested the report which type they need, and for which date or period.

Type I and Type II are different reports

A Type I report looks at whether the controls are suitably designed at a point in time. A Type II report looks at whether those controls operated effectively over a period. Teams often agree a period of several months for Type II. The length is part of the engagement, not a number this page can set for you.

You do not have to complete a Type I report before a Type II report. Some teams go straight to Type II because a customer asked for operating effectiveness. Some teams use Type I when the reader only needs a point-in-time opinion. Pick the report the reader asked for. Do not treat one type as a required first step, and do not promise a date until the auditor has agreed the period and the sample.

Give every evidence item an owner

Auditors look for practices that match the written controls. A shared folder with no owner, no date, and no link to a control is a pile of files. For each item, record the source, the date, the control it supports, and the person who will answer questions about it.

• Access reviews: the reviewer, the decision, the date, and any follow-up. The same pattern is useful for ISO 27001 evidence.
• Change records: what changed, who approved it, and where the ticket or commit lives.
• Suppliers: which services are in the system description, and who reviews them.
• Incidents: what happened, who assessed it, and what was kept. Do not invent an example from a real customer.
• Policies: a version, an approver, and a review date. A policy that nobody operates is not evidence of the control.
• Risks: an owner, a treatment, and a review date. See the risk register guide.

Premium includes connectors for some systems, such as GitHub and AWS. Core is where you record evidence yourself. A connector is not a substitute for an owner, and a missing connector is not a failed control. If the product does not collect a source, keep the export next to the control and note who produced it.

A readiness checklist

Use this list to see what is missing. It does not guarantee a report date, a fee, or an opinion.

1. Write the system description and the criteria in scope.
2. Name owners for access, change, suppliers, incidents, policies, and risks.
3. Tie each evidence item to a control, with a date and a location.
4. Mark evidence that is missing, stale, or about a system outside the description.
5. Ask the auditor what they will sample before anyone tells a customer when the report will be ready.
6. Decide Type I or Type II from the question the reader asked, not from a fixed sequence.

Run the program on infrastructure you control

GRCompliance is self-hosted. Core is free and open source. Premium is a self-hosted licence at $1,990 a year. The only public hosted instance is the demo at demo.grcompliance.com. Install Core when you want the data on your own infrastructure. The demo is for looking at the product, not for storing a real examination file.