What a SOC 1 report is for
A SOC 1 report is an attestation on a service organisation's controls that are relevant to its clients' internal control over financial reporting (ICFR). It exists because auditors of your clients need assurance over processes you operate on their behalf — payroll processing, claims administration, loan servicing, payment processing, managed ERP hosting, fund accounting.
The engagement is performed by an independent CPA firm under the attestation standards (SSAE 18 in the United States, or ISAE 3402 internationally, where the report is commonly called an ISAE 3402 report).
SOC 1 versus SOC 2
| Dimension | SOC 1 | SOC 2 |
|---|---|---|
| Subject matter | Controls relevant to clients' financial reporting | Trust Services Criteria: security, availability, processing integrity, confidentiality, privacy |
| Control objectives | Defined by the service organisation, mapped to financial assertions | Prescribed criteria, tailored through points of focus |
| Primary audience | Client management and client financial statement auditors | Clients, prospects, procurement, risk functions |
| Typical trigger | Your service affects client financial statements | Security due diligence in sales and vendor risk |
Many service organisations need both: SOC 1 for the financial audit chain, SOC 2 for security assurance. Where the same controls support both, one evidence set can serve both engagements if scoping is coordinated.
Type 1 versus Type 2
| Type 1 | Type 2 | |
|---|---|---|
| Opinion covers | Fairness of the description and **suitability of control design** | Description, design **and operating effectiveness** |
| Timing | As of a point in time | Over a review period, commonly 6 to 12 months |
| Testing | Design evaluation, inquiry, inspection | Design plus tests of operating effectiveness across the period |
| Usefulness to client auditors | Limited — they cannot rely on operation | High — supports reliance on your controls |
Type 1 is a reasonable first cycle when controls are newly implemented and you need something credible quickly. Client auditors almost always want Type 2, so treat Type 1 as a bridge, not a destination.
Anatomy of a SOC 1 report
- Independent service auditor's report — the opinion, scope and any qualification
- Management's assertion — the service organisation's own statement about the description and controls
- System description — services, infrastructure, software, people, procedures, data, and the boundaries of the system
- Control objectives, controls, tests and results — the auditor's procedures and any exceptions, in a Type 2 report
- Other information — unaudited supplementary content such as roadmap or business continuity context
Control objectives and CUECs
SOC 1 control objectives are written by you, then assessed for suitability. They typically cover transaction completeness and accuracy, authorisation, cut-off and timeliness, data integrity, and the IT general controls underpinning them: access management, change management, and computer operations including job scheduling, monitoring and backup.
Complementary User Entity Controls (CUECs) are controls the report assumes *your clients* perform — reviewing output reports, authorising master data changes, reconciling submitted files. State them explicitly and precisely: vague CUECs create disputes with client auditors, and overreliance on them can undermine your objectives.
Where you depend on sub-service organisations such as a cloud provider, decide between the inclusive method (their controls are in your report) and the carve-out method (excluded, with your monitoring controls described). Carve-out is more common and requires documented vendor monitoring.
Readiness: how to prepare
- Scope the system — services, locations, applications, infrastructure, in-scope period
- Map financial relevance — from client financial statement assertions back to your processes
- Write control objectives and controls — one control per objective is rarely enough; document frequency, owner and evidence
- Gap assessment — test design against objectives, remediate before the observation window opens
- Stabilise IT general controls — access provisioning and revocation, periodic access review, change approval, deployment segregation, job monitoring, backup restoration testing
- Build the evidence pipeline — automated tickets, logs and reports rather than retrospective screenshots
- Run a dry run — sample your own controls over one or two months and fix failures before the audit period
- Select the period and the auditor — align the period end with client audit cycles, and plan bridge letters for gaps between the period end and your clients' year end
Common causes of exceptions
- Access reviews performed late or without evidence of remediation
- Terminations not revoked within the stated timeframe
- Emergency changes lacking retrospective approval
- Job failures resolved without documented follow-up
- Backup restoration never tested during the period
- Controls described at a frequency the organisation does not actually sustain
Key takeaways
- SOC 1 addresses controls relevant to clients' financial reporting; SOC 2 addresses security and related criteria
- Type 2 is what client auditors rely on, because it opines on operating effectiveness over a period
- You define the control objectives — clarity and financial relevance determine report quality
- CUECs and sub-service organisation treatment must be explicit and defensible
- Most exceptions arise in IT general controls, so stabilise those before the observation period begins
Describe only controls you can operate every single time. A narrow report with a clean opinion serves clients far better than a broad description riddled with exceptions.