SOX vs ISO 27001

SOX scope is set by financial reporting risk, not by the security program. SEC Release 33-8810 asks management to evaluate only the IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks. IT general controls that only affect operational efficiency fall outside that evaluation. The release names program development, program changes, computer operations and access to programs and data as example areas management might consider, and it states that these do not apply to every company. The SEC does not publish a fixed ITGC catalog, so the boundary depends on which systems feed the financial statements and which automated controls rely on them.

ISO/IEC 27001 works the other way around. The organization defines the ISMS scope itself, then selects the controls from Annex A that its risk assessment and statement of applicability justify. Annex A is normative and lists 93 controls, but an organization can include or exclude them within its documented scope, provided it justifies the choices. A company may therefore find that its ISMS scope covers customer data platforms, support tooling and corporate endpoints that SOX never touches, while a general ledger interface is in SOX scope and is only partly addressed in the ISMS. Confirm with your auditor which in-scope applications and interfaces they will test, and map that list against your ISMS scope statement before either program is designed.

Practical check: ask the external auditor to confirm in writing which systems, interfaces and user populations form the ITGC population for the current fiscal year, then compare that list to the ISMS scope and the applicability statement. Gaps in either direction are the usual source of rework. Systems inside SOX scope but outside the ISMS need the same access and change controls documented once, with the evidence stored where both teams can reuse it. Systems inside the ISMS but outside SOX scope should not be pulled into the ICFR test unless the auditor asks for them.

The cost of a SOX program and an ISO 27001 program come from different payers, so compare them by who pays for what rather than by a single total. For SOX, management pays for its own ICFR assessment and for the internal control testing that supports it. For an accelerated or large accelerated filer that is not an emerging growth company, the external auditor's attestation under Section 404(b) is an additional, recurring fee. For ISO 27001, the organization pays the accredited certification body for its audits and pays internally for the work that precedes them: the internal audit program, management review meetings and the upkeep of the scope boundary. The SEC's 2020 estimate for an issuer newly exempt from the auditor attestation, about $210,000 per year (roughly $110,000 in audit fees and $100,000 in other costs, Release 34-88365), shows how much of the SOX recurring cost sits in the attestation itself. Ask your auditor and your certification body for their own fee structures, since the SEC figure reflects one issuer group in 2020.

One-time work is front-loaded in both programs. For SOX, control design, documenting the IT general controls that matter to financial reporting and closing gaps before the first assessed year are one-time efforts, while annual testing of access, change and computer operations controls recurs every fiscal year. For ISO 27001, scoping, the statement of applicability, the first risk assessment and gap work against the Annex A controls are one-time, while the surveillance audits in each calendar year and the recertification audit at the end of the three-year cycle recur. Both programs also recur through evidence collection, so ask each vendor to separate initial implementation from annual running cost in writing.

Four factors drive the effort in either program. The first is the number of in-scope systems: every application that feeds the general ledger, or that holds information within the ISMS scope, adds access reviews, change records and logs to produce. The second is the number of sites and legal entities, which multiplies walkthroughs and sample sizes. The third is control maturity: a team that already runs documented change approvals and quarterly access reviews spends far less on remediation than one that must build them. The fourth is internal staff capacity, since a small team that must also run the internal audit function will buy more outside help. Before requesting a quote from DeployOpen, write down the in-scope systems, sites, entities and the controls you already operate, and provide that written scope, because DeployOpen does not publish prices and fixed-scope quotes follow from it. Confirm with your external auditor which systems they expect in the ITGC walkthroughs, and with your certification body which sites and processes sit inside the ISMS boundary.

Start with the SEC interpretive release before any framework work, because it sets the boundary for the SOX side. 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, and it names program development, program changes, computer operations and access to programs and data as areas to consider. It also states that these areas do not apply to every company. Read it to confirm which systems feed your financial close, then pair it with the PCAOB standards that govern the external auditor: Auditing Standard No. 5, now AS 2201, covers ICFR testing, and the risk assessment standards, including what is now AS 2110, cover how the auditor assesses IT risk. Confirm with your auditor which ITGC areas they will test and at what depth, since no SEC rule or PCAOB standard publishes a catalog of IT general controls.

Next, read the ISO certification page and the IAF transition documents if a customer has asked for certification. The ISO certification page makes the basic point that ISO does not certify organizations, accredited certification bodies do. Then check the IAF MD 26:2023 transition document, which records that all ISO/IEC 27001:2013 certificates had to expire or be withdrawn by 31 October 2025, and confirm that any existing certificate your customers refer to is on the 2022 edition. Also ask certification bodies to confirm they apply IAF MD 29:2024, which required ISO/IEC 27006-1:2024 for all clients by 31 March 2026.

These sources settle scope principles, auditor testing, the certification process and the 2022 edition transition. They do not settle how your ISMS scope should be drawn, whether a SOX ITGC test will accept ISMS evidence, or how long your certification cycle runs in practice. Put those questions to your external auditor and to the certification body in writing before scoping begins, and keep their answers in the project file alongside the SEC and PCAOB references.