Let’s say your founder, call him Dave, runs a fintech platform that just cleared security review on a $400K enterprise deal. Procurement sends one last request: “Please provide your most recent SOC report.” Easy. Dave sends the SOC 2 Type II his team spent eight months getting. Three days later, the reply lands: “Our external auditors need your SOC 1.” Dave rereads it twice. There are two?
There are! They answer different questions for different readers, and by the end of this post you’ll know which one your company needs… or whether, like a lot of fintech platforms, you may need to consider both.
TIL;DR: SOC 1 covers controls that affect your clients’ financial reporting; SOC 2 covers/answers how you protect the systems and key data behind your service.
What Is a SOC 1 Report?
A SOC 1 is an independent CPA examination of your controls that are relevant to your customers’ internal control over financial reporting (ICFR). It applies when your business performs a task whose output lands in your client’s financial statements. Running payroll, servicing loans, administering claims, calculating or processing the value of something your client owns. Does your SaaS product produce numbers your client’s auditor can rely on at year-end?
Say your platform processes accounts payable for clients. Every invoice you receive, approve, and pay rolls up into the AP balance on your client’s balance sheet. When their auditor tests that balance, the question is whether it’s accurate and complete: did every valid invoice get recorded, only valid invoices, right amount, right period? Your client can’t answer that alone. The processing happens inside your systems, so their auditor needs assurance over your controls. Things may be fully automated or there could be reconciliation processes that are manual or semi-automated. These processes and procedures would make up controls that an independent auditor would verify in a SOC 1 Report. Essentially, if your output feeds their books, your business processes may be in scope from a SOC 1 perspective.
The structural difference from SOC 2: a SOC 1 is built around control objectives, and you define them. There’s no standard checklist. You state what your processing is supposed to achieve (“invoices are processed completely and accurately,” “payroll calculations reflect authorized rates and hours”), and the auditor tests whether your controls achieve it. Loosely defined by you, then held against you. The engagement runs under AT-C section 320 of the AICPA attestation standards (SSAE 18), which exists specifically for this kind of reporting.
Practical tip before you sign anything: diagram your business processes now. Your auditor will walk through them with you, input to output… where the invoice enters, who approves it, what the system calculates, where the number lands. If nobody can draw the process, nobody can test it, and you’ll burn fieldwork hours reconstructing your own workflow on a whiteboard.
The report covers more than the processing steps. A SOC 1 looks at your control environment through the COSO internal control framework, five areas:
- Control environment: management’s tone and accountability around controls
- Risk assessment: how you identify what could go wrong with the numbers
- Control activities: the daily approvals, reconciliations, and system checks
- Information and communication: whether the right information reaches the right people in time
- Monitoring: how you catch and fix control failures
Your ITGCs or IT General Controls – (access, change management, operations) are still underneath all of it. Our SOC 1 reporting page covers scoping and timelines.
What Is a SOC 2 Report?
A SOC 2 checks the locks, the badge readers, the alarm system, and who has keys.
A SOC 2 examines how you protect the system itself: Security, and optionally Availability, Processing Integrity, Confidentiality, and Privacy. The criteria come from the AICPA Trust Services Criteria rather than management’s own objectives, anchored by the common criteria (CC series) every report carries. That’s why SOC 2 reports look similar across companies and SOC 1 reports don’t.
I’ve written a full guide on what a SOC 2 report is and a breakdown of the five Trust Services Categories, so I’ll skip to the part that decides the question.
The Real Difference: Who Reads It and Why
When I wrote about SOC 3 reports, the punchline was “it’s all about who gets to read it.”
A SOC 1 is read by your clients’ financial statement auditors during their year-end audit. They pull your report to decide whether they can rely on your processing instead of testing around it. A SOC 2 is read by TPRM and security teams during vendor due diligence, usually before the contract is signed.
| SOC 1 | SOC 2 | |
|---|---|---|
| Purpose | Assurance over controls affecting clients’ financial reporting (ICFR) | Assurance over protection of systems and data |
| Criteria | Control objectives defined by management | AICPA Trust Services Criteria |
| Audience | Client management and their financial statement auditors | Client security, TPRM, and compliance teams |
| Typical requester | Controller, audit committee, external audit firm | Procurement security review, CISO, vendor risk analyst |
| What’s inside | System description, control objectives, controls, test results | System description, TSC mapping, controls, test results |
| Standard | AT-C 320 (SSAE 18) | AT-C 105 and 205 (SSAE 18) |
Dave’s prospect wasn’t being difficult. Their security team already had what it needed. Their auditors did not.
Do Type I and Type II Work the Same Way for Both?
Yes. The Type distinction is independent of the SOC number. A Type I is a design snapshot as of a date. A Type II tests operating effectiveness over a period, typically 3 to 12 months. “SOC 1 Type 2” means controls relevant to financial reporting, tested over a period.
I’ve covered Type I vs Type II in depth. Short version: past your first report, everyone asks for the Type II.
Which One Do You Need?
Before anything else, ask one question: is the request coming from your client’s security team or from their auditors? The concern or risk they are looking for and the audience may help you decide. And if the answer still is not obvious, our “Do I need SOC 2?” assessment sorts it out in about two minutes.
It depends on what your service touches:
- Payroll processors, loan servicers, claims administrators, fund administrators: SOC 1. Your client’s auditor pulls payroll registers and loan trial balances your system produced.
- SaaS platforms, hosting providers, data processors: SOC 2. Nobody’s balance sheet depends on your numbers, but their data lives in your system.
- Fintech platforms that hold, move, or calculate client money: often both. AWS publishes SOC 1, SOC 2, and SOC 3 reports for this exact reason. Their auditors read one, their security teams read the other.
This happened to me. Earlier in my career doing internal GRC work, our service produced fair market valuations of mortgage assets. A model built on prepayment behavior, default risk, borrower credit, geography, and where rates were heading. I knew a SOC 1 would be needed eventually, but we did the SOC 2 first because that’s what the loudest requests were asking for. Within six months of holding the Type II, publicly traded clients pushed back. Their audit firms wanted independent assurance over the valuation process itself, not a report about our access controls.
A SOC 2 in hand doesn’t pause the SOC 1 clock. If a publicly traded client relies on a number you produce, their auditors will come asking on their timeline.
If you need both, the same CPA firm can run coordinated engagements. The ITGC work sometimes overlaps heavily, sometimes differs, but testing can run concurrently and the efficiencies are real.
A Quick Aside: Neither One Is a “Certification”
There is no SOC certification. No certificate, no pass/fail stamp, and a platform-generated badge is not an attestation. Both AICPA SOC Reporting frameworks are designed to be CPA attestation reports containing an independent auditor’s opinion. Anyone selling you a “SOC certification” hasn’t read the standard.
Where Sage Audits Fits
We’re a boutique Colorado CPA firm doing independent SOC 1 and SOC 2 attestation audit work for SaaS and fintech companies. We do actual walkthroughs with your control owners. We will work with your environment and preferred evidence collection tool or even if manually done. We phase testing across your period instead of showing up at month twelve with a 90-item evidence request. We answer questions year-round, and if you’re in Colorado we’ll meet you in person. Fixed fee, partner on every engagement.
If you’re staring at a request (like Dave’s) and aren’t sure which report it’s asking for, (we will all have a laugh if they want a “SAS70”) send us the request. We’ll tell you which one it likely is.
