The lean path to SOC 2 Type 2 is a narrow scope, a short set of policies that match what you actually do, and controls that run the same way every week of the observation period. Start with the Security category alone, keep in scope systems few, and do not promise anything in policy that you cannot evidence.
What does lean mean here, and what does it not?
Lean does not mean skipping criteria. The AICPA criteria apply to whatever you put in scope, and a Type 2 report covers a period and includes tests of operating effectiveness. Lean means choosing a boundary you can defend and operate, then doing less, better.
It also does not mean copying a stranger's policy pack. An auditor tests your controls against your own written descriptions. Policies you cannot follow create exceptions out of thin air.
How do you pick the scope?
The criteria define five categories: security, availability, processing integrity, confidentiality and privacy. Security, delivered through the common criteria (CC series), is the baseline. Add the others only when customers ask or your service promises require them. Each extra category adds criteria, controls and evidence.
Then fix the system boundary. List the product, the infrastructure it runs on, the code repositories, the identity provider, the ticketing and deployment tools and the people with access to production. Leave out the marketing site, the internal wiki with no customer data, and the sandbox with synthetic data, and write down why.
Fewer systems in scope means fewer access reviews, fewer evidence streams and fewer places for drift.
Which controls matter most for a small team?
Concentrate on areas where small companies most often get exceptions.
Access. Single sign on or at least central identity, multi factor authentication everywhere, named accounts, prompt removal when someone leaves, and a quarterly access review of production and source control. This maps to the logical access criteria (CC6 series).
Change management. Protected branches, a second reviewer, automated tests and a deployment record (CC8.1). Cheap to set up in a git platform, and easy to evidence.
Risk and vendors. A short risk assessment, refreshed yearly, and a vendor list with a review for each critical supplier (CC3 and CC9.2).
Monitoring and incidents. Logging, alerts, a vulnerability scan routine and a written incident process that you rehearse once (CC7 series).
People. Background checks where lawful, signed policy acknowledgements, security training at onboarding and annually.
Governance. An owner for the programme, a board or founder review of security at least yearly, and meeting notes (CC1 to CC5).
What order works best?
Many startups do a Type 1 first because it describes the design of controls at a point in time and gives customers something sooner. It carries no opinion on operating effectiveness, so it is a stepping stone, not the destination. Other teams go straight to a Type 2 with a short first period. Ask your auditor what period they will accept for a first report, and what customers will accept, before you decide.
Whichever you pick, start the clock on evidence as early as you can. For Type 2 the observation period is the thing you cannot compress after the fact.
What mistakes sink lean programmes?
- Policy packs with commitments nobody follows, such as monthly reviews that never happen.
- Letting scope grow because a new tool was added without a decision.
- Starting the observation period before controls actually run.
- Manual evidence collected from memory at the end of the period.
- No named owner, so everyone assumes someone else is checking.
- Exceptions treated as shameful and hidden. Auditors expect some; they look at your response.
What to do
- Choose Security as the first category and write the system boundary on one page.
- Pick an auditor early and ask about period length and sampling.
- Write short policies that match your practice and no more.
- Turn on multi factor authentication, protected branches and central logging before the period starts.
- Create a recurring calendar with an owner and an evidence note for each task.
- Keep evidence as you go, in a single structure by criterion.
- Review exceptions monthly and record the cause and fix.
- Rehearse one incident scenario and keep the notes.
Quick check
Do we need all five trust services categories?
No. Security is the baseline. Availability, processing integrity, confidentiality and privacy are added when your commitments or customers call for them, and each one adds criteria and evidence.
Is a Type 1 report enough?
A Type 1 report describes the design of controls at a point in time and gives no opinion on operating effectiveness. Many customers ask for Type 2 because it tests operation across a period.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): categories, CC8.1, CC9.2 and report type definitions.
How Safeguard helps automate this
A lean team has no spare hours for evidence chasing. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of screenshots, and monitoring runs between audits, which saves time for the work that moves the company forward. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. The remediation agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Safeguard helps you prepare and keep evidence ready; it does not certify you or replace your auditor. Book a call.
Last reviewed: 18 October 2026.
