SOC 2 Type 2 to SOX 404 ITGC: Mapping and Bridge Guide

You have a SOC 2 Type 2 report, and a public-company customer wants evidence for its SOX 404 IT General Controls (ITGC) review. Start with the customer’s financially relevant systems and control requirements. Your report may contain useful evidence, but the customer’s external auditor decides whether it supports the audit.

This guide covers the control mapping, report-period gaps, bridge letters, and the decision to add SOC 1 or additional SOC 2 criteria. Our compliance framework comparison sets SOC 2 beside the other frameworks.

When does a SOC 2 Type 2 help a customer’s SOX 404 effort?

Determine how your service affects the customer’s internal control over financial reporting (ICFR). A billing platform, payroll service, or data warehouse may support transactions or information used in financial statements. Having a public-company customer does not put every feature of your product in SOX scope.

The relevant PCAOB references are AS 2601, Consideration of an Entity’s Use of a Service Organization, and AS 2201, paragraphs B17 to B26, for an integrated ICFR audit. Paragraph B21 names the three things the customer’s auditor weighs in a service auditor’s report: the period covered by the tests and its relation to the as-of date of management’s assessment; the scope, the applications covered and the controls tested; and the results of the tests and the service auditor’s opinion on operating effectiveness. A report is judged on those, not on the Type 2 label.

A SOC 1 report is designed for controls relevant to user entities’ ICFR. SOC 2 examines controls against the Trust Services Criteria. That difference matters even when both reports test access and change management. See SOC 1 vs SOC 2 before commissioning a second report.

The AICPA also publishes Interpretation No. 1 of AU-C section 402, which it describes as discussing the use of a SOC 2 report in a financial statement audit. AU-C is the AICPA’s auditing standard, so the interpretation speaks to audits under AICPA standards; a PCAOB ICFR audit follows AS 2601 and AS 2201.

How should you map SOC 2 controls to SOX ITGC requirements?

The AICPA Trust Services Criteria provide the SOC 2 evaluation framework. The table sets four examples from our controls library against what a financial-statement auditor may ask for. The control IDs are ours, and your report uses its own identifiers. It is an illustrative checklist, not an official crosswalk.

For each row the auditor will also ask for the report’s exceptions on that control, the complementary user entity controls the customer must operate, and the overlap between the tested period and the fiscal year. Management’s bridge letter covers changes and incidents after the period. It does not replace a test.

A Security-only report is assessed on its actual controls, so a missing Availability category is not a rejection by itself, and selecting Availability does not guarantee complete operations coverage. Program development (new systems and modules) is covered in the next section.

For each requirement, record the application, report control identifier, test performed, tested period, result, and any customer control needed alongside it. Flag missing evidence separately from exceptions in tested controls. That gives the customer’s auditor a concrete basis for deciding whether further work is needed.

Our Trust Services Criteria explainer covers the SOC 2 framework. The auditor certification overview discusses questions to ask when choosing a firm for cross-framework work.

When might the customer’s auditor need more testing or SOC 1?

Review these issues before the customer’s audit starts:

• Scope and testing. Compare the report’s applications, controls, test methods, and results with the customer’s requirements. Sample sizes are the customer’s auditor’s call.
• Customer responsibilities. Identify the complementary user entity controls and any other controls the customer must operate. A vendor report does not show that the customer has implemented its own access reviews or reconciliations.
• Development activity. Check relevant new systems and major modules against the development controls actually tested. A missing test may call for additional evidence, but not every SOC 2 report needs a separate SDLC walkthrough.
• Subservice organizations. Read whether the report carves out or includes them. With carve-out treatment, the provider’s controls are excluded from the service auditor’s examination, so separate evidence may be needed. Inclusive treatment brings specified provider controls into scope, but not every provider control or period.

Ask the customer to have its auditor review the proposed scope before you buy additional work. A request for SOC 1 may reflect missing ICFR evidence, the audit team’s requirements, or both, so get the specific requirements rather than treating a report label as sufficient.

How do SOC 2 periods and SOX fiscal years interact?

Under AS 2201 paragraphs B24 and B25, when a significant period has elapsed between the tests of controls and the date of management’s assessment, the auditor performs additional procedures. That includes asking management about changes at the service organization since the report period. Whether more evidence is needed depends on the significance of the outsourced activities, processing errors, and control changes. A longer gap can increase the work; a short gap does not settle sufficiency by itself.

Three scheduling examples:

1. Report ends September 30; customer year-end is December 31. Identify the October to December period and ask what evidence the auditor needs. Management’s bridge letter can describe changes and incidents in that period, and the auditor decides whether further procedures are necessary.
2. Report ends June 30; customer year-end is December 31. Discuss the six-month interval early. Depending on the risks and available evidence, the auditor may need additional testing, customer-side controls, or a later report. A letter alone may not cover it.
3. Customers have different year-ends. Plan both the testing period and the report delivery date. A calendar-year report is issued after December 31, so it cannot be in hand for a customer whose assessment date falls earlier in that year. A longer observation period helps coverage but does not solve every customer’s timing.

Choose reporting dates with your service auditor and the customers who will use the report, and agree the evidence plan for any uncovered interval before year-end. Our SOC 2 bridge letter guide explains the letter itself.

What should a bridge letter include for a SOX review?

Larson & Company explains that management prepares the letter and the independent service auditor provides no assurance over it. Agree the requested content with the recipient. A useful letter should:

• Identify the service organization, covered system, SOC report, and report period.
• State the exact subsequent dates addressed. Do not assert that controls continued through a future date.
• Describe relevant changes to controls, systems, personnel, or service arrangements, including changes involving subservice organizations known to management.
• Disclose relevant incidents, processing errors, and known control deficiencies, with remediation status where applicable.
• Name an authorized management representative as signer, and make clear that it supplements the SOC report without extending the auditor’s opinion.

Tie customer-specific questions to the control mapping where useful. Do not assert that a carved-out provider’s controls remained unchanged unless management has evidence for that statement, and supply the provider’s reports or other evidence separately when available.

If the customer needs independently tested evidence for the gap, ask what procedures or later report would provide it. Changing the letter’s signer to a CPA does not create that evidence.

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

Use this sequence before committing to an audit deliverable:

1. Confirm the customer’s scope: the relevant applications, financial-reporting risks, assessment date, and audit deadline.
2. Map the existing report using the table above. Read the opinion and exceptions as well as the system description.
3. Check shared responsibilities: complementary user entity controls and excluded subservice controls, and what additional evidence exists for each.
4. Agree the period-gap plan. Assign responsibility for management’s letter, supporting records, and any requested testing, and consider report delivery dates as well as observation dates.
5. Choose the report structure. Obtain scope-specific proposals for the options the customer’s auditor considers useful.

The options are:

• SOC 2 only: appropriate when its actual evidence meets the customer’s audit needs, together with any necessary additional procedures.
• SOC 2 and SOC 1: separate reports for Trust Services Criteria and ICFR-related control objectives. SOC 1 still needs the right scope, tests, period, and customer controls.
• SOC 2 with additional criteria, often called SOC 2+: the AICPA permits additional subject matter and suitable criteria in SOC 2 engagements. Specify what is added and how it will be tested. The label alone does not replace SOC 1 or cover an untested period.

Request prices against the agreed scope rather than assuming a standard add-on fee for Availability, SOC 1, or a longer observation period; SOC 2 audit cost shows current ranges by company size. If you need help choosing an audit firm, compare the scope and experience questions in Big Four vs specialist SOC 2 auditors and the auditor directory. The fintech SaaS guide provides context for services involved in payments or revenue workflows.