Are cybersecurity controls in scope for SOX, and which ones?
Security controls are in SOX scope only when they support the financial reporting risk. Under the test in SEC Release 33-8810, management evaluates the IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks, and does not need to evaluate IT general controls that only affect operational efficiency. A firewall rule set, an endpoint agent or a security awareness program is not in scope because it is a security control. It is in scope if a failure of that control could allow a financially significant application, database or report to be altered, accessed or lost in a way that would prevent a reliable financial close. The question to answer is therefore not whether a tool is security related, but which automated control or report it protects.
Scope depends on the company's facts and circumstances. Release 33-8810 states that the aspects of IT general controls relevant to an ICFR evaluation vary with each company, and neither the SEC nor the PCAOB publishes a catalog of them. Management owns the scoping decision and must document how it reached it, including which applications, databases and infrastructure support financially significant accounts and which automated controls depend on them. The external auditor then tests that decision under PCAOB AS 2201 and assesses IT risks under AS 2110, so a scope that is not supported by a documented risk rationale is likely to be challenged at audit. Confirm with your auditor early which security platforms they expect to see in the ITGC inventory, because that expectation often differs by company.
Which security controls auditors commonly test as ITGCs
Auditors do not start from a fixed list of security controls. They start from the financially significant systems and data, then test whether the security controls protecting them keep financial reporting reliable. The six families below appear most often because each one protects an application, database, infrastructure component or dataset that feeds the financial statements.
Logical and privileged access
Logical access controls limit who can view, change or administer financially significant applications, databases and operating systems, and privileged access covers the accounts that can bypass those limits. The financial reporting link is that unauthorized access can lead to improper changes or unauthorized transactions, a risk PCAOB AS 2110 names directly. Auditors typically test provisioning and removal approvals, periodic user access reviews, and the list of accounts with administrator rights against the population of in-scope systems.
Authentication for financial systems
Authentication settings determine how users prove their identity to financial applications, including password rules, multifactor requirements, session timeouts and single sign-on configuration. The reporting link is that weak or bypassable authentication lets someone act under another user's identity, which undermines the accountability that approval controls depend on. Check whether the configuration in production matches the approved standard, whether exceptions are documented, and whether directory settings that feed the application are also governed.
Change control over financial applications
Change control ensures that modifications to financially significant applications, configurations and infrastructure are requested, tested, approved and moved to production by people who did not build them. The reporting link is that an unapproved change can alter calculations, master data or reports without anyone noticing. Auditors commonly sample changes and trace each one to a ticket, a test record, an approval and a production deployment record, and they look for developers with production write access.
Backup and recovery
Backup and recovery controls keep financial data retrievable after corruption, deletion, ransomware or hardware failure. The reporting link is the loss of data or the inability to access it, which PCAOB AS 2110 lists as an IT risk to internal control over financial reporting. Evidence usually includes backup job logs, periodic restore tests, retention settings and the procedure for recovering a financial system, so confirm that restores are tested, not only that backups complete.
Job processing integrity
Job processing controls confirm that scheduled and batch jobs that move financial data, such as interfaces, interest accruals or period-end runs, complete fully and accurately. The reporting link is that a failed or altered job can silently drop or duplicate transactions even when the underlying application is well controlled. Auditors often test job monitoring, error handling and reconciliation procedures, and they check who can edit job schedules and scripts.
Vulnerability and patch management
Vulnerability and patch management keeps in-scope operating systems, databases and applications updated and free of known exploitable weaknesses. The reporting link is that an unpatched component can be used to access or alter financial data, and a compromise can invalidate the integrity of the system. Confirm which systems are in the scan population, how patch timing is set and approved, and how exceptions for systems that cannot be patched are documented and compensated.
What PCAOB AS 2110 says auditors treat as IT risks to ICFR
External auditors do not start with a list of security tools. They start with the risks that AS 2110 asks them to understand, and paragraph B4 of its Appendix B names the IT risks to internal control over financial reporting that matter here. The first is unauthorized access to data, which might lead to destruction of data, improper changes, or the recording of unauthorized or non-existent transactions. The second is potential loss of data or inability to access data as required. For a security team, these two risks translate directly into controls the company already runs: privileged access reviews on the ERP and general ledger databases, change controls on production configurations, and backup and restore testing for financially significant systems. A breach that touches the general ledger database is a SOX matter because it threatens the integrity of the balances, not only the confidentiality of the records.
The mapping works in the other direction too. When a control such as multi-factor authentication for finance administrators, logging of changes to journal entry tables, or immutable backups of the ledger is in place, the auditor asks which financial risk it addresses and whether it operates reliably enough to rely on. Your task is to tie each security control to a specific financial reporting risk and a named system, then confirm that the owner, frequency and evidence are documented. Controls that protect systems with no bearing on the financial statements may be good practice but generally fall outside the ICFR evaluation. Confirm with your external auditor which applications and databases they have scoped in, because that scoping decision determines which security controls they will test.
The ICFR test itself is performed under PCAOB AS 2201, which governs how the auditor tests and opines on the effectiveness of internal control. AS 2110 shapes the risk assessment that feeds that test, and the auditor uses AS 2201 to decide how much work each IT-dependent control requires. Management carries the same logic into its own Section 404 evaluation. The practical step is to walk through the risks in B4 with your auditor early in the planning cycle, agree on the financially significant systems, and ask which security evidence they will sample. Reports from a security operations platform, access review exports and restore test records are only useful if they are complete, dated and tied to the period under audit.
How disclosure controls connect security incidents to Section 302 certifications
Under Section 302 of the Sarbanes-Oxley Act, the CEO and CFO certify each periodic report. Their statements cover several points: they are responsible for establishing and maintaining internal controls, they evaluated those controls within 90 days before the report, and they disclosed to the auditors and the audit committee any significant deficiencies, material weaknesses, and fraud involving personnel with a significant role in internal control. They also report significant changes in internal controls. A security incident does not have to be a financial event to matter here. If it affects an in-scope IT general control, such as access restrictions or the integrity of a financially significant system, the officers may need to assess it under these statements.
- Responsibility statement: The officers confirm that they own the internal control system, so an incident cannot be delegated away from their review.
- 90-day evaluation: The evaluation must be recent relative to the report, so an incident in that window needs to be reflected in what the officers rely on.
- Deficiency and weakness disclosure: An incident that exposes a control gap may be a deficiency, a significant deficiency, or a material weakness, and the officers must communicate it.
- Fraud involving key personnel: Compromised credentials used to alter financial records can create a fraud question that reaches this statement.
- Significant changes: Emergency fixes or system changes made during response can count as changes to internal control.
Confirm with counsel and the external auditor how your company documents this assessment for each incident affecting in-scope controls.
The audit committee oversees the financial reporting process and the relationship with the external auditor, so it is the channel through which significant control matters reach the board. Section 302 requires that significant deficiencies, material weaknesses, and relevant fraud be disclosed to this committee. In practice, the committee needs enough information to judge whether an incident has changed the company's control environment, not only the technical facts of the attack. Its role is to receive and challenge the officers' assessment, not to perform the control evaluation itself.
- Escalation path: Define in advance which incidents touch in-scope controls and must be raised to the committee, and who makes that call.
- Auditor communication: Agree with the external auditor how incident findings will be shared, so the committee and the auditor hear the same account.
- Documented challenge: Minutes should show that the committee questioned the impact on IT general controls and the compensating steps taken.
- Remediation tracking: The committee should see whether control gaps exposed by an incident are closed before the next evaluation date.
- Oversight of providers: Where a third party hosts or operates a financial system, the committee should understand how that provider's incidents reach the company.
Confirm the committee charter and the escalation procedure in your current disclosure controls documentation.
The facts that support a Section 302 judgment are produced by working teams. Security teams know which systems were touched, what access was granted, and whether logs remain intact. Finance and internal audit teams know which controls depend on those systems and which reports rely on them. Disclosure controls work only when these two groups share a common view of the incident and record it consistently. Neither group should decide alone whether an in-scope control failed.
- Scope mapping: Keep a current list linking in-scope applications, databases, and infrastructure to the financial controls they support.
- Incident triage questions: Ask whether the affected system is in SOX scope, whether access controls or change controls were bypassed, and whether data integrity is in doubt.
- Evidence preservation: Retain access reviews, change tickets, logs, and backup records that show the state of controls before and after the incident.
- Joint assessment record: Document the reasoning for each conclusion about control impact, including what was ruled out.
- Clear handoffs: Define who passes findings to the certifying officers and on what timetable.
Confirm with your internal audit and external auditor which evidence they will expect for an incident affecting an in-scope control.
How Regulation S-K Item 106 differs from SOX scope
Item 106 of Regulation S-K does not define which controls are in SOX scope. It is a disclosure requirement, adopted in 2023, that asks a registrant to describe its processes for assessing, identifying and managing material cybersecurity risks. The description must also say whether the company engages assessors, consultants or auditors for those processes, and how it oversees risks from third-party service providers. Whether a given access control, change control or backup procedure belongs in ICFR scope is still decided by the top-down, risk-based analysis of financial reporting risks that SEC Release 33-8810 describes. A security control can be central to the Item 106 narrative and still fall outside SOX testing because it does not support a financial reporting risk.
The practical consequence is that the two programs should be mapped to the same control inventory rather than maintained separately. Confirm with your disclosure committee and external auditor which of your access, change and computer operations controls already serve as ICFR evidence. Then check whether the same records can also support your Item 106 description of risk processes, such as the frequency of risk assessments, who reviews them, and when outside assessors or auditors were involved. Where a control is in SOX scope, its test results carry over; where it is not, the Item 106 description still needs its own support. Keep a single evidence index so that a control owner's answer to the auditor and the answer in the annual report come from the same source.
Third-party oversight is where the two frameworks most often diverge in practice. Item 106 asks how the company oversees cybersecurity risk from service providers, while SOX asks whether the controls over a provider's systems that affect financial reporting operate effectively. Before the annual filing, ask each owner of a financially significant outsourced system which SOC 1 or equivalent report covers it, which complementary user entity controls the company must perform, and who reviews the provider's security incident notices. Those answers will be needed for both the ICFR assessment and the disclosure narrative, so document them once and cross-reference them.
Scoping mistakes that pull security controls in or out of SOX incorrectly
Most scoping errors come from deciding scope by tool or by category instead of by financial reporting risk. The cards below cover the mistakes auditors see most often and the check that fixes each one. In every case, the documented scoping rationale is what the external auditor reviews first.
Treating every security control as an ITGC
Security teams run many controls, such as endpoint detection, vulnerability scanning and phishing training, that never touch financial reporting. SEC guidance in Release 33-8810 says management only needs to evaluate the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. The fix is to start from the financial reporting risks and ask which security controls protect the systems, data and processing behind them. Document each exclusion with a reason, because a control left out without rationale invites questions about the scope itself.
Excluding controls because a provider runs them
A control that sits inside a SaaS platform or cloud provider still protects financial data, so it does not leave scope because someone else operates it. The organization still owns its access reviews, configuration choices and change approvals for the tenant, even where the provider runs the infrastructure. The check is to list each financially significant system, identify which controls the provider performs, and confirm which ones the organization must still evidence, such as user access reviews, administrator activity and provider reports it reviews. Ask for the provider's assurance reports early, since auditors will ask how the organization relies on them.
Not revisiting scope after a migration
A system migration, platform replacement or new integration can move financial data into a system that was never in scope. Scope set last year may then miss the new database, interface or administrator group that now supports reported figures. Revisit the scoping rationale at each migration milestone and before fiscal year end, not only at the annual planning cycle. Confirm that controls cover the new environment before go-live and that the old environment's data retention and access are still addressed, since data may remain accessible after cutover.
Relying on the security tool inventory
Security teams usually scope their work from asset inventories, cloud accounts and tool coverage lists, which group systems by technology rather than by how money moves. A financial process can cross several of those boundaries, using a payment platform, a reporting database and a spreadsheet extract. Start from the financial process map, trace each significant account and disclosure to the systems that produce it, and then match security controls to those systems. Where the two lists disagree, the process map governs scope, and the gap becomes an item to resolve with both teams.
Omitting data stores that feed reports
Auditors frequently find that the application is in scope while the database, data warehouse or extract store behind it is not. Access to those stores can change reported figures without anyone touching the application, which is the kind of risk the PCAOB risk assessment standard names as unauthorized access to data that could lead to improper changes or unauthorized transactions. Inventory the data stores, reporting tools and scheduled extracts that feed each report, and apply access and change controls to them. Include backup and restoration checks where the loss of that data would stop reporting.
Who owns the scoping decision and who evaluates it
Management owns the scoping decision. The company decides which controls, systems and IT general control areas fall inside its ICFR evaluation, and it must be able to explain why. SEC guidance in Release 33-8810 ties that decision to financial reporting risk: management evaluates only the IT general controls needed for the proper and consistent operation of controls that address those risks, and it need not evaluate controls that only affect operational efficiency. For a cybersecurity control, the working question is whether a failure could let an unauthorized person change, destroy or hide data that feeds a financial statement. Document that rationale for each control in scope, and for each control you leave out, in a form the auditor can follow without asking the team to reconstruct it.
The external auditor tests the scope independently. Under PCAOB AS 2201, the auditor forms its own view of which controls matter and tests them, and under AS 2110 it must understand the IT general controls that support automated controls. An auditor may accept, challenge or expand management's boundary. Expect questions about why a security tool or monitoring service is excluded, how the company identified IT risks to financial reporting, and whether the same risk appears in other areas. Confirm with your audit firm early which scoping artifacts it expects, such as system inventories, risk assessments and control-to-risk mappings, and when it expects them.
An implementation partner prepares the inputs but does not decide. DeployOpen can help build system inventories, control mappings and evidence collection for self-hosted platforms in your own environment, so that the scoping memo rests on accurate facts. It does not decide what is in scope, does not sign off on the company's rationale, and does not issue audit reports or opinions. Those remain with management and the independent auditor. Before engaging any partner, agree in writing which artifacts it will produce, who approves them internally, and who in your organization is accountable for the final scope.
How to check scope is ready before the auditor arrives
Scope is where cybersecurity controls either become SOX evidence or drop out of the audit. The checks below let a compliance lead confirm that the systems, risks, records and sign-offs behind the scope decision hold up before the external auditor asks for them. Each check produces a specific artifact the auditor can test.
Confirm the financially significant systems list
Start with a current inventory of the applications, databases, infrastructure and data stores that feed financial statements, including the reporting tools and interfaces that move data between them. Compare the list against the general ledger, subledgers and key reports, and flag any system added, retired or moved to a cloud or managed provider since the last assessment. Illustrative example: a billing platform that now sends invoices through a new SaaS interface may be missing from the list. The dated, approved inventory is the evidence the auditor uses to select systems for testing.
Map security controls to reporting risks
For each security control in the cybersecurity program, ask whether a failure could lead to unauthorized access to financial data, improper changes to it, or loss of access to it. Those are the IT risks the PCAOB's risk assessment standard names for internal control over financial reporting. Controls that only protect operational efficiency, such as some monitoring or endpoint tools, can be documented as out of SOX scope with a short rationale. The mapping table is the document that shows the auditor why each control is in or out.
Collect configuration and access evidence
For each in-scope system, pull the current configuration settings, privileged account listings, and user access reviews that cover the period under audit. Confirm that the population is complete, meaning the report comes directly from the system with its parameters recorded, not from a manual export. Check that terminated and transferred users were removed on time. The auditor will test these populations, so a report that cannot be reproduced will weaken the control regardless of how well the control operates.
Link change and incident records to ledger systems
Trace a sample of recent changes and security incidents back to the ledger-affecting systems they touched. For changes, confirm each has an authorization, a test record and an approval before production. For incidents, confirm the ticket records whether financial data, processing or access was affected. A ticket that cannot be tied to a system on the inventory leaves a gap the auditor will ask about. Keep the link between the ticket and the system identifier in the record itself.
Obtain management sign-off on the scope rationale
Confirm that management has approved the scope decision in writing, including the systems, the control mapping, the exclusions and the reasons for each. The SEC guidance places the evaluation with management, so an auditor will look for management's own documented judgment rather than a consultant's conclusion. Record the approver, the date and the version of the scope document. Re-approve the document when systems, providers or risks change during the year.
How DeployOpen prepares security control evidence for SOX scoping
DeployOpen helps finance, IT and security leaders decide which security controls sit inside SOX IT general control scope and prepares the systems and evidence that support them. Management owns every control and its conclusions, while an independent auditor issues the opinion.
How we scope
- We start with the written scope, agreed in advance, covering the systems, access paths and security controls under review.
- We map which security controls protect financially significant applications, databases and infrastructure, and which only support operational efficiency.
- We document the scoping rationale so management and the external auditor can trace each decision to a financial reporting risk.
How we build
- We configure and harden self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks.
- We set up access provisioning, change approval and logging so the controls that auditors test produce consistent records.
- We integrate security tooling with existing ticketing and identity systems so evidence is generated during normal operations.
How we hand over
- We document each control's design, owner, frequency and the evidence it produces, in a form management can maintain.
- We deliver test scripts and sample evidence packages that show how each control operates, for review by internal audit and the auditor.
- We hand over runbooks and configuration records so the client's own staff can run and retest the controls after the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial fixed-scope engagement ends.
- We can re-run control tests before each fiscal year end, so gaps surface before the external auditor's fieldwork begins.
- Confirm with your auditor which evidence formats and sampling periods they expect before work starts, and include that in the written scope.
