When a public company should pursue SOX ITGCs, the NIST CSF or both
If your company is an SEC registrant, the answer to the board's question starts with a fixed point: SOX Section 404 is a legal duty, and it covers only financial reporting risk. Management must assess internal control over financial reporting each year, and for accelerated and large accelerated filers that are not emerging growth companies, an auditor attests to it (15 U.S.C. 7262). The IT general controls you test are the ones needed for the consistent operation of controls that address financial reporting risk. The NIST CSF is different in kind. It is a voluntary framework for the whole cybersecurity program, and no regulator requires you to adopt it or to certify against it. So the scope decision for SOX is not optional, while the decision to run a CSF program is a choice about how to organize everything else.
Most public companies that adopt the CSF do run both, and the usual reason is practical: the CSF gives the board a single view of cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond and Recover, while ITGC testing answers a narrower question about financial systems. Access provisioning, change management and computer operations evidence that your ITGC team already collects can support CSF Subcategories in the Protect and Govern Functions. Use it to build a Current Profile, then record gaps where the CSF asks for outcomes that ITGC testing never examines, such as incident response beyond financial systems or supplier risk outside the financial close. Confirm the Subcategory mapping with your external auditor before you rely on it, because the auditor's ITGC scope is set by the auditor's own risk assessment, not by the CSF.
Neither path produces a certificate. An ICFR evaluation ends in management's assessment and, where applicable, an auditor's attestation, and the CSF has no conformity assessment program: NIST states that it does not certify or endorse CSF implementations. Any vendor or consultant who offers a CSF certificate is selling something NIST does not recognize, so ask for the actual deliverable, such as a profile, a gap register or an auditor's report, before you sign. The SEC cybersecurity disclosure rules sit alongside both programs and are covered separately on this page.
How SOX and the NIST CSF differ on scope, authority and proof
This table compares SOX IT general controls with the NIST CSF 2.0 on legal basis, scope, structure, governing standards, enforcement and the proof each produces. Read it to see why ITGC evidence can support a CSF profile without satisfying it, and why CSF alignment does not replace a Section 404 assessment.
| Factor | SOX IT general controls | NIST CSF 2.0 |
|---|---|---|
| Legal basis | Section 404 of the Sarbanes-Oxley Act of 2002 and SEC rules under it (15 U.S.C. 7262) | Voluntary framework published by NIST; not a regulation |
| Who requires it | Management of SEC registrants filing annual reports on ICFR | Not required by law for most organizations; some customers or suppliers require it, and U.S. federal agencies must use it under a 2017 executive order |
| Scope of risk covered | Only IT controls that support reliable financial reporting, as SEC guidance describes it | The whole cybersecurity program, including risks outside financial reporting |
| Structure | Areas management may consider, such as program development, program changes, computer operations and access to programs and data | Six Functions (Govern, Identify, Protect, Detect, Respond, Recover), 22 Categories and 106 Subcategories, plus Tiers and Profiles |
| Catalog of controls | No SEC rule or PCAOB standard publishes an ITGC catalog; relevant areas vary with each company's facts | Published Core, with Implementation Examples and informative references to other standards |
| Governing standards | SEC Release 33-8810, PCAOB AS 2201 and AS 2110, and COSO 2013 Principle 11 on technology general controls | NIST CSWP 29 and the CSF 2.0 Reference Tool; mappings to other standards are maintained alongside it |
| Enforcement | SEC oversight of management's ICFR evaluation and the external auditor's attestation | No regulator enforces the CSF; obligations come from contracts, sector rules or agency mandates |
| Proof produced | Management's annual ICFR assessment and, for eligible filers, an auditor attestation | No certification or conformity assessment; NIST has no plans to create one |
Who must apply SOX ITGCs and who chooses the NIST CSF
Section 404 of the Sarbanes-Oxley Act of 2002 requires management of an SEC registrant to assess internal control over financial reporting (ICFR) every year. For accelerated and large accelerated filers that are not emerging growth companies, the external auditor must also attest to that assessment. For these registrants, IT general controls (ITGCs) are part of the legal evidence base, because the automated controls that produce financial figures depend on them.
- Management assessment: Management must evaluate ICFR annually, and this evaluation covers the ITGCs that support financial reporting controls.
- Auditor attestation: The external auditor attests to ICFR only for accelerated and large accelerated filers that are not emerging growth companies (15 U.S.C. 7262).
- Scope rule: Management evaluates only the ITGCs necessary for the proper and consistent operation of controls that address financial reporting risks, not those that only affect operational efficiency (SEC Release 33-8810).
- Company-specific scope: No SEC rule or PCAOB standard lists the ITGCs that apply, so the relevant areas depend on each company's facts and circumstances.
- Auditor reliance: Auditors assess IT risks under AS 2110 and test ICFR under AS 2201, so the ITGC scope agreed with them shapes the evidence you must produce.
Confirm with your external auditor which systems feed significant accounts and which ITGC areas they will test before you fix the scope.
Registrants that are not accelerated or large accelerated filers, and emerging growth companies, still have to evaluate ICFR. The difference is the auditor attestation. Without an attestation requirement, the evaluation still has to be documented and supportable, and the same SEC guidance on ITGC scope applies. Smaller registrants often find the scope question sharper, because a small finance function may depend on a handful of systems and shared administrator accounts.
- Management still evaluates: The Section 404(a) management assessment applies to registrants regardless of filer status, under the framework rule in Rule 13a-15(c).
- No attestation layer: The auditor attestation in Section 404(b) is not required for these registrants, which changes the external testing workload and the evidence trail auditors will request.
- Cost driver: The SEC estimated in 2020 that an issuer newly exempt from the 404(b) attestation would save about $210,000 per year on average, roughly $110,000 in audit fees and $100,000 in other costs (Release 34-88365).
- Same scope test: The question of which ITGCs matter to financial reporting is identical, so access, change and computer operations controls still need a financial reporting link.
- Filer status changes: Filer status can change from year to year, so confirm your status with counsel before assuming you are exempt from attestation.
Check your filer status and the current SEC guidance with your securities counsel before you reduce the ITGC scope.
The NIST Cybersecurity Framework 2.0 is a voluntary framework for managing cybersecurity risk across the whole organization, not only financial reporting. NIST is not a regulatory agency and does not certify or endorse implementations. Most organizations adopt it because a board wants a common language, a customer or insurer asks for it, or a supplier contract requires it. None of these creates the legal duty that Section 404 does.
- Voluntary for most: Most organizations use the CSF voluntarily, though some companies require it of customers or suppliers.
- Contractual pressure: Customers, insurers or regulators in some sectors may ask for CSF alignment, so the written requirement determines what you must show.
- No certification: NIST has no plans for a conformity assessment program, so no CSF certificate exists to prove adoption.
- Broader audience: CSF 2.0 applies to all organizations regardless of size, sector or maturity, which is why a board can adopt it without an SEC filing duty.
- Separate evidence: A CSF profile records your own current and target states, so it does not replace ITGC testing evidence.
Ask the requesting party in writing which CSF outcomes and evidence they expect, and whether they accept ITGC evidence in place of a separate assessment.
For U.S. federal agencies, the CSF is not optional. A 2017 executive order made the framework mandatory for federal agencies. This is the one situation where the CSF carries a government requirement, but it still does not replace the financial reporting duties that apply to any public company. A federal agency does not file under Section 404, and most federal financial controls are assessed through federal audit processes rather than SOX.
- Mandatory use: A 2017 executive order made the CSF mandatory for U.S. federal agencies (NIST CSF FAQs).
- No SOX duty: Federal agencies are not SEC registrants, so Section 404 does not apply to them.
- Contractors: Federal contractors that handle government data may face contract-driven requirements, which are separate from the CSF mandate for agencies.
- Mixed organizations: A public company that serves federal agencies may need both SOX ITGC evidence and CSF-aligned evidence, each with its own owner.
- Scope boundaries: The mandate covers the agency's cybersecurity program, so the financial reporting scope is defined by the agency's own audit framework.
Confirm the exact federal or contract requirement with the contracting officer or agency counsel before mapping your controls to the CSF.
Where SOX ITGC work and CSF work overlap
SOX ITGC testing and a NIST CSF program meet in the same technology controls, but they answer different questions. The overlap is in how access, change and operations are governed, while the purpose, scope and proof differ. Use the cards to decide where one body of evidence can serve both programs and where it cannot.
Access to programs and data
SEC guidance names access to programs and data as an IT general control area management might consider for ICFR. In a CSF program, the same work usually sits under the Protect Function, in identity and access management Categories. Check whether your auditor treats a given access review as ICFR evidence for specific financial applications and databases, and whether the review covers privileged and service accounts, which often drive the testing scope.
Program change control
Program changes are another ITGC area named in SEC guidance. The same change approvals, testing and segregation of duties can support a CSF Protect or Govern outcome for the same systems. The difference is the test population: an ITGC test samples changes to systems that feed financial reporting, while a CSF program may cover every production change. Confirm which systems and change types your auditor will sample before building one shared change record.
Computer operations
Computer operations, covering job scheduling, backups and incident handling for financial systems, is a third ITGC area in SEC guidance. CSF 2.0 places related work in its Recover and Detect Functions. Operational evidence such as backup restoration tests and job failure logs can serve both programs. Ask your auditor whether restoration tests and incident records must cover specific financial applications, since a CSF program may hold them to a broader scope.
Governance and oversight
COSO's 2013 framework, in Principle 11, asks organizations to select and develop general control activities over technology. CSF 2.0 added the Govern Function to the five Functions of earlier versions, so both frameworks expect management to set policy, assign ownership and review results. Use the same risk register and committee minutes for both, but confirm that management's ICFR evaluation under Rule 13a-15(c) is documented separately from the broader CSF program reports the board receives.
Cross-referenced mappings
NIST's CSF 2.0 Reference Tool export links Implementation Examples and informative references to SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022, CIS Controls v8.1 and PCI DSS. NIST notes that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement. The export does not map Subcategories to ITGC areas, so confirm any ITGC-to-Subcategory correspondence with your external auditor before you rely on it.
Who assesses each framework and what each one produces
This table compares who checks each framework, what document or evidence the organization ends up with, and how often the cycle runs. Read it to separate the SOX attestation chain from the CSF's self-directed profiles, then decide which outputs your board and auditors will actually ask for.
| Dimension | SOX ITGC (Section 404) | NIST CSF 2.0 |
|---|---|---|
| Who assesses | Management assesses ICFR; an external auditor attests under AS 2201 for accelerated and large accelerated filers that are not emerging growth companies | No certification body and no NIST conformity assessment program; the organization or a party it commissions carries out any review |
| What is issued | Management's ICFR report and, for eligible filers, the auditor's attestation report | The organization's own Current and Target Profiles, plus any evidence it chooses to share |
| Evaluation basis | Rule 13a-15(c) requires evaluation against a suitable, recognized framework; the SEC guidance in Release 33-8810 satisfies it | Gaps are measured against the organization's own target outcomes, not a pass or fail result |
| Cycle | Annual, as of each fiscal year end, with the auditor's work following the financial reporting cycle | No mandated cycle; organizations set their own review rhythm for profiles and evidence |
| Auditor's IT risk work | AS 2110 risk assessment requires an understanding of the ITGCs important to automated controls | Not applicable; the CSF does not define an external audit step |
| SEC disclosure cycle | Regulation S-K Item 106 requires an annual description of cybersecurity risk processes, including any assessors or consultants used; Form 8-K Item 1.05 requires incident disclosure generally within four business days after materiality is determined | The CSF does not create a disclosure duty; the SEC rules that apply sit alongside it and must be reconciled with any CSF claims made to the board |
Using CSF profiles alongside ITGC evidence without double counting
The practical rule is that a CSF Profile can point at ITGC evidence, but the evidence never becomes CSF proof on its own. Record a Current Profile and a Target Profile for the whole cybersecurity program, then map each relevant Subcategory to the artifacts your team already gives the external auditor: quarterly user access reviews, approved change tickets, and batch job logs for financial processing. Each mapping should name the owner, the system and the period covered. Keep the mapping clear that the artifact supports an outcome; it does not certify it. NIST states that it does not offer certifications or endorsements of CSF implementations, so no ITGC artifact can be presented to the board as CSF conformance.
Do not read the four Tiers (Partial, Risk Informed, Repeatable and Adaptive) as a SOX pass mark. The Tiers describe how rigorously an organization manages cybersecurity risk, and they say nothing about whether a control operated effectively over a fiscal year. A team can reach a high Tier in some areas while a single ITGC deficiency remains open. Keep Tier discussions in the board pack separate from the Section 404 deficiency evaluation, and avoid reporting a Tier as an ICFR result.
Profiles and ITGC testing use different scopes, which is the main source of double counting. ITGCs cover the systems and processes that support financial reporting risks. A Profile can cover the entire organization, including operational technology, customer-facing systems and business units that never touch the general ledger. Before you map, decide whether one piece of evidence will count toward both a financial reporting control and a Profile outcome, and record that decision. Ask the external auditor which evidence it will accept, how it will select samples and over what period, because the auditor's sampling method determines how much one artifact can carry. Also check the current CSF Quick-Start Guides and informative reference mappings before you map, since NIST updates those more often than the CSF 2.0 Core.
Sequencing SOX ITGCs and a CSF program in one organization
This sequence lets an organization set the SOX scope first, then build a wider NIST CSF program on top of it, so shared controls are mapped once and evidence is reused without blurring what each framework is for.
Confirm filer status and the financial reporting systems
Start by confirming with counsel and the finance lead which filer category applies and whether the company is an emerging growth company, since that determines whether an auditor attestation under Section 404 is required. Then list the systems, interfaces and processes that produce or support financial reporting, using the SEC's framing that management evaluates only the IT general controls needed for the proper and consistent operation of controls addressing financial reporting risks. Done means a signed scope memo that names each in-scope application, its business owner and the reporting process it supports, with operational-only systems explicitly excluded.
Document ITGC design and evidence owners with the auditor
Document the ITGC control design for the in-scope systems across the areas management typically considers, such as program development, program changes, computer operations and access to programs and data, recognizing that the relevant areas vary by company. Review the draft with the external auditor early so their view of IT risk, including the understanding of IT general controls their standard expects for automated controls, shapes the design rather than being discovered at year end. Done means a control narrative for each area, a named evidence owner for every recurring control, and the auditor's written comments recorded.
Build CSF Organizational Profiles starting with Govern and Identify
Build the Current and Target Organizational Profiles for the wider cybersecurity program, starting with the Govern Function, which covers the risk strategy, roles, policy and oversight that the board will ask about, and then the Identify Function, which covers asset, supplier and risk context. Keep the profiles scoped to the whole enterprise, not only financial reporting systems, so they show what the CSF program covers beyond SOX. Done means approved Current and Target profiles with a stated Tier ambition for each Function and an owner who can explain the gap to the board.
Map shared controls to CSF Subcategories as organization judgment
Use the NIST CSF 2.0 Reference Tool export to look up the Subcategories that match each in-scope ITGC, along with its Implementation Examples and informative references. Treat every mapping as the organization's own judgment, because NIST develops and maintains the informative references with non-NIST entities, does not check the correctness of non-NIST mappings, and does not treat a listed mapping as endorsement. Note where one ITGC supports several Subcategories and where a Subcategory has no ITGC equivalent. Done means a versioned mapping workbook with a reviewer's initials on each row and a note on the mappings that the external auditor did not review.
Set evidence reuse rules and disclosure owners
Agree in writing which evidence can be reused across the SOX test and the CSF program, such as access reviews and change tickets, and which must be produced separately because the purpose or population differs. Assign a named disclosure owner for Regulation S-K Item 106, which asks how the company assesses, identifies and manages material cybersecurity risks and whether it uses outside assessors or consultants, and a separate owner for the Form 8-K Item 1.05 incident process, which requires disclosure generally within four business days after the company determines an incident is material. Done means a reuse standard, a RACI for both disclosures, and a tested escalation path from the security team to the disclosure committee.
Run an annual review tied to the fiscal year end
Set the annual cycle so the ICFR evaluation, which the rules require as of each fiscal year end against a suitable, recognized framework, is completed before the year-end close and the auditor's fieldwork. Refresh the CSF profiles, the mapping workbook and the Item 106 description on the same calendar so the board sees one consistent story, and record which informative references or Quick-Start Guides changed since the last review. Confirm the review schedule with the auditor and counsel rather than assuming a date. Done means an approved calendar, a change log for the mapping workbook and minutes showing board review of the updated profiles.
What buyers ask before bringing in outside help on SOX and the CSF
Does following the NIST CSF satisfy SOX Section 404?
No. The CSF does not replace SOX. Section 404 requires management's annual assessment of internal control over financial reporting and, for accelerated and large accelerated filers that are not emerging growth companies, an auditor attestation. Its scope is financial reporting risk, and the auditor's testing follows PCAOB standards. A CSF program can produce evidence that supports ITGC testing, but the CSF has no attestation output of its own, so the two should be mapped to each other rather than treated as interchangeable.
Is there a NIST CSF certificate we can show our board or customers?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans to develop a conformity assessment program. Any firm offering a CSF certificate is selling its own service, not a NIST credential. When a customer or board asks for proof, the useful artifacts are a documented current profile, a target profile, and evidence that ITGC testing results map to the relevant subcategories.
What drives the cost of an ITGC program?
The main drivers are the number of in-scope systems and applications, the number of key controls in each area, how much the external auditor is willing to rely on management's testing, the quality and completeness of evidence, and who performs the testing. Costs are split between internal staff time, which recurs every testing cycle, and any outside assessor fees, which depend on the written scope. Ask any provider to price these drivers separately so you can see what changes if scope shrinks or auditor reliance increases.
How much could a newly exempt issuer save on the 404(b) attestation?
The SEC estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, roughly $110,000 in audit fees and $100,000 in other costs, according to Release 34-88365. That figure describes the savings from an exemption, not the price of running an ITGC program. Your own savings depend on your filer status, the size of your control environment and how much work management still performs, so confirm eligibility with your auditor and counsel before using the number in a budget.
How long does an ITGC assessment take, and what sets the timeline?
The timeline is set by the number of systems in scope, how many controls depend on each system, whether evidence already exists in a usable form, and the fiscal calendar that determines when testing must finish. Programs that already have documented access reviews and change tickets move faster than those rebuilding evidence from scratch. Ask for a schedule with milestones tied to the year-end date and the auditor's interim testing windows, and confirm that the agreed dates work with those windows.
What do we need from our own staff for this work?
Most of the effort sits with internal people. You need named control owners who can explain each key control, system owners who can confirm configuration and scope, and an administrator who can produce user access listings, privileged account data and change records on request. Staff time is a recurring cost because the same people supply evidence every cycle. Agree on these roles before work starts, since delays in evidence usually cost more schedule time than the testing itself.
Can our own team run the management assessment without a partner?
Often yes for the management assessment, provided the team has people who understand both SOX testing and the systems in scope, and it can document controls and retain evidence consistently. A management evaluation can follow the guidance in Release 33-8810, which Rule 13a-15(c) recognizes. Before you decide, confirm your external auditor's expectations for documentation, sample sizes and reliance, because those expectations shape the work more than the framework does.
How DeployOpen scopes and supports readiness for SOX ITGCs and the CSF
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For SOX vs NIST CSF work, we help teams separate the ITGC evidence that supports financial reporting from the wider CSF program, so each can be tested on its own terms.
How we scope
- Agree in writing which systems support financial reporting and which ITGC areas the written scope covers
- Map each in-scope control to its owner, evidence source and the Release 33-8810 area it addresses
- Record which CSF Functions and Categories the wider program will cover and which stay out of scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts
How we build
- Configure access, change and logging controls on self-hosted platforms so they produce reviewable evidence
- Run security testing on in-scope applications and infrastructure, with findings tracked to remediation
- Draft a CSF Current Profile and Target Profile that links to existing ITGC evidence without duplicating it
- Document control design and operation so management can perform its annual ICFR evaluation
How we hand over
- Deliver control narratives, evidence catalogs and runbooks for the ITGC areas in scope
- Provide a mapping showing where one ITGC control also supports a CSF Subcategory, with the mapping's limits noted
- Walk your control owners and auditors through the evidence so they know where each item comes from
- Note what the external auditor must still test and confirm, since DeployOpen does not issue audit reports
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Update profiles and evidence when platforms are upgraded or when disclosure obligations change
- Coordinate with your internal audit, legal and disclosure teams on Item 106 descriptions and Form 8-K timing
- Review ITGC and CSF documentation on an agreed cadence set in the retainer
Sources and further reading
- 15 U.S.C. 7262, Management assessment of internal controls (SOX Section 404 as amended) ↗
- Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting, Release 33-8810 ↗
- 17 CFR 229.106 (Item 106 of Regulation S-K) Cybersecurity ↗
- SEC press release 2023-139: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure ↗
- NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 ↗
- NIST Cybersecurity Framework FAQs ↗
