A small SaaS team needs controls that protect the service it actually runs. Start with your customer commitments. Assign the work. Keep evidence as the work happens. Then check whether the controls are doing their job.
SOC 2 is an examination of those controls within a defined scope. It is not a software purchase or a set of policies to finish once. This guide gives you a practical structure for running the program before, during and after the examination.
1. Decide what the report needs to cover
Write down the product and services customers rely on. Include the people, applications and providers needed to deliver them. Trace where customer data enters the service and where it goes.
- Identify the production service and its important dependencies.
- Include support and administrative tools that can affect that service or its data.
- List the promises you make about security and service delivery.
- Record what customers must configure or do themselves.
- Agree the report boundary and relevant Trust Services categories with your CPA firm.
Security is included in most SOC 2 examinations. The categories examined depend on the agreed scope. An uptime commitment may make availability important. A service that processes customer transactions may need processing integrity. Confidentiality and privacy address different information-handling concerns; do not treat them as interchangeable.
Do not choose SOC 1 simply because a customer calls the request an “SSAE audit.” SOC 1 addresses controls relevant to customers’ financial reporting. A payroll or financial-processing service may need it. SOC 2 addresses the applicable Trust Services Criteria. Some services need both reports, with different objectives.
2. Give the program an owner
One person should coordinate the program. That does not mean they perform every control. Engineering should own engineering work. The person responsible for hiring should start the joiner and leaver process. Management must make decisions about unresolved risks.
- Program lead: Maintains the scope and control list. Follows up on gaps.
- Control owners: Perform the work and retain its evidence.
- Reviewers: Challenge results and confirm that problems were resolved.
- Management: Sets priorities and provides resources. Approves risk decisions.
Small teams can combine roles. Where one person could approve their own sensitive work, decide what separate oversight is practical. An owner’s documented review may help in some situations. It does not automatically replace every preventive check.
3. Cover the whole service, not just the audit portal
Use the areas below to organize your program. The examples are starting points, not a universal list of sufficient controls. Select the controls and timing that address your service’s risks and commitments.
People, policies and risk decisions
Do: Define responsibilities and teach people how to handle customer information. Assess realistic ways the service could fail its commitments. Keep policies aligned with actual work. Revisit the assessment when the product or operating model changes.
Owner: Program lead with management and the relevant team leads.
Evidence: Approved policies, training records and risk decisions with follow-up owners.
A growing risk register is not the goal. Show which problems you will fix, how you will address them and who accepted any remaining exposure.
Accounts, devices and customer separation
Do: Approve access based on the job. Protect privileged sign-ins. Remove access when it is no longer needed. Manage credentials used by applications as well as people. Protect work devices that can reach production or customer data.
Owner: Engineering or IT, with managers approving business access.
Evidence: Access requests, removal records and review results that show corrections. Retain relevant device and authentication settings.
For a shared SaaS platform, check that one customer cannot reach another customer’s information through the application or its interfaces. A cloud provider’s security report does not demonstrate that your application enforces that boundary.
Software changes and security weaknesses
Do: Review and test changes before release. Limit who can deploy. Define how urgent fixes are handled. Find relevant vulnerabilities and track them through correction or a documented decision.
Owner: Engineering lead.
Evidence: Change records linked to review, test and deployment results. Keep vulnerability findings and the evidence that important fixes worked.
Match testing to the application. A dependency scan does not replace checks for broken authorization or business logic. Set response targets based on risk and commitments rather than copying a deadline the team cannot meet.
Monitoring and incident response
Do: Identify the events that could signal a problem. Decide who investigates them and when. Define how to contain an incident and communicate with affected parties. Exercise the response process.
Owner: Service operations or the engineering lead.
Evidence: Alert investigations, incident records and exercise findings with assigned corrections.
Collecting logs is not the same as monitoring them. An after-hours alert needs a route to someone who can act if that is what your service requires.
Recovery and service capacity
Do: Identify what must recover and the time and data-loss limits that matter. Protect the necessary backups. Test recovery of a usable service. Watch capacity and dependency failures that could prevent delivery.
Owner: Service owner with engineering.
Evidence: Backup results, recovery test outcomes and unresolved limitations. Keep records of significant capacity decisions.
A running database is not enough if customers cannot sign in or complete the intended task. Include dependent services in the recovery plan. Expand these controls to match availability commitments when that category is in scope.
Customer data throughout its life
Do: Know what information you hold and where. Limit its use and movement. Protect it during storage and transfer. Apply retention and disposal rules that match your commitments and obligations.
Owner: Product or data owner, supported by engineering and qualified privacy advice where needed.
Evidence: Data-flow records, approved settings and retention or deletion results.
Consider support exports and test environments, not just the production database. If privacy is in scope, address the applicable notices, choices and rights processes too. A generic security policy will not cover all of that work.
Cloud providers and other suppliers
Do: Identify the providers that matter to the service. Review their scope and responsibilities. Assess relevant reports and unresolved issues. Assign the controls your team must perform.
Owner: Service owner or program lead.
Evidence: Supplier reviews, responsibility decisions and follow-up on gaps.
Using managed infrastructure can reduce the systems you operate. It does not remove your duties over application behavior or customer data. For example, AWS explains that responsibilities vary by service. A team running virtual servers has different operating tasks from one using an abstracted managed service.
Processing results, when relevant
Do: Define what correct processing means. Validate inputs and reconcile results. Handle rejected records and retries without silently losing or duplicating work. Deliver output to the intended parties.
Owner: Product or operations lead.
Evidence: Processing checks and records of exceptions through resolution.
For a billing service, this might include checking a customer batch against the invoices produced. The exact checks depend on the service. Processing integrity must be included in the report scope before you claim the report covers that category.
4. Keep a small control list that people can use
For each control, record the objective, owner and actual procedure. Add its timing or trigger, evidence location and reviewer. Include the action to take when it fails.
For example: “Engineering reviews production changes before deployment. The change record links the approval and test results. Urgent changes follow the emergency process and receive the required follow-up review.” Adapt that description to what your system really does.
A ticketing system and a protected evidence folder can be enough to start. Automation helps when it reduces recurring work. It does not decide whether an approval was meaningful or whether an exception is acceptable.
5. Build the work into the normal operating rhythm
- At the event: Capture evidence when someone joins, leaves, deploys a change or handles an incident.
- On the agreed schedule: Perform access reviews, supplier reviews and recovery exercises at the frequencies your program defines.
- When things change: Reassess a new data use, major feature, provider change or customer commitment.
- At management review: Examine overdue work and control failures. Decide what needs resources or a different approach.
As a practical starting point, a small team can use a short monthly program check to review open issues. That is a management suggestion, not a universal SOC 2 frequency. Individual controls may need to run continuously, per event or on another schedule.
6. Prepare for the examination without inventing a second operation
Agree the report type and timing with the CPA firm. Type 1 addresses design at a specified date. Type 2 also examines operating effectiveness over a period. Do not reconstruct approvals as though they happened earlier.
Describe the service accurately. Keep evidence tied to the relevant systems and period. When a control failed, preserve the facts and the corrective action. A clean-looking checklist is less useful than an honest record the reviewer can follow.
Keep operating after the report is issued. New staff and product changes can alter the controls. Track the next reporting period and keep customer-facing claims aligned with what the report actually covers.
Sources and next steps
This guide draws on the AICPA Trust Services Criteria and SOC reporting guidance. See AICPA’s SOC 1 explanation for the financial-reporting distinction. Proposed 2027 criteria are not treated here as final requirements.
For concrete examples, see four SaaS controls and their evidence. Use those examples inside the wider program, not as a substitute for it.
For buyer considerations and report selection, see our SaaS reporting overview.
Need help defining the scope or turning existing work into a workable program? Discuss your SaaS SOC reporting needs.