SOC 1
SOC for Service Organizations: ICFR. Updated: September 30, 2026.
A SOC 1 examination reports on controls at a service organisation that are likely to be relevant to its customers' internal control over financial reporting — ICFR. The customers are called user entities, and the reason the report exists is that their auditors need to rely on your controls in order to audit their financial statements. Without a SOC 1 report, that auditor either tests your controls directly, which nobody wants, or qualifies what they can conclude.
Two things follow immediately, and both are routinely misunderstood. A SOC 1 is an attestation examination and report, not a certification — there is no SOC 1 certificate and nobody is “SOC 1 certified”. And SOC 1 is not primarily a cybersecurity or general information-security assessment. Security controls appear in a SOC 1 only where they support financially relevant processing; everything else about your security posture is outside its scope by design.
SOC 1 vs SOC 2 — Don't Confuse Them
The short orientation:
If the service can affect numbers in a customer's financial statements, SOC 1 may be relevant.
If the customer wants assurance about security and operational controls, SOC 2 is usually the relevant SOC framework.
Treat that as an educational simplification rather than a scoping rule. Real scoping depends on what your customers actually rely on you for, what their auditors say they need, and a conversation with a practitioner. Plenty of organisations end up needing both reports, as two separate engagements.
Type 1 and Type 2
As with SOC 2, these examine different subject matter rather than being a smaller and a larger version of the same thing:
- Type 1 reports on the description of the system and the suitability of the design of the relevant controls as of a specified date.
- Type 2 reports on the same description and design and additionally on the operating effectiveness of those controls throughout a specified period, with the service auditor testing evidence sampled across that period.
For SOC 1 the distinction has a practical consequence beyond the usual one: a user entity's auditor generally needs evidence that controls operated across the financial period they are auditing, so a Type 1 rarely satisfies them on its own.
The period has to line up
This matters more in SOC 1 than anywhere else. The examination period should align with your significant customers' financial year. A report covering January to September is of limited use to an auditor examining a December year end, and the gap then has to be addressed by a bridge letter or by additional procedures at extra cost. Agreeing the period with your major customers before commissioning the examination avoids a great deal of friction.
Where SOC 1 May Be Relevant
The common thread in every case below is the same: processing performed by the service organisation may affect financial information the customer uses in its accounts. The service does not have to be a financial product — it has to touch the numbers.
- Payroll processing — you calculate wages, deductions and tax that land directly in the customer's payroll expense and liabilities.
- Payment processing — you capture, settle and reconcile transactions that become the customer's revenue and cash.
- Financial transaction processing — trade capture, settlement, reconciliation, anything where a processing error becomes a misstatement.
- Billing systems — you determine what is invoiced, so you determine recorded revenue and receivables.
- Accounting platforms — the ledger itself, or systems feeding it, so completeness and accuracy of your processing is completeness and accuracy of their books.
- Loan servicing — interest accrual, payment application and balances that appear in the customer's asset figures.
- Claims processing — you determine amounts paid and reserves held, both of which are material financial estimates.
- SaaS platforms processing financially significant transactions — the growing category, and the one most often missed. A subscription-billing, expense or revenue-recognition platform is a financial processor whether or not it thinks of itself as one.
You will usually discover you need one because a customer's auditor asks, often at year end and with little notice. If your service does not touch anyone's financial reporting, you do not need a SOC 1 and should not buy one.
What Can IT and DevOps Have to Do With SOC 1?
A reasonable first reaction from an engineering team is that this is Finance's problem. It is not, and the reason is that the financial processing runs on systems you operate. General IT controls supporting a financially relevant application are themselves relevant, because if change management is weak then no assurance about the application's calculations survives.
The qualifier matters throughout: these are in scope only where they support systems or processes relevant to ICFR. The same control on a marketing website is not a SOC 1 control.
- Logical access to financial applications — who can reach the system that computes the numbers.
- Privileged database access — who can change financial data directly, bypassing the application's own controls entirely. Usually the highest-risk item on the list.
- Change management — that changes to financially relevant code are requested, reviewed, approved and tested.
- Application deployments — who can release to production, and whether a release can bypass the pipeline. See CI/CD setup.
- Database changes — schema migrations and data fixes, which are changes to the accounting records even when they are performed as maintenance.
- Backup and recovery — that financial data can be recovered complete and accurate — backup and recovery.
- Batch and job processing — scheduled runs that post, settle or reconcile. A job that silently fails to run is a completeness problem, which is why failure handling is examined as closely as success.
- Interface controls — data moving between systems, and the checks that it arrived once, completely and unaltered.
- Infrastructure changes to the environments hosting those systems.
- Production access — standing administrative access to production is scrutinised heavily, because it is how controls get bypassed.
- Segregation of duties — that the person who writes a change is not the only person who approves and deploys it, and that no one individual can both initiate and conceal a financial entry.
Example Evidence
As always, the control existing is not the evidence — the dated record that it operated is. For the IT controls above, a service auditor typically asks for:
| Area | Evidence typically requested |
|---|---|
| Change management | Change ticket, approval, code review, deployment record |
| Access management | User and role listing, privileged access review, access approval |
| Database changes | Approved DB change, migration or patch record, execution evidence |
| Batch processing | Job logs, monitoring, failure handling |
| Backup and recovery | Backup evidence, and recovery test records where relevant to the financial-processing system |
A SOC 1 report does not mean the organisation has been comprehensively assessed for cybersecurity. Its subject matter is controls relevant to financial reporting. A company can hold a clean SOC 1 opinion while a great deal of its security posture — vulnerability management, security monitoring, incident response, the security of systems unrelated to financial processing — sits entirely outside that report's scope and was never examined. If security assurance is what you need from a vendor, ask for a SOC 2, and read its scope too.
Two Things to Check in Someone Else's SOC 1
- Complementary user entity controls. As in SOC 2, the report lists controls it assumes you perform — reviewing reports it sends you, reconciling totals, authorising the data you submit. The service organisation's clean opinion does not cover you if you do not do them.
- How subservice organisations are handled. Where the service organisation relies on others — a hosting provider, for instance — the report either excludes them (the carve-out method, in which case you need their assurance separately) or includes them (the inclusive method). Which one was used changes what the opinion actually covers.
The International Equivalent
SOC 1 is issued under the American attestation standards. The international equivalent, used widely in Europe, is ISAE 3402, and reports are frequently issued under both. If your customers are European, ask your practitioner about a dual-standard report rather than assuming a SOC 1 will be accepted.
Getting One
Engage a licensed practitioner, define the control objectives with them in light of what customers actually rely on, agree the period against your customers' financial years, run it, and have it tested. The process mirrors SOC 2, and the same warning applies: generate the evidence throughout the period rather than assembling it at the end.
References
- AICPA & CIMA — System and Organization Controls (SOC) suite of services, which defines SOC 1, SOC 2 and SOC 3.
Written from an infrastructure perspective. We are not a certification body, an audit firm or a legal adviser, and this is not legal advice. Standards are revised on a cycle — confirm the current edition before you commit.