Search the text of the Sarbanes-Oxley Act of 2002 for the word "vendor" and you will not find it. Section 404, codified at 15 U.S.C. § 7262, requires each annual report to contain an internal control report in which management accepts responsibility for establishing and maintaining "an adequate internal control structure and procedures for financial reporting" and assesses its effectiveness as of the end of the most recent fiscal year. That is the entire statutory text on point - nothing about outsourcing, service providers, or the fourth parties a vendor might itself rely on. Every third-party obligation that shows up in a SOX 404 program - and there is real, testable obligation there - is derived rather than written down, coming from two places: how the SEC defines the scope of internal control over financial reporting (ICFR), and how the PCAOB requires an auditor to obtain evidence about that scope.
Section 404(a) and 404(b): the assessment and the attestation
Section 404 splits into two distinct obligations. Section 404(a) requires every reporting company's management to assess and report on the effectiveness of its own ICFR every year, evaluated against "a suitable, recognized control framework...established by a body or group that has followed due-process procedures" - a formulation the SEC's adopting release, Release No. 33-8238 (June 2003), confirms the COSO Internal Control - Integrated Framework satisfies, while leaving room for other frameworks that meet the same criteria. Section 404(b) is a separate, additional requirement: an independent auditor must itself attest to and report on management's assessment. The two are not the same test performed twice - 404(a) is management's own conclusion; 404(b) is a second, independent opinion layered on top - and it is 404(b) that pulls in the PCAOB auditing standards that actually reach a company's vendors.
Who actually owes a 404(b) attestation
Not every filer owes both halves. Section 989G of the Dodd-Frank Act added a new Section 404(c) to SOX, permanently exempting any issuer that is neither an "accelerated filer" nor a "large accelerated filer" from the Section 404(b) auditor attestation - a change the SEC implemented in Release No. 33-9142 (September 2010). Under the filer definitions in Exchange Act Rule 12b-2, as most recently amended by the SEC's 2020 rule (Release No. 34-88365), that generally means a company with a public float under $75 million - or, since the 2020 amendment, a smaller reporting company with public float up to $700 million but under $100 million in annual revenue - files management's own 404(a) assessment with no auditor attestation behind it. The exemption changes who tests the control, not whether it exists: a non-accelerated filer's management still has to assess ICFR every year under 404(a), including whatever part of it runs through a vendor. What disappears for a smaller filer is the independent auditor's own obligation to go get evidence about that vendor's controls - which is exactly the mechanism, covered next, that pulls a service organization into scope for everyone still subject to 404(b).
Where ICFR scope actually reaches a vendor
The scope test is functional, not organizational: if a process that materially affects the financial statements runs on a system a vendor operates - a hosted general ledger, an outsourced payroll processor, a SaaS billing platform, a managed IT function touching financial applications - that process sits inside ICFR scope regardless of who runs the servers. PCAOB AS 2201, "An Audit of Internal Control Over Financial Reporting That Is Integrated with an Audit of Financial Statements," requires the auditor to obtain evidence sufficient to support an opinion on ICFR as a whole, and its paragraph .B17 says so explicitly: where a company obtains services from another organization that are part of its information system, AS 2601, "Consideration of an Entity's Use of a Service Organization," applies. The auditor cannot simply decline to test a control because a vendor operates it, and management cannot satisfy 404(a) by treating an outsourced process as someone else's problem - the assessment obligation travels with the process, not with whoever happens to host it.
SOC 1 reports: the evidence, and where it stops
AS 2601 gives the auditor two paths: test the vendor's controls directly, or rely on a report from the vendor's own auditor. In practice almost everyone takes the second path, and the report built for exactly this purpose is the SOC 1 - "Report on Controls at a Service Organization Relevant to User Entities' Internal Control over Financial Reporting," issued under the AICPA's SSAE No. 18 (AT-C Section 320) attestation standard. A Type 1 report describes the vendor's controls and opines on whether they are suitably designed as of a point in time; a Type 2 report goes further and tests whether those controls actually operated effectively across a review period, typically six to twelve months - and it is the Type 2 report, not Type 1, that gives a user auditor anything resembling the operating-effectiveness evidence AS 2201 calls for. AS 2601 places one further restriction worth knowing before leaning on either: a user auditor is not permitted to base its own opinion, even in part, on a bare reference to the service auditor's report - the report informs the audit, it does not transfer the opinion.
| Term | What it means for a vendor relationship |
|---|---|
| CUECs (complementary user entity controls) | Controls the SOC 1 report explicitly assumes the customer itself operates - for example, reviewing a vendor-generated report for accuracy, or maintaining its own approvals for who can submit transactions into the vendor's system. A vendor's Type 2 opinion is only complete once the customer confirms its own listed CUECs are actually in place. |
| Carve-out method | Where a vendor itself relies on a sub-service organization (a payroll processor's own cloud host, say), the SOC 1 report can carve that sub-service organization's controls out of its own opinion, leaving the user auditor to separately obtain assurance over it - the SOX-audit version of the fourth-party risk problem. |
| Bridge letter / gap letter | A vendor's own interim representation covering the period between the end of its last SOC 1 report and the customer's fiscal year-end, used to shorten - never fully close - the coverage gap a report's fixed review period leaves. |
None of this is optional paperwork collection. A Type 2 report with unaddressed CUECs, an uncarved sub-service organization nobody separately assessed, or a stale bridge letter standing in for a real test is a gap the company's own 404(b) opinion inherits.
ITGC domains, applied to a vendor's environment
Where a vendor's system falls inside ICFR scope, the same IT general controls (ITGC) domains apply to it that apply internally - ISACA's COBIT framework is the reference most SOX programs use to structure them: change management (are changes to the vendor's financially relevant application authorized, tested, and approved before release), logical access (who at the vendor, and at the company, can create, modify, or approve transactions in the system), and computer operations (do backups, job scheduling, and incident handling operate as the vendor's own SOC 1 description claims). A SOC 1 report is the evidence a company uses to answer these questions about a vendor it does not control directly - it is not a substitute for asking them.
Turning SOX ITGC scope into TPRM actions
- Scope by process, not by procurement category. The test for whether a vendor belongs in the ICFR-relevant population is whether it touches a financial-reporting-relevant process - not whether it was purchased through the same channel as an obviously "IT" vendor. See vendor tiering.
- Confirm CUECs are actually implemented, not just read once when the SOC 1 report arrives - a control the report assumes the company runs is a control an auditor will ask to see evidence of on the company's own side.
- Chase carve-outs to the sub-service organization, rather than treating a carved-out control as someone else's problem to solve later. See fourth-party risk.
- Track SOC 1 report expiration like a compliance deadline, not a filing-cabinet document - a lapsed report window with no bridge letter behind it is a gap the next audit cycle will find regardless of whether the program noticed first.
- Treat 404(a)'s annual assessment obligation as real even where 404(b) does not apply - a non-accelerated filer with no auditor attestation still has to make its own defensible judgment about vendor-hosted ICFR processes.
Where this sits among TPRM platforms
Tracking which vendors carry SOC 1 report obligations, mapping CUECs to owners, and chasing bridge letters on a compliance calendar is governance workflow that platforms such as OneTrust and ProcessUnity are built to run alongside the audit-evidence trail a 404(b) attestation requires. Security-rating vendors such as BitSight, SecurityScorecard, and UpGuard are built to answer a different question - a vendor's current, externally observed security posture - which a SOC 1 report's fixed review window does not cover on its own (see evidence-based risk scoring). Rescana's role is pairing continuous, evidence-based monitoring with automated evidence collection, so a vendor's ICFR-relevant risk picture does not go stale in the months between one SOC 1 report and the next.
Frequently asked questions
What does Sarbanes-Oxley require for third-party service providers?
Nothing directly - the text of SOX Section 404 (15 U.S.C. section 7262) never mentions vendors or service providers. The third-party obligation instead comes from how broadly the SEC and PCAOB scope internal control over financial reporting (ICFR): if a process material to the financial statements runs on a system a vendor operates, that process is inside ICFR scope regardless of who hosts it. PCAOB AS 2201 requires the auditor to obtain sufficient evidence over that full scope, and AS 2601 governs how the auditor does that when a service organization is involved - typically by relying on the vendor's own SOC 1 report.
What is a SOC 1 report and why does it matter for SOX compliance?
A SOC 1 report - formally, a Report on Controls at a Service Organization Relevant to User Entities' Internal Control over Financial Reporting, issued under the AICPA's SSAE No. 18 attestation standard - is the evidence a company's auditor typically relies on under PCAOB AS 2601 when a vendor operates part of the company's ICFR. A Type 1 report opines only on whether the vendor's controls are suitably designed at a point in time; a Type 2 report tests whether those controls actually operated effectively over a review period, usually six to twelve months, and is the version that supports a SOX Section 404(b) opinion.
What are complementary user entity controls (CUECs) in a SOC 1 report?
CUECs are controls a SOC 1 report explicitly assumes the customer, not the vendor, operates - such as reviewing a vendor-generated report for accuracy or maintaining its own approval process for who can submit transactions into the vendor's system. A vendor's Type 2 opinion is only complete in practice once the customer confirms its own listed CUECs are actually implemented; an unaddressed CUEC is a control gap the company's own SOX assessment inherits, not a failure of the vendor's report.
Are all public companies required to get an auditor attestation under SOX Section 404(b)?
No. Section 989G of the Dodd-Frank Act added Section 404(c) to SOX, permanently exempting any issuer that is neither an accelerated filer nor a large accelerated filer from the Section 404(b) auditor attestation requirement - generally, companies with a public float under $75 million, or, after the SEC's 2020 filer-definition amendments, smaller reporting companies with public float up to $700 million and under $100 million in annual revenue. Those companies still must complete management's own Section 404(a) assessment every year, including for any process that runs through a vendor - they just do so without an independent auditor separately attesting to it.