How Do You Bridge SOC 2 Type 2 to SOX 404 ITGC for a Public-Company Customer?

You have a SOC 2 Type 2 report. A public-company customer is now asking whether it can satisfy their SOX 404 ITGC reliance requirement. This article answers that question concretely: which existing SOC 2 controls map to the four ITGC categories, where the gaps are, what the bridge letter must say, and whether you need a SOC 1 or SOC 2+ alongside what you already have. The framework comparison primer — which standard applies to you in the first place — is covered in SOC 2 vs SOX. This article assumes you have cleared that threshold.

When does a SOC 2 Type 2 report help a customer’s SOX 404 effort (and when does it not)?

Financial relevance is the threshold: your product must process, store, or transmit data that feeds the customer’s general ledger, revenue recognition, payroll, or financial statements. Billing platforms, GL-feeding data warehouses, and payroll providers are the most common examples. If your product does not touch those workflows, the customer’s SOX auditor may not need to assess your controls at all.

When financial relevance is confirmed, the customer’s SOX Section 404(a) management assertion — and for accelerated filers, SOX Section 404(b) external attestation — creates the ITGC reliance ask. Under 404(b), the customer’s PCAOB-registered auditor tests IT General Controls at service organizations in scope, and PCAOB AS 2410 governs how they rely on service auditor reports.

SOC 2 Type 2 helps when: CC6, CC7, and CC8 are in your scope; the observation period ends within four months of the customer’s fiscal year-end; and the customer’s auditor has indicated in prior years that they accept SOC 2 for ITGC reliance.

SOC 2 Type 2 is insufficient when: the auditor requires a SOC 1 for ICFR-relevant controls (SOC 1 is the historical SOX vendor report, structured around the customer’s own ICFR control objectives); Availability is not in scope and Computer Operations coverage is thin; the bridge window exceeds three to four months; or your carve-out subservice organizations’ own reports are unavailable or stale.

Which TSC controls map cleanly to SOX 404 ITGC categories?

The four ITGC categories that SOX 404 auditors test at service organizations are Access to Programs and Data, Program Changes, Program Development, and Computer Operations. The table below maps each to the SOC 2 Trust Services Criteria and notes the practical strength of each mapping for SOX reliance purposes.

ITGC Category	SOC 2 Common Criteria (TSC)	Strength of Mapping	Notes for SOX Reliance
Access to Programs and Data	CC6.1 (logical access controls), CC6.2 (user provisioning), CC6.3 (access removal / JML), CC6.6 (logical access boundaries), CC6.7 (data transmission protection), CC6.8 (malware and intrusion prevention)	Strong	CC6.x is the deepest and most consistently tested area in SOC 2 Security engagements. SOX auditors typically accept CC6 evidence; they may verify sample sizes and confirm that privileged access reviews are included.
Program Changes	CC8.1 (change management: design, authorize, test, approve, document, deploy)	Strong	Change ticket linkage, code review evidence, deployment authorization, and pre/post-deployment testing are all within CC8.1 scope. SOX auditors generally accept this with confirmation that financially relevant systems are in scope.
Program Development	Partial: CC8.1 covers change management but does not systematically test SDLC controls for new-system or new-module development	Weak	This is the primary gap. SOC 2 does not address acquisition, development, and implementation project controls the way SOX ITGC testing does. SOX auditors may require separate SDLC walkthroughs if new development activity is material.
Computer Operations	CC7.1 (capacity management), CC7.2 (environmental and operational monitoring), CC7.3 (anomaly and incident detection), CC7.4 (incident response and recovery), CC7.5 (post-incident review), A1.1 (capacity planning), A1.2 (backup and recovery), A1.3 (disaster recovery testing)	Strong (if Availability is in scope)	If Availability is a selected criterion, Computer Operations coverage is extensive. If only Security is selected, CC7.x still covers monitoring and incident response but may not include backup/recovery controls at the depth SOX auditors want.

With Security and Availability in scope, you have credible coverage for three of the four ITGC categories. Program Development is the persistent gap. One critical scope check: the SOC 2 system description must name the specific applications in scope. If the customer’s financially relevant system — say, the billing module feeding their revenue recognition — is not in your system description, the customer’s auditor cannot rely on the report for that system regardless of control quality. Confirm coverage before pointing to the report. For the full Common Criteria definitions, see the AICPA’s SOC suite of services and our Trust Services Criteria explainer. For the firm-qualification view of how SOC 2 firms map controls to SOX 404 ITGC scope, see the auditor certification overview.

Where does the customer’s external auditor still require re-testing or a separate SOC 1?

PCAOB AS 2410 gives the customer’s auditor discretion on whether to rely on the service organization’s report or test directly. Four conditions consistently trigger re-testing or a parallel SOC 1 requirement.

Sample size re-performance. PCAOB-registered firms maintain internal sampling standards typically more conservative than AICPA standards for private-company engagements. If your SOC 2 tested privileged access reviews on three samples per quarter and the customer’s Big Four auditor expects 25, they may perform their own tests. This is most common for access provisioning, access removal, and change management controls.

User-entity control testing. SOC 2 reports often include user entity controls (UECs) — controls the customer must operate on top of yours, such as periodic review of the user access list your system exports. The customer’s auditor tests whether those UECs are operating. That burden falls on the customer, but it generates friction when the customer has not been running those controls consistently.

Program Development gap. If a financially relevant system underwent significant new development during the testing period, the SOX auditor will perform a separate SDLC walkthrough — requirements management, design approval, testing protocols, go-live authorization. Your SOC 2 report does not satisfy this; it requires a direct walkthrough with your engineering team.

Subservice organization treatment. If you use the carve-out method for AWS, GCP, or a payment processor, the customer’s auditor needs those providers’ own current SOC reports. If you use the inclusive method, your auditor has tested through the subservice organizations and the customer can rely on your report for them. Confirm which method your report uses before a customer’s audit cycle starts.

Direct SOC 1 preference. Some Big Four firms maintain policies that preference SOC 1 for ICFR reliance regardless of SOC 2 quality. Ask the customer early whether their auditor has a stated preference — before the audit cycle, not during it. Our SOC 1 vs SOC 2 explainer covers when adding SOC 1 is the right call.

How do SOC 2 review periods and SOX fiscal years interact?

Three scenarios cover most situations:

Scenario 1: Aligned periods. Your SOC 2 observation ends September 30. The customer’s fiscal year ends December 31. A three-month bridge letter is typically sufficient.

Scenario 2: Mismatched by five or more months. Observation ends June 30, customer FY-end December 31. Most SOX audit teams will not accept a six-month bridge without supplemental evidence — mid-period walkthrough, expanded management representations, or a refreshed report. Re-time your observation period to end closer to September or October 31 if this relationship is strategic.

Scenario 3: Multiple customers, different fiscal year-ends. A 12-month observation period — January 1 through December 31 — combined with per-customer bridge letters addresses both a June 30 and a December 31 customer simultaneously. The 12-month period adds roughly 10–20% to audit cost versus a six-month period but is the right model for any SaaS company with more than one public-company customer in active status.

Practical recommendation. If any public-company customer is in your current book or near-term pipeline, move to a 12-month SOC 2 Type 2 observation period now. Bridge windows shrink to near zero for December 31 customers on a January–December observation. If your period already ends more than six months before the customer’s year-end, no bridge letter resolves it — begin scoping a refreshed observation period immediately. For bridge letter mechanics in full, see our SOC 2 bridge letter guide.

What does a bridge letter need to include for SOX consumption?

The standard “no-changes letter” confirms controls have not materially changed since the observation period ended. For a procurement or security team, that suffices. For a PCAOB-registered auditor under AS 2410, it does not. A SOX-grade bridge letter requires five additional elements:

1. Explicit ITGC criteria reference. Name the specific Common Criteria: CC6.1–CC6.8 (Logical and Physical Access), CC8.1 (Change Management), CC7.1–CC7.5 / A1.x (Computer Operations). The customer’s auditor must be able to map the letter’s assurance to the ITGC categories they are relying upon.

2. Bridge-period incident disclosure. Confirm explicitly that no security incidents, unauthorized access events, or control failures occurred during the bridge period that affected the reliability of in-scope ITGC controls. If an incident occurred, describe it and the remediation — the customer’s auditor needs to make an informed reliance decision.

3. Subservice organization confirmation. Confirm that in-scope subservice organizations (AWS, GCP, etc.) experienced no material changes to their controls during the bridge period. For carve-out engagements, provide current SOC reports from those providers if available.

4. Same-partner signature. The engagement partner who signed the SOC 2 Type 2 must sign the bridge letter. A different signer raises continuity-of-knowledge questions that PCAOB auditors flag.

5. Precise date coverage. State the exact start date (observation period end + 1 day) and end date (customer fiscal year-end or letter date, whichever applies).

Confirm in your next engagement letter that the SOX-grade bridge letter is a defined deliverable. Some firms offer it as a distinct product; others include it on request. Wire this in before you need it — not during a rushed year-end close. PwC’s SOC reporting practice benchmarks the most developed version of this: their SOC 2+ framework incorporates SOX-specific testing directly, reducing or eliminating the bridge letter burden for customers whose auditors accept it.

What gap analysis should a SaaS run before its first SOX-relevant customer?

Close these gaps before the customer’s first audit cycle — not during it. A SOX auditor who discovers your SOC 2 does not cover Computer Operations because Availability was never selected, after already planning reliance procedures, creates a crisis for the customer’s audit timeline.

Step 1: Confirm CC6, CC7, CC8 are in scope. Review your most recent report’s system description. Confirm CC6 (Logical and Physical Access), CC7 (System Operations), CC8 (Change Management), and A1.x (Availability) are all in scope and tested. Adding Availability typically costs $5,000–$15,000 more per engagement — the right investment for any company with public-company customers.

Step 2: Map controls to ITGC categories and flag gaps. Use the mapping table in section two. Assign each tested control to one of the four ITGC categories. For the Program Development gap, prepare a management representation letter or walkthrough template your team can produce when a customer’s auditor requests it.

Step 3: Verify subservice organization report periods. Confirm that current SOC 1 or SOC 2 reports from your subservice organizations (AWS, GCP, payment processors) cover the same observation period as your report. Period mismatches surface during the customer’s auditor’s review and cannot be papered over retroactively.

Step 4: Assess bridge letter cadence. If your observation period end-date is more than four months before your target customer’s fiscal year-end, model the cost of shifting or lengthening to 12 months. For active public-company customer relationships, 12 months is the right default.

Step 5: Decide on report structure. Three options in increasing cost:

• SOC 2 only — viable when CC6, CC7, CC8, A1 are in scope and the customer’s auditor will accept it under AS 2410. Right for Series A–C SaaS with a small number of public-company customers.
• SOC 2 + SOC 1 — dual reporting. SOC 2 satisfies security buyers; SOC 1 directly satisfies the SOX auditor. Adds $25,000–$50,000 in annual audit cost. Right when your product is embedded in billing, payroll, ERP integration, or GL data flow.
• SOC 2+ — SOC 2 with added SOX-aligned ITGC testing scope. A small number of Big Four and large specialist firms offer this. For the auditor tier decision, see Big Four vs. specialist.

For accelerated filer customers with 404(b) attestation required, or multiple modules each touching different financial systems, engage a SOX-specialist with direct PCAOB experience. Our fintech SaaS perspective covers the most common version: a payments or revenue infrastructure company where customer-driven SOX exposure is structural. The full firm directory, filterable by SOX-aligned scope capability, is at /best-soc-2-auditors/.

Frequently asked questions

Can a SOC 2 Type 2 satisfy a public-company customer’s SOX 404 ITGC reliance requirement?

It can, but the customer’s auditor — not your report — makes that call. Strong CC6, CC7, CC8, and A1 coverage plus a properly drafted bridge letter gives the auditor what they need under PCAOB AS 2410. Many PCAOB-registered auditors still prefer or require a SOC 1 for ICFR reliance regardless of SOC 2 quality. Confirm the customer’s auditor preference early.

Which SOC 2 Trust Services Criteria map to SOX 404 ITGC categories?

CC6.1–CC6.8 → Access to Programs and Data. CC8.1 → Program Changes. CC7.1–CC7.5 + A1.x → Computer Operations. Program Development has no direct SOC 2 equivalent; SOC 2 does not test SDLC new-development controls, and that gap may require a separate walkthrough.

What is a SOX bridge letter and what must it include?

A SOX bridge letter confirms controls have not materially changed between the SOC 2 observation end-date and a specified current date. Beyond the standard no-changes language, it must reference CC6, CC7, CC8 explicitly, disclose any bridge-period incidents affecting those controls, confirm no subservice organization changes, and be signed by the same engagement partner who signed the SOC 2 report.

What happens when the SOC 2 observation period and the customer’s fiscal year do not align?

A gap up to three or four months is bridgeable. Beyond four months, most PCAOB auditors require a refreshed observation period or supplemental evidence. Multiple public-company customers with different fiscal year-ends is the clearest argument for moving to a 12-month SOC 2 observation period.

When does a public-company customer’s auditor require a SOC 1 instead of a SOC 2?

SOC 1 is required or strongly preferred when your product processes data that directly flows into the customer’s financial statements — billing, payroll, GL journal entries, revenue reporting. SOC 1 Type II is structured around the customer’s ICFR control objectives, which maps more naturally to PCAOB AS 2410 reliance. If the customer’s Big Four auditor is asking for SOC 1, that is usually firm policy, not a negotiating position. See our SOC 1 vs SOC 2 guide.

What is a SOC 2+ report and how does it differ from a standard SOC 2?

SOC 2+ adds supplemental criteria beyond the standard Trust Services Criteria — for SOX, that means layering ITGC testing objectives onto the standard SOC 2 framework. PwC’s SOC reporting practice is among the most developed examples. For customers whose external auditors accept SOC 2+ for ITGC reliance, it eliminates the need for a parallel SOC 1 engagement.