SOX ITGCs in the public cloud: what you inherit and what you own

What SOX ITGC work stays with you when financial systems run on AWS

When a public company runs its ERP or financial reporting platform on AWS, the provider's SOC 1 report and its bridge letter supply evidence about AWS's own controls, but they do not discharge your SOX IT general controls. You still own and must test the customer-side access, change and operations controls over the financial application. The split is not fixed. AWS places physical and environmental controls wholly with the provider, treats patch and configuration management as shared, and leaves zone security with the customer. Where your system runs on Amazon EC2, you manage the guest operating system, patches, installed applications and security group configuration, so those settings fall inside your program. Start by mapping each service in the financial data path to the responsibility matrix in AWS's shared responsibility model, then record who owns each control for that service.

Management's obligation does not shrink because the provider is large or well audited. SEC staff guidance states that management maintains a responsibility to assess controls over outsourced operations even when it relies on a service auditor's report. In practice, that means reviewing the AWS SOC 1 Type 2 report for the services in scope, checking that the report period and the bridge letter cover the assessment date, and documenting any gap. AWS reports are obtained through AWS Artifact, where a non-disclosure agreement is required before you can review them, and AWS says its SOC reports are typically released about 9 to 10 weeks after the period ends. Confirm current availability in your own account before planning a fiscal year end. Your team should also confirm that each financially significant service appears in AWS's services in scope list for SOC 1.

The customer-side work is concrete. Test that IAM roles and administrative access to the financial application, its database and its hosts are approved, reviewed and removed on termination. Test that changes to AMIs, infrastructure templates and application code pass through documented approval before production, and that privileged deployment paths are logged. Test that backups, job scheduling and monitoring for the financial workload are configured, run and reviewed. Only your independent auditor issues an opinion on ICFR, and only an external CPA firm issues a SOC report. An implementation partner can prepare configurations, logs and evidence packages, but the control owner and your auditor determine whether those controls operate effectively.

Who owns each ITGC area on AWS

Access controls are where the customer's ownership is most visible. AWS secures the physical facilities and the underlying infrastructure that run its services, but the people and roles that can reach your financial data are defined in your account. Auditors will ask who can administer the account, who can assume privileged roles, and whether those rights match job duties. Access to the guest operating system and the application layer on EC2 sits with you, so those accounts must be managed separately from AWS-level identities.

IAM roles and policies: Your team defines who can create, change or delete roles and policies, and it must show periodic review of those grants.
Privileged account controls: Root account use, administrator sessions and break-glass access need approval, logging and monitoring that you can produce on request.
Guest OS and application access: Logins to instances, databases and the financial application itself are your responsibility, including account provisioning and removal.
Leaver and mover processes: Terminations and transfers must remove access in both the cloud console and the application.

Confirm with your cloud provider's documentation which access controls sit in your scope for each service you use, and document that boundary in your walkthrough.

How to use AWS SOC 1 reports and the bridge letter in your assessment

Your assessment depends on AWS evidence only after you have obtained the right documents and checked what they cover. AWS makes its SOC 1 and SOC 2 reports available through AWS Artifact, and you must accept an NDA before you can review them. Its SOC 3 report is published as a public whitepaper, but that summary is too general to support ITGC testing. Download the SOC 1 Type 2 report, then confirm that every AWS service your financial applications, databases and hosting depend on appears in the report's scope. AWS lists its in-scope services on the Services in Scope by Compliance Program page, so check each service name against that list rather than assuming coverage from the platform as a whole.

The report period almost always ends before your assessment date. AWS says its SOC reports are typically released about 9 to 10 weeks after the period ends, so a report can be several months old by the time you need it. The SOC Continued Operations Letter is AWS's bridge letter, and AWS updates it monthly in AWS Artifact to cover the time since the last report period. Ask your audit team which bridge coverage it expects, obtain the latest letter for each assessment date, and record the gap between the report period end and your fiscal year end. Any gap that the bridge letter does not cover needs your own compensating evidence, such as your own change and access reviews for that period.

The report is not a substitute for your own controls. Its opinion assumes that customers perform the complementary user entity controls described in the report, and management must assess whether it performs them. On AWS, these typically include the account and identity configuration you control, the security group and guest operating system settings you manage on EC2, and the approval of changes you make to your own environment. Build a list of these controls from the report, map each one to an owner and a test, and document how you tested it. Where the report notes a control you do not operate, confirm that the responsibility sits with another party and is written into your agreement with AWS or your integrator.

Customer-owned controls that auditors test on cloud platforms

Even when a provider's SOC 1 report covers the cloud facilities and underlying infrastructure, the company still runs the access, change, configuration, operations and recovery controls that sit on top of it. Auditors test these controls against your own records, so the evidence has to come from your accounts, ticketing and monitoring tools.

User access reviews and privileged access

Your team owns who can sign in to the cloud console, assume administrator roles and reach the databases behind financially significant applications. Auditors usually ask for periodic access review sign-offs by a reviewer who is not the account holder, plus the list of privileged roles and the approvals that created them. Check that identity provider groups match the role assignments in the cloud account, and that leavers are removed on time.

Change management for code and infrastructure

Changes to application code and infrastructure as code are your responsibility, even though the provider runs the platform beneath them. Auditors typically sample changes and ask for the request, the peer review or approval, test results and the deployment record showing the change reached production. Confirm that the people who can merge code cannot also approve and deploy their own changes without a separate check.

Configuration and security group change approval

On Amazon EC2, the customer manages security group configuration, so changes to network rules, instance settings and guest operating system hardening fall to your change process. Auditors look for approval records for these changes and evidence that unauthorized changes are detected. Ask which configuration changes are logged, who receives alerts on them, and whether a periodic review compares the live state with the approved baseline.

Job scheduling and monitoring

Batch jobs, interfaces and data feeds that move financial data are often configured by your team, and their failures can leave ledgers incomplete. Auditors ask for job schedules, the alert rules that flag failed or late runs, and records showing that someone reviewed and resolved exceptions. Confirm that job definitions are under change control and that monitoring covers every job that feeds a financial report.

Backup and restore testing

The provider keeps its infrastructure resilient, but you decide which data is backed up, how long copies are kept and whether a restore actually works. Auditors usually request backup schedules, retention settings and restore test records that show a recovered environment matched expected results. A backup that has never been restored is weak evidence, so ask for dated restore tests that cover the financial systems in scope.

Incident handling and escalation

Security and operational incidents affecting financial data are handled by your team, even when the provider notifies you of an event on its side. Auditors look for an incident log, the triage and escalation steps taken, and evidence that root cause analysis led to any needed changes or control fixes. Confirm that cloud alerts route to a named team and that incidents affecting financial processing are assessed for their effect on reporting.

How to set up cloud ITGC evidence before fiscal year end

This sequence turns an AWS-hosted financial system into a documented set of inherited, shared and customer-owned ITGCs, with provider evidence that the external auditor can rely on and your own evidence for the controls that stay with you.

Map in-scope systems to AWS services
Start by listing every application, database, interface and supporting tool that feeds financially significant reports and where each one runs. For each component, record the AWS services it uses, such as EC2, managed databases, storage or identity services, and whether the workload is a provider-managed service or a resource you configure. Management owns this inventory, and the external auditor will compare it against the provider's list of services in scope. The step closes when every in-scope component is mapped to a service and a responsible party, and the list is signed off by the control owners.
Obtain and review the provider SOC 1 report
Download AWS's SOC 1 report from AWS Artifact, where a non-disclosure agreement is required before you can open it. Confirm the report period, the services in scope against your mapping, the opinion, the controls tested and any exceptions, and whether the complementary user entity controls section lists obligations that fall to you. Check the report against the services list on the AWS compliance programs page. The step closes when a reviewer has recorded that each mapped service is covered for the full period and that every exception has an impact assessment on your controls.
Close the period gap with the bridge letter
AWS publishes its SOC reports on a lag after the period ends, so the report rarely reaches your fiscal year end. Obtain the SOC Continued Operations Letter from AWS Artifact, which AWS updates monthly and which covers the time since the last report period. Confirm the letter's coverage date reaches or passes your assessment date and that it does not disclose changes to the scope you mapped. Where a gap remains, document how your own controls cover that interval. The step closes when the report and letter together cover the full assessment period, or the uncovered dates are recorded with compensating procedures.
Document customer-owned and shared controls
Using the AWS shared responsibility model, sort each ITGC into three groups: controls AWS fully inherits, controls shared with AWS where you implement your part, and controls that remain entirely yours. On EC2, for example, you own the guest operating system, patching, installed applications and security group configuration. Write each customer-owned control with its owner, frequency, system and the evidence it produces, covering user access reviews, change approvals, job monitoring and backup restores. The step closes when every mapped system has a complete control narrative and no ITGC area is left without an owner.
Document complementary user entity controls
Go through the complementary user entity controls listed in the provider report and map each one to a control you operate, such as restricting administrative access to the AWS account, reviewing who holds roles that can change production resources, or approving configuration changes. Where the report assumes a control that your organization does not perform, record that gap as a finding for remediation. Confirm that the owner of each mapped control understands what the provider assumes. The step closes when every complementary user entity control has a matching internal control or a documented gap.
Test design and operation of your controls
Walk through each customer-owned control with its owner to confirm it is designed to address the risk it targets, then select samples over the period and inspect the evidence: access review sign-offs, change tickets with approvals and test results, AWS Config or CloudTrail records, backup and restore logs, and incident tickets. Management or an independent tester performs this work, and the results are recorded against each control. The step closes when design and operating effectiveness results are documented for every control, with exceptions logged and their impact assessed.
Close gaps and remediate before year end
Address each exception or design gap by correcting the control, adding a compensating procedure or redesigning the process, then retest the affected control with fresh evidence. Assess whether any unresolved gap could affect a financial reporting control that depends on the ITGC, since that determines how it is communicated to the auditor. Confirm the remediated controls operated long enough to show they work before the assessment date. The step closes when the gap register is either empty or each open item has an owner, a documented impact conclusion and an agreed path with the auditor.
Hand the evidence package to the external auditor
Assemble the package in one indexed location: the in-scope inventory, the provider SOC 1 report and bridge letter, the shared responsibility mapping, the complementary user entity control matrix, control narratives, test workpapers and the remediation log. Agree with the external auditor on the form of evidence and the walkthrough schedule before fieldwork starts. Remember that the auditor forms its own conclusions and that management remains responsible for the provider's controls even when it relies on the service auditor's report. The step closes when the auditor has confirmed receipt, the open questions are logged, and management has signed off on the package.

What to have in place before the auditor arrives

Auditors testing SOX ITGCs on AWS start from what AWS has already tested and what you still must prove. These six items show which evidence covers the provider's side, which covers yours, and where the two meet. Check each one against the period under audit, not just the date you pull it.

System and service inventory

List every financially significant application, database, server and storage resource, and the AWS services each one runs on. Map each AWS service to the Services in Scope list for the compliance programs your auditor will rely on. A service missing from that list, or in scope only for a different report, creates a gap that the provider's SOC report cannot fill. Confirm the inventory matches the account structure and that it is reviewed each quarter.

Current SOC 1 report and bridge letter

Download AWS's SOC 1 report from AWS Artifact and the SOC Continued Operations Letter that covers the time since the report period ended. AWS says its reports usually release about 9 to 10 weeks after the period ends, so a bridge letter is what closes the gap to your year end. Keep a written review memo that records the report period, the opinion, any exceptions, and the subservice organizations carved out. Reviewing the report does not transfer your responsibility for it.

Complementary user entity controls list

The SOC 1 report assumes that customers run specific controls, often covering account administration, access to the AWS console, and the use of the service within their own environment. Write each assumed control down, name the owner, and point to the evidence that proves it operates. Any control the report expects you to perform and you cannot show is a gap your auditor will raise. Review this list whenever the report or your AWS footprint changes.

Access review records

You own identity and access inside AWS accounts, including IAM users and roles, root account use, federated logins, and security group configuration. Retain completed quarterly reviews that list each privileged principal, the business reason, the reviewer's sign-off, and removals made. Check that the population reviewed matches the live IAM and Identity Center data, not a spreadsheet kept by hand. Gaps in joiner, mover and leaver handling are the most common access findings.

Change records for guest and application layers

AWS manages the hardware and facilities, but you manage the guest operating system, patches, installed applications and configuration of the services you use. For each change, retain the request, approval, test evidence and deployment record, and link them to the affected resource. Pull a sample across the audit period and confirm each change has a ticket, an approver who is not the requester, and a matching log entry in your change pipeline. Infrastructure as code history can support this if it is reviewed and locked.

Backup restore test evidence

Backups and recovery are part of computer operations and remain your responsibility for the data and applications you run on AWS. Keep the backup schedule, job success logs, and the results of at least one restore test in the period, showing the restored data was usable. Confirm which backup services and retention settings are in scope for the financial systems and that the restore test covers the database as well as the application server. A backup that has never been restored is weak evidence for the auditor.

Where cloud SOX programs usually fall short

The most common cloud SOX gap is treating a provider's SOC 1 report as proof that your financial controls work. The report covers the provider's controls over its own service, not the controls you run on top of it. AWS's report can show that physical access, environmental safeguards and its share of patch and configuration management operated during the audit period, but it says nothing about who in your organization can assume a role that changes general ledger data, whether your EC2 instances were patched, or whether your security group rules were reviewed. Before you rely on any report, map each control your financial applications depend on to one of three owners: the provider, you, or shared. Then confirm the report actually tests the provider controls you named.

The second gap is letting the coverage period drift. AWS says its SOC reports are typically released about 9 to 10 weeks after the period ends, and its SOC Continued Operations Letter is updated monthly in AWS Artifact. Teams often download the report, file it, and forget that the assessment date keeps moving. Ask your auditor which bridge documentation they will accept for the gap between the report period end and fiscal year end, and schedule the monthly letter download as a recurring task with a named owner. Missing letters in the last quarter are a common reason testing slips into year-end fieldwork.

Two more gaps show up in almost every first cloud audit. Teams skip the complementary user entity controls section of the provider report, which lists the controls the customer must operate for the report's conclusions to hold, such as restricting who can administer the account and reviewing access granted to external parties. Teams also treat shared controls as fully inherited. Patch management and configuration management are shared, so AWS may patch its hypervisors while you still own the guest operating system, the change record for your AMI, and the baseline configuration of your resources. For each shared control, write down your scope in one sentence and attach the evidence you will produce, such as patch reports, configuration snapshots and approval tickets.

Questions buyers ask about SOX ITGCs in the cloud

Can management rely on the AWS SOC 1 report alone for SOX ITGCs?

No. The AWS SOC 1 report covers the controls AWS operates, such as the facilities, hardware and parts of the infrastructure that AWS runs, but it does not cover the controls your organization operates on its own accounts. Management still has to assess the controls over outsourced operations even when it relies on a service auditor's report, as SEC staff guidance states. Your own user access reviews, change approvals for the workloads and configurations you deploy, and job monitoring remain your evidence to produce. Confirm the exact services and controls in scope for your accounts by checking the services in scope list and the report itself, since scope depends on which AWS services your financial systems use.

How much effort does the customer side of cloud ITGCs take?

The effort depends mainly on how much of the financial stack you manage. On Amazon EC2, for example, you manage the guest operating system, patches, installed applications and security group configuration, so each of those becomes a control you must design, operate and evidence. Drivers that raise effort include the number of financially significant applications hosted in the cloud, the number of accounts and environments, how often infrastructure changes, whether you use infrastructure as code, and how well identity and logging are already centralized. Effort is recurring, because access reviews, change testing and operations checks run every period. Ask any partner for a written scope that lists the systems, accounts, controls and evidence formats before agreeing on a quote.

Can we run cloud SOX ITGCs in-house or do we need outside help?

Many organizations run the work in-house, and the decision usually turns on capacity and skills rather than on whether the law permits it. Management owns its controls and must perform and document the assessment, so internal staff can do the work. Outside help is commonly used to set up the controls, build evidence pipelines, document the design and run a readiness review before the external auditor arrives. An implementation partner prepares systems and evidence, but it cannot issue audit reports or opinions. Those come only from the independent external auditor. Weigh the internal team's cloud, identity and audit experience against the number of controls and the audit calendar before deciding.

What does an AWS bridge letter cover and what does it miss?

A bridge letter, called the SOC Continued Operations Letter in AWS Artifact, covers the time between the end of the last SOC report period and the present, so it helps close a gap in coverage. AWS updates it monthly. It does not replace the SOC report, does not test controls, and does not extend the opinion to periods the report does not cover. It also does not cover the controls you operate in your own accounts. Your team still needs its own evidence for the full period under audit. Review the letter's date against your assessment period and document how you confirmed that no significant changes affected the coverage. Your auditor will decide what additional evidence is needed.

How long does it take for AWS SOC reports to arrive?

AWS says its SOC reports are typically released about 9 to 10 weeks after the period ends. Plan your timeline around that release window rather than the period end, because your management assessment and auditor fieldwork may need the report before it is published. SOC 1 and SOC 2 reports are available to customers through AWS Artifact, where an NDA is required to review them, and the SOC 3 report is published as a public whitepaper. Confirm current release timing in AWS's SOC FAQs before setting a calendar, since timing can change.

What can a partner do for the external auditor, and what can it not do?

A partner can help you prepare: map controls to the cloud environment, document the design of your ITGCs, configure logging and access tooling, collect and organize evidence, and run a readiness review before fieldwork. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments. A partner cannot test controls on the auditor's behalf in a way that substitutes for the auditor's independent work, cannot conclude on the effectiveness of ICFR, and cannot issue an audit report or attestation. Only the independent external auditor issues those. Ask any firm to state in writing which deliverables it will produce and which belong to management or the auditor.

How DeployOpen prepares cloud ITGC evidence for your audit

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, so the controls you own are built, tested and evidenced in a form your auditor can review. We prepare systems and evidence for your assessment; management owns the controls, and only the external auditor issues opinions.

How we scope

We agree a written scope listing the financial applications, cloud accounts, regions and administrative paths that sit inside your SOX ITGC boundary.
We map which AWS shared responsibility items you inherit and which guest operating system, access and configuration controls remain yours.
Engagements are fixed-scope, so deliverables, responsibilities and timelines are settled in writing before any work starts.

How we build

We configure access, change and logging controls in your accounts so each control has a named owner, a defined trigger and retained records.
We set up privileged access and change workflows that produce approvals and review records an auditor can sample across the period.
We document each control's design, including what the provider's SOC 1 report covers and where your own complementary controls must operate.

How we hand over

You receive control narratives, configuration baselines and evidence runbooks that show who performed each control and when.
We walk your team through how to pull population reports for access reviews, change tickets and backup restores before the auditor asks.
Evidence is delivered to your repositories in your environment, so your team retains ownership of the records after the engagement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which keeps controls and evidence current as your cloud estate changes.
We can review changes to the provider's SOC 1 coverage, bridge letter timing and your own controls before each assessment period closes.
Your auditor remains the party that tests controls and issues any report; we answer their questions about how the evidence was produced.