SOC 2 for saas
A customer asks for your SOC 2 report. Then another does. What was sitting on the compliance roadmap is now standing between you and a signed contract.
For a Canadian software company selling into the US, Type 2 is the report enterprise buyers ask for, and increasingly the only one they will accept. Type 1 can still help as interim assurance while your Type 2 is underway. The real decision is which path to Type 2 fits your company, and that comes down to three questions:
Working through those starts with understanding what a SOC 2 report is and what each type tells your buyer.
Once your product sits inside a customer’s technology or data supply chain, their security team needs a way to evaluate the risk of using it. Without an independent report, that review runs on security questionnaires, policy requests, architecture diagrams, penetration-test results and follow-up meetings, and each round adds time to the sales cycle.
A SOC 2 report gives the buyer a standardized, independent document their team already knows how to review. For enterprise buyers in the US and Canada, SOC 2 has become a baseline requirement for vendors that handle their data, and when they ask for your report, they almost always mean a Type 2.
SOC 2 (System and Organization Controls 2) is an American Institute of Certified Public Accountants (AICPA) framework for evaluating how well a service organization, typically a SaaS or cloud company, protects customer data. An independent CPA firm examines your controls against the Trust Services Criteria and issues a report with its opinion. No law requires SOC 2, but enterprise buyers often make it a contractual requirement.
There is no SOC 2 certification and no pass/fail grade. The report covers a defined scope and date or period. Your customers’ security teams will review the scope, opinion, and any exceptions before deciding if they can trust you with their data. This is different from glancing at a badge on your website.
The AICPA Trust Services Criteria are organized into five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is the only category required in every SOC 2, with others added only when an SLA, a contract, or a customer makes those commitments explicit.
The criteria are flexible rather than prescriptive, and that can trip up first-time teams. There is no official AICPA list of SOC 2 controls, so each company designs its own to fit its system and risks. Without a set list to follow, many reach for a generic template and end up committing to controls that don’t match how they work. Every control you commit to is one the auditor will test.
Both report types can cover the same system and the same Trust Services Criteria. The difference is what the auditor tests, and over how long.
A Type 1 says your controls were effectively designed and in place as of a date. It doesn’t test whether they operated over time.
What is an ‘effectively designed’ control? The control reduces the risk it targets, fits the relevant criteria, and is documented clearly enough to be performed consistently and tested. It is “in place,” or implemented, when your systems and processes actually carry it out.
For example: on October 31, did branch protection require an approved pull request before code could reach production?
A Type 2 tests the same design as a Type 1, plus whether each control actually ran as described throughout a reporting period.
For example: From January 15 to July 15, did every production change go through the required review and approval process?
To answer that, the auditor may select a sample of change logs from across the period and check each one. A missed step in any month can show up as an exception in the report.
That track record helps buyers move through procurement and vendor-risk reviews with more confidence.
What it tells buyers
Type 1
“This company’s controls were in place and operating effectively on October 31.”
Type 2
“This company’s controls were not only designed well but actually operated effectively over a 6-month period.”
| Area | Type 1 shows (on one date) | Type 2 adds (across the period) |
|---|---|---|
| Access management | Access to cloud systems, code, production and customer data is defined and restricted | Access was granted, changed, reviewed and removed as the control requires |
| Change management | Code and infrastructure changes require review, testing and approval before deployment | Sampled changes followed that process, with pull requests, approvals and deployment records to show it |
| Cloud configuration | MFA, encryption, logging and network restrictions are configured and enforced | Those settings stayed in place, and deviations were detected and fixed |
| Vulnerability management | A process exists to identify, assess and remediate vulnerabilities | Vulnerabilities were found, prioritized, tracked and remediated within the timelines the process sets |
| Incident response | Roles, escalation paths and response procedures are defined | Security events were monitored, investigated, escalated and documented as those procedures require |
That track record takes months to build, so timing shapes every decision that follows.
Think of it as two clocks: one you can’t speed up, and one you can.
A Type 2 needs your controls to run for a set reporting period so the auditor can see they worked over time. First reports often cover 3 to 6 months, and later reports usually cover 12. A shorter period only helps if the buyer will accept it. Once the period starts, no amount of effort shortens it, though the work doesn’t stop. Controls keep running and any remaining gaps get closed.
Before the reporting period starts, your controls need to be in place and working the way your company actually operates. How long that takes depends on your starting point and how much focus you give it. A few ways to shorten it:
Your earliest Type 2 = readiness + reporting period + time for testing and issuing the report
Look at how many prospects are asking, how large those deals are and which industries they’re in. Buyers in regulated sectors such as financial services and healthcare are less likely to accept anything short of a Type 2 in the interim.
Your first Type 2 report needs months. If that won’t fit the buyer’s timeline, the question becomes what they’ll accept while your Type 2 is underway.
Some teams are building controls from scratch. Others already have most of them running and only need to close a few gaps. Where you fall determines how long readiness takes, and how soon either report can reach the buyer.
Once you know what your buyers require and what your timeline allows, there are two practical paths.
Prepare → begin Type 2 reporting period → Type 2 examination → Type 2 report
You get your controls ready, run them through the reporting period, and the auditor tests them and issues the Type 2. This is the best path when buyers will wait for the Type 2 or accept other interim evidence.
Watch for
If access reviews are inconsistent or offboarding is unreliable, the period won’t fix the issues. It will record them as exceptions.
Prepare → Type 1 as of the start of the reporting period → Type 1 report issued while the period runs → Type 2 examination → Type 2 report
Your buyer receives independent assurance while your Type 2 track record builds. It’s worth doing when a buyer accepts a Type 1 in the meantime and having one keeps a deal moving.
Watch for
Easing off once the Type 1 is issued. Your reporting period is still running, so a missed access review or an unapproved change in month four can still show up as an exception in your Type 2.
1. Will the buyer accept a Type 1 while your Type 2 is underway?
2. Would having a Type 1 keep a deal moving before your Type 2 is ready?
3. Are your controls ready for the reporting period?
What matters is that your controls work the same way every time. Before the reporting period starts, you should be able to say yes to three things.
For a cloud-native team, most controls should live in the tools you already use: branch protection, required pull-request approvals and CI/CD checks for change management, and SSO, MFA and role-based access for identity. In AWS, services such as IAM Identity Center, CloudTrail and AWS Config already enforce or record much of what an auditor will ask about. On platforms such as Vercel or Heroku, more of the infrastructure sits with the provider, so your controls focus on access, code changes and configuration.
Where you can, let the system enforce the control. A branch protection rule runs on every merge. A manual checklist runs when someone remembers it.
Access reviews happen, changes get approved, vulnerabilities get fixed, and vendors get reviewed at the cadence you committed to.
If the auditor picks something from four months ago, can you prove it happened? Most of that evidence should already sit in your identity provider, cloud logs, pull requests, tickets and monitoring tools.
Set the policies aside and pull up real events. Show what happened the last time:
For each one, can you show who did it, who approved it, when it happened, and what record proves it?
Keeping a focused security package on hand, ready to share under NDA, means you can respond quickly each time a prospect asks. The package might include:
| Document | How it helps |
|---|---|
| Reporting period and timeline | Dated milestones toward the Type 2 |
| Auditor engagement confirmation, if engaged | Proof that an independent CPA firm is involved |
| Type 1 report, if running in parallel | Independent assurance as of a specific date |
| Readiness or gap assessment summary | An outside view of where your controls stand |
| Penetration-test summary | Independent technical evidence, ideally with remediation status |
| Completed security questionnaire | Direct answers to the buyer's own requirements |
| Architecture and data-flow overview | Where customer data lives and moves |
| Subprocessor list | Your third-party dependencies, such as your cloud provider |
| Security policy summaries | Evidence that core security expectations are defined |
If the buyer needs the report before signing and yours won’t arrive in time, ask whether they’d commit under conditions. These conditions might include:
Then deliver.
Your first Type 2 is the start of a yearly cycle. Customers will usually ask for a current report each year, so your controls keep running and your team keeps collecting evidence after the first period ends. Each new reporting period typically starts the day the last one ended, so your coverage has no gaps.
Between the end of one period and the issue of the next report, some buyers will ask for a bridge letter. This is a short statement from your company confirming nothing significant has changed in your controls since the period ended.
Your buyers want a Type 2, so every decision should get you there as soon as possible. If a Type 1 keeps a deal moving while your track record builds, run it in parallel with your Type 2 reporting period. If it wouldn’t, go direct.
Either way, the reporting period itself can’t be rushed, so the time you can save comes before it starts. Get your controls running the way your company operates and producing evidence. Keep a security package ready so sales can keep prospects engaged in the meantime.
Yes. A Type 1 report is not a prerequisite for Type 2. You still need your controls designed, implemented, and operating, with evidence being captured, before the Type 2 reporting period begins.
Some will and some will not. What matters is whether the buyer driving the requirement will treat a Type 1 as meaningful interim assurance, and whether receiving it changes the procurement decision.
Think in two parts: readiness and operating history. Readiness depends on your starting point, scope and existing controls. The Type 2 then covers a defined reporting period, followed by testing and report issuance.
No. Security is required in every SOC 2 report. The other criteria are added based on the service being examined, the relevant risks and commitments, and what your customers require.
No. AWS’s report covers the controls AWS operates. Your SOC 2 covers the controls you operate: who has access, how changes reach production, how your environment is configured and monitored. Your auditor may consider AWS’s report as part of your examination, but it does not replace your own.
Type 2 becomes the primary report you share, because it provides assurance over operating effectiveness across a period. That is why a Type 1 should only be part of the first journey when the interim report itself has a job to do.
Next step
Tell us what the buyer asked for and when they need it, and we will tell you plainly which path fits.