SOC 1 Guide: Type 1 vs Type 2, CUECs and ITGCs

When a payroll processor, fund administrator, claims platform or cloud ERP host processes your transactions, its controls become part of your financial reporting, and your auditor will ask how you know they work. A SOC 1 report is the standard answer: an independent CPA's examination of the controls at a service organisation that are likely to be relevant to its customers' internal control over financial reporting (ICFR). This guide explains what a SOC 1 report covers, how Type 1 and Type 2 differ, how to read one properly as a customer, and how to prepare for one as a service provider. It is written for security, IT audit and GRC practitioners, and for finance and technology leaders who sign off on outsourcing risk.

Key takeaways

SOC 1 is about financial reporting, not security in general. Its scope is the controls at a service organisation that matter to customers' ICFR, and its intended readers are those customers and their financial statement auditors.
Type 2 is the report that carries evidence. A Type 1 opinion covers design and implementation at a single date; only a Type 2 tests whether controls operated effectively over a period, usually 6 to 12 months.
The report is only half of the control. Complementary user entity controls (CUECs) listed in the report are your responsibility, and the service auditor's opinion assumes you perform them.
IT general controls decide most outcomes. Logical access, change management and computer operations objectives underpin the application controls, and service accounts, batch job identities and API keys sit inside those objectives.
Reading the report is a control in its own right. Check the period, scope, carved-out subservice organisations, exceptions and management responses, then cover the gap to your year end with a bridge letter and your own procedures.

What a SOC 1 report is, and what it is not

The AICPA describes SOC 1 as an examination of controls at a service organisation that are likely to be relevant to user entities' internal control over financial reporting, intended to help user entities and their auditors (user auditors) evaluate the effect of those controls on the user entities' financial statements. The engagement is performed by a CPA firm under the AICPA attestation standards in SSAE No. 18, specifically AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting, together with the AICPA SOC 1 Guide. SOC 1 replaced the older SAS 70 report. Outside the United States, the equivalent international standard is ISAE 3402, and many large providers issue one report that satisfies both.

Why it matters: in the United States, management of an SEC registrant must evaluate the effectiveness of ICFR as of each fiscal year end using a suitable, recognised control framework (17 CFR 240.13a-15(c)). The rule defines ICFR as a process giving reasonable assurance about the reliability of financial reporting, including policies and procedures for accurate records, properly authorised receipts and expenditures, and prevention or timely detection of unauthorised use or disposition of assets. If a provider runs part of that process, its controls are in scope for you.

Report	Subject matter	Criteria or objectives	Typical audience and distribution
SOC 1	Controls relevant to user entities' ICFR	Control objectives defined by the service organisation (for example "logical access to the payroll application is restricted to authorised personnel")	User entities' management and their financial statement auditors; restricted use
SOC 2	Controls relevant to security, availability, processing integrity, confidentiality or privacy	AICPA 2017 Trust Services Criteria (with revised points of focus, 2022)	Customers and others with a business need, usually under NDA
SOC 3	Same subject matter as SOC 2	Trust Services Criteria, without detailed tests	General use; often published openly

A common mistake is to ask a provider for a SOC 1 when the concern is data protection, or to accept a SOC 2 when your auditor needs ICFR assurance. If the service touches transactions, balances or financial data that flow into your ledger, ask for SOC 1. If the concern is confidentiality or availability of customer data, ask for SOC 2. Many providers that matter to both finance and security issue both. See the SOC 2 Guide.

Type 1 versus Type 2

The distinction is about evidence. PCAOB AS 2601, the standard US public company auditors follow when a client uses a service organisation, is explicit that a report on controls placed in operation is not intended to provide any evidence of operating effectiveness. Only a report that includes tests of operating effectiveness can support a user auditor in assessing control risk below the maximum.

Feature	Type 1	Type 2
Opinion covers	Fair presentation of the system description and suitability of design, as of a specified date	Fair presentation, suitability of design and operating effectiveness throughout a specified period
Tests of controls and results	Not included	Included, with exceptions listed
Usefulness to a user auditor	Understanding controls for planning	Evidence to rely on controls and reduce substantive testing
Period	A single date	Commonly 12 months; AS 2601 says a useful operating effectiveness report should ordinarily cover at least six months
When used	First-year reports, new services, a newly designed control set	Steady state; what customers and auditors expect each year

Large providers show how this works in practice. Microsoft runs its SOC 1 Type 2 on a rolling 12-month window with no gaps between periods, and commissions a mid-year Type 1 for services added since the last Type 2. AWS issues SOC 1 reports quarterly, each covering 12 months, generally about 9 to 10 weeks after the period ends. A first-time service organisation typically issues a Type 1 to give customers something early, then moves to a Type 2 as soon as it has enough operating history.

Anatomy of a SOC 1 report

Independent service auditor's report: the opinion. Look for the words "qualified" or "adverse", and for scope limitations. An unqualified opinion can still contain exceptions in testing.
Management's assertion: the service organisation's written statement that the description is fairly presented and that controls were suitably designed (and, for Type 2, operated effectively).
Description of the system: services in scope, locations, applications and infrastructure, the control objectives and the controls that achieve them, subservice organisations and how they are treated, and the complementary user entity controls.
Control objectives, tests and results (Type 2): each control, the test performed (inquiry, observation, inspection, reperformance), the sample, and the result, including "exceptions noted".
Other information: often management's responses to exceptions. This section is not covered by the opinion. Microsoft, for example, tells readers to search for "Management Response" for exceptions and for "User Entity Responsibilities" at the end of its reports.

Control objectives and IT general controls, including non-human identities

Unlike SOC 2, SOC 1 has no fixed list of criteria: the service organisation writes its own control objectives, scoped to the transaction flows customers rely on. In practice reports contain two families. Business process objectives cover transactions (for example, "payroll changes are authorised, complete and accurately processed"). IT general control (ITGC) objectives cover the environment that the application controls depend on. If ITGCs fail, the auditor cannot rely on automated controls, reports and interfaces. See the SOX ITGC Guide.

Typical ITGC objective	Example controls tested	Non-human identity angle
Logical access to in-scope applications, databases and operating systems is restricted to authorised users	Joiner approval, timely leaver removal, periodic access review, privileged access restricted, password or MFA settings	Service accounts, batch job and integration identities, database accounts used by the application, API keys and certificates must be inventoried, owned and reviewed, not just human users
Changes to applications and infrastructure are authorised, tested and approved before implementation	Change tickets, testing evidence, approvals, segregation between developers and deployers	CI/CD pipeline identities that deploy to production are effectively the "deployer"; their permissions and secrets are part of the segregation story
Computer operations: scheduled jobs and interfaces run completely and accurately; failures are resolved	Job scheduling changes approved, failure monitoring and resolution, interface reconciliations	Scheduler and interface credentials; file transfer keys between the provider and customers
Data backup and recovery supports processing	Backup configuration, monitoring, restore testing	Backup service accounts often hold broad read access and are rarely reviewed

Service auditors increasingly ask for population completeness on access reviews. A user access review that lists only named staff, while the production database is reached daily by a generic account whose password is in a shared script, is the textbook source of an exception. Treat each non-human account as an in-scope identity with an owner, a purpose and a rotation record. See the Service Account Security Guide and the Segregation of Duties Guide.

Complementary user entity controls and subservice organisations

CUECs: controls the service organisation assumes its customers perform for the control objectives to be achieved. AS 2601 notes that where user controls are necessary, the report's opinion is worded so that objectives are achieved only if user organisations applied the controls contemplated in the design. Typical CUECs: you review who in your organisation has access to the provider's portal; you approve and reconcile input files; you review output reports; you notify the provider promptly when your users leave; you protect the credentials and API keys you use to connect.
Mapping CUECs is your work: list every CUEC, name the owner in your organisation, identify the control in your own environment that meets it, and keep evidence. Your external auditor will ask.
Subservice organisations: providers often rely on their own providers, such as a data centre or cloud platform. Under the carve-out method, the subservice organisation's controls are excluded from the report and you need that party's own report; under the inclusive method they are included in the description and testing. Complementary subservice organisation controls (CSOCs) are the controls the service organisation expects its subservice provider to perform.
Fourth-party chains: if a carved-out subservice organisation hosts the application that calculates your balances, its report belongs in your evidence file too. See the Third-Party Risk Management Guide.

How to review a SOC 1 report as a user entity

Confirm relevance. Check that the services, applications, locations and legal entity in scope are the ones you actually use. A report on the provider's "core platform" may exclude the module that runs your payroll.
Check the type and period. Prefer Type 2. Note the period end and how far it is from your fiscal year end; AS 2601 notes that a shorter test period and a longer time since testing give less support.
Read the opinion. Record whether it is unqualified, qualified or adverse, and whether any control objective was not achieved.
Review exceptions. For each exception, assess whether it affects a control you rely on, read management's response, and decide whether you need compensating procedures. Access control exceptions on in-scope systems deserve particular attention.
Map CUECs. Document how each applicable CUEC is met in your environment, with an owner and evidence.
Handle subservice organisations. For carved-out providers that matter, obtain and review their reports or document why not.
Cover the gap. Obtain a bridge (gap) letter from the provider for the months between period end and your year end. Remember it is a management representation, not auditor-tested: Microsoft and AWS both describe their bridge letters as self-attestations.
Record and escalate. Store the review, conclusions and follow-ups with your vendor risk record, and escalate unresolved issues to the business owner and finance. Repeat annually. See the Vendor Security Assessment Template.

Preparing for a SOC 1 as a service organisation

Scope with customers and their auditors. Identify the services and transaction flows that affect customers' financial statements. Agree which applications, databases, infrastructure and locations are in scope.
Write control objectives and controls. Draft objectives in the AICPA style, map each to specific, testable controls with owners, frequencies and evidence. Keep the set lean: every control you list will be tested.
Define CUECs and CSOCs deliberately. List only what customers must really do, and agree the subservice approach (carve-out or inclusive) with your service auditor.
Run a readiness assessment. Walk through each control, collect sample evidence, and fix design gaps. Inventory every identity with access to in-scope systems, including service accounts, deployment pipelines and scheduler identities.
Issue a Type 1 if customers need something now. It shows design at a date and buys time to build operating history.
Operate for the Type 2 period. Run controls consistently, keep evidence in a central repository, and do internal testing quarterly so failures are found and fixed before the auditor samples them.
Close out and repeat. Prepare management responses for any exceptions, issue bridge letters on a fixed cadence, and avoid gaps between periods. See the Compliance Calendar Template.

If a control proves unworkable during the period, do not quietly change it: agree a documented change with the service auditor, because the description must reflect the controls that actually operated.

Decision guidance

SOC 1 or SOC 2: choose SOC 1 when customers' auditors rely on your processing for financial statements (payroll, billing, investment administration, loan servicing, revenue platforms). Choose SOC 2 when customers mainly care about the security and availability of their data. Offer both when you sell into regulated finance teams and security teams alike.
SOC 1 or ISAE 3402: if customers are mostly outside the US, they or their auditors may ask for ISAE 3402. A combined engagement can serve both.
Type 1 or straight to Type 2: a Type 1 is useful as a first deliverable or for a newly launched service. If you already have six months of reliable evidence, some organisations go directly to Type 2.
Period alignment: as a provider, pick a period end that suits most customers' fiscal years (31 December is common) or issue more frequently, as AWS does quarterly.
Small versus large user entities: a small customer may review only the opinion, exceptions and CUECs for its two or three critical providers. A large or listed company needs a documented review for every provider that touches ICFR, linked to its SOX scoping, and should push providers for CUEC clarity during procurement.
When there is no report: if a provider has no SOC 1, your auditor may need to perform procedures at the provider or you may need stronger controls of your own over inputs and outputs. AS 2601 describes these alternatives.

Measurement

For user entities, monitor the provider population and review timeliness; for service organisations, monitor control operation and exceptions.

Coverage: percentage of ICFR-relevant providers with a current Type 2 (or ISAE 3402 type 2) report reviewed within 60 days of receipt.
Gap months: months between each report's period end and your fiscal year end, with bridge letters obtained where the gap exceeds three months.
CUEC mapping: percentage of applicable CUECs with a named owner and evidence.
Exceptions: number of exceptions per report on access and change objectives, and trend year on year (service organisations).
Identity hygiene in scope: percentage of non-human accounts on in-scope systems with an owner, documented purpose and credential rotation date.
Internal testing pass rate: controls passing quarterly internal tests before the auditor's fieldwork.

Evidence-collection tooling helps with both sides. See the Audit Evidence and Continuous Controls Monitoring Guide.

Framework mapping

Activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Assess providers before contracting and request SOC 1 reports	SA-9 External System Services	GV.SC-06, ID.RA-10	5.19 Information security in supplier relationships
Annual SOC 1 review, exceptions and CUEC tracking	SA-9, CA-7 Continuous Monitoring	GV.SC-07	5.22 Monitoring, review and change management of supplier services
Logical access objectives, including service accounts	AC-2 Account Management, AC-6 Least Privilege, IA-5 Authenticator Management	PR.AA-01, PR.AA-05	5.15 Access control, 5.18 Access rights
Change management objectives	CM-3 Configuration Change Control	PR.PS-01 is related; scope with your auditor	8.32 Change management
Monitoring of logs for in-scope systems	AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-09 is related	8.15 Logging, 8.16 Monitoring activities
Exit and termination of the service	SA-9	GV.SC-10	5.20 Addressing information security within supplier agreements

Common failure patterns

Filing the report unread: the PDF is saved to the vendor record, but nobody checks the scope, period or exceptions. Auditors then find that the report covered a different service or a period that ended nine months before year end.
Ignoring CUECs: the provider's opinion assumes you remove leavers from its portal and reconcile its output. If you do not, the reliance chain breaks at your end, not theirs.
Human-only access populations: service organisations present access reviews that cover staff accounts but omit application service accounts, shared database logins and deployment pipeline identities, which then surface as exceptions or scope limitations.
Treating bridge letters as audit evidence: a bridge letter is management's statement that nothing material changed. It does not replace your own procedures for the gap period.
Carve-outs nobody follows up: the provider carves out its hosting or processing subcontractor and the customer never obtains that party's report.
Over-scoped control sets: first-time service organisations list aspirational controls, then fail them in Type 2 testing. Fewer, well-evidenced controls produce a cleaner report.

Practitioner checklist

Identify every provider whose processing affects your financial statements and record which report type you need from each.
Request SOC 1 Type 2 (or ISAE 3402 type 2) reports annually and calendar the expected receipt date.
Review scope, period, opinion, exceptions and management responses, and document conclusions within 60 days.
Map each applicable CUEC to an owner and an internal control with evidence.
Obtain reports for material carved-out subservice organisations, or document the alternative procedures.
Obtain bridge letters covering the gap to your year end and perform your own procedures for that period.
As a service organisation, inventory all human and non-human identities with access to in-scope systems before readiness testing.
Test controls internally each quarter and keep evidence in one repository the service auditor can sample.
Align your report period and bridge letter cadence with customers' fiscal year ends and avoid gaps between periods.

SOC 1 Guide: Reports on Controls Relevant to Financial Reporting