In a ten person engineering team, SOC 2 Type 1 works best with one sponsor, one program owner, an infrastructure owner, an application owner, someone for people processes, and a named auditor contact. Each owns a block of Trust Services Criteria. Type 1 only shows that controls are designed and in place at one date.
What are you actually building?
A Type 1 report is an auditor's opinion on whether controls are suitably designed at a point in time. It has no opinion on operating effectiveness, which is what a Type 2 adds over a period. So your job is to design sensible controls, put them in place by the report date, and be able to describe them accurately. Security is the required category. Availability or confidentiality are optional extras. Keep the first scope small.
Who should own what?
Titles are made up for a team of ten, so adapt them. One person can wear several hats, but each block needs one name.
Executive sponsor (founder or CTO). Owns governance and the tone: CC1 covers control environment, board oversight and accountability. Approves policies, signs management's assertion, and funds tools. Joins auditor kickoff and close out.
Program owner (a senior engineer or engineering manager). Runs the project plan, keeps the control matrix and evidence folder, chairs a short weekly check, and is the auditor's main contact. Owns CC2 (communication of information) and CC4 (monitoring of controls), and drives risk assessment under CC3.
Infrastructure owner. Cloud accounts, networks, encryption, logging, backups and monitoring. Owns most of CC6 on logical access infrastructure, CC7 on detection and incident response, and A1 on availability if you add it.
Application owner. Source control, code review, CI and CD, testing and release. Owns CC8.1 on change management and the vulnerability handling part of CC7.1. Enforces branch protection and pull request review.
People owner (founder, office manager or HR contractor). Hiring checks, onboarding and offboarding, policy acknowledgment, security training. Supports CC1.4 on attracting and developing competent people and CC6.2 and 6.3 on access provisioning and removal alongside IT.
Vendor owner (often the program owner). Vendor list, risk review and reports collected, linked to CC9.2.
Everyone else. Complete training, acknowledge policies, use approved devices and report incidents.
In what order should the work go?
First, scope and tools: choose categories, system boundary and a compliance platform if you want one. Second, risk assessment and policies, kept short. Third, the technical baseline: single sign on, multi-factor authentication, encryption, logging, backups, branch protection. Fourth, people processes. Fifth, vendor review. Sixth, a readiness check against each criterion, then the auditor fieldwork for the point in time date. The Trust Services Criteria text sets no durations, so plan against your own calendar and ask auditors for theirs.
What evidence will you hand over?
Policies with approval dates, the system description, a control matrix, configuration exports for access and encryption, source control settings, onboarding records, training completion, the vendor list with reviews, a risk assessment and incident response plan. Dates matter, because Type 1 is tied to one date.
What are the usual role traps?
Making one person own everything, which fails when they are on leave. Giving the program owner no authority to chase peers. Skipping the sponsor, so policies are never approved. And assigning controls to people who do not know the control exists.
What to do
- Pick a sponsor and a program owner.
- Assign each criteria block to a named owner.
- Choose categories and a small boundary.
- Write the risk assessment and short policies.
- Set up the technical baseline.
- Run onboarding, training and vendor reviews.
- Do a readiness check and fix gaps.
- Brief the team before auditor fieldwork.
Quick check
Can the CTO also be the program owner?
Yes in a small team, as long as the sponsor role still approves policies and someone independent reviews important changes where possible. Name the person for each role.
Which category is required?
Security, called the common criteria. The others are added if your commitments need them.
How Safeguard helps automate this
For a ten person team, hours spent collecting proof are hours not spent building. 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 by screenshot, and monitoring runs continuously between audits, saving time for other work. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which suits the application owner's change and vulnerability controls. Safeguard's 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. The report comes from your independent auditor. Book a call to see it.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): Type 1 and Type 2 engagement description; criteria CC1 to CC9, A1
Last reviewed: 18 October 2026.
