IT risk assessment for SOX: risks that make ITGCs matter

IT risk assessment for SOX: which risks make ITGCs matter

A public company finance or IT leader preparing for Section 404 needs to show which systems stand behind each financial control. IT risk assessment for SOX means identifying the IT risks that threaten financial reporting, mapping each one to the IT general controls (ITGCs) that keep it in check, and doing this inside management's top-down evaluation of internal control over financial reporting (ICFR) rather than as a separate IT review. The risk categories PCAOB AS 2110 names are unauthorized access to data, IT personnel holding access beyond their duties and breaking segregation of duties, unauthorized changes to systems or programs, potential loss of data or inability to access data when needed, and inappropriate manual intervention. Each one points to a specific ITGC area: access, program changes, or computer operations.

The answer differs from company to company. The cost and effort of meeting this requirement depend on which applications, databases, infrastructure components, locations and reports sit inside the financial reporting process, and on how many automated controls rely on them. SEC Release 33-8810 says the relevant IT general controls vary with each company's facts and circumstances, so there is no fixed list to copy from a peer. Management owns the conclusion about which risks matter and which ITGCs address them, and it must be able to explain that reasoning. The external auditor tests that conclusion under AS 2201 and AS 2110. Outside advisers can help document and organize the analysis, but they cannot make the judgment for management.

A practical starting point is to list each significant account and the automated controls or system-generated reports that support it, then ask for each one which of the five risk categories would cause a misstatement if it failed. Confirm with your auditor how they expect that linkage to be documented, and check the exact wording of AS 2110 paragraph B4 and Release 33-8810 in the SEC guidance on management's ICFR report before finalizing your risk matrix. Where a risk has no mapped ITGC, record why, because gaps in this reasoning are what auditors question first.

How each IT risk maps to an ITGC area

Each IT risk named in the PCAOB risk assessment standard points to one of the ITGC areas SEC guidance describes. The cards below pair the risk with the control area that addresses it and the evidence an assessor will ask to see, so management can build its IT risk assessment directly from the risks that affect financial reporting.

Unauthorized access to data

Unauthorized access to data can lead to destruction of data, improper changes, or recording of unauthorized or non-existent transactions. This risk maps to the access to programs and data area. Check whether user access to financial databases is restricted by role, whether access requests are approved by the data owner, and whether the assessor can see a quarterly review of who holds direct database access, including service accounts.

Privileged access beyond job need

IT personnel holding access beyond what their duties require breaks segregation of duties, so one person could both change and approve a financial transaction. This maps to the access area and to the change area. Evidence includes a privileged access list reconciled to job roles, approval records for elevated rights, and logs showing when admin rights were granted and removed.

Unauthorized changes to systems

Unauthorized changes to systems or programs can alter how a financial calculation runs without anyone noticing. This risk belongs to the program changes area. Assessors typically ask for a sample of changes with the request, approval, test results and production release record, and they check that developers cannot move code into production themselves.

Loss or inability to access data

Loss of data, or an inability to access data when it is required, can stop a close or leave the company unable to support a reported number. This maps to the computer operations area. Check that backups run on schedule, that restores are tested rather than assumed, and that job failures are monitored and resolved with records kept.

Inappropriate manual intervention

Manual intervention in automated processing, such as editing batch files or overriding a job output, can bypass the control the system was meant to enforce. This risk ties to computer operations and to access, since the ability to intervene is itself an access question. Evidence includes job logs, documented manual overrides with sign-off, and reviews of who ran those overrides.

New systems going live untested

A financial system implemented without testing, data conversion checks or go-live approval can misstate balances from its first day. This risk maps to the program development area. Ask for a signed test plan, reconciliation of converted balances to the legacy system, and a documented approval before production use.

How management runs the IT risk assessment within its ICFR evaluation

The sequence starts from financial reporting risks and ends with a documented map from each IT risk to the ITGCs that address it. Management runs it as part of the top-down evaluation of internal control over financial reporting, not as a separate IT review.

Identify significant accounts and assertions
Management starts from the financial statements and disclosures and identifies the accounts and disclosures that could materially misstate the financial statements, along with the assertions that apply to each, such as existence, completeness and valuation. The finance and accounting owners of each process usually lead this work, with IT and internal audit reviewing it. The step is done when management has a documented list of significant accounts, their relevant assertions and the business processes that produce them.
Map processes and identify key controls
For each significant account, management traces the business process from transaction origination through recording and reporting and identifies the controls that address the risks of misstatement. Management separates controls that are automated, manual with system-generated information, or manual without IT involvement. The output is a process narrative or flowchart with the key controls tagged by type. Management should confirm the list with the control owners before moving on.
Identify automated and IT-dependent controls
Within the key controls, management picks out those that depend on technology. This includes automated application controls, such as calculations and three-way matching, and manual controls that rely on system reports, spreadsheets or queries. Each IT-dependent control is recorded with the application, report or data source it uses. The output is an inventory of automated and IT-dependent key controls, which later feeds the scoping decision for the systems involved.
Identify IT risks to those controls
For each automated or IT-dependent control, management asks what could stop it from operating consistently. The PCAOB's risk assessment standard lists categories such as unauthorized access to data, personnel holding access beyond their duties, unauthorized changes to systems or programs, loss of data or inability to access required data, and inappropriate manual intervention. Management records each risk against the control it threatens. The output is a risk register that links IT risks to specific financial reporting controls, with a short note on how each risk could lead to misstatement.
Map each IT risk to the required ITGCs
Management matches each IT risk to the IT general controls that mitigate it, across access to programs and data, program changes, program development and computer operations. For example, a risk of unauthorized changes maps to change management and access controls, and a risk of data loss maps to backup and recovery controls. Management also records which IT general controls are needed for the proper and consistent operation of each automated control. The output is a matrix that shows each IT risk, its mitigating ITGC and the financial reporting control it protects.
Document the risk-to-control map and confirm scope
Management documents the complete chain from significant account to assertion, key control, IT risk and ITGC, and records the rationale for any IT control left out because it only affects operational efficiency. Management should ask the external auditor and internal audit to review the documentation for completeness. The step closes when the map is approved, versioned and ready to support walkthroughs and testing. Confirm with your auditor how they expect this documentation to be presented, since format expectations vary.

How the risk picture changes by environment

When the ERP runs in the company's own data center, the organization owns almost every IT risk that PCAOB AS 2110 describes. Management controls the operating systems, databases, network, physical access and the application itself, so unauthorized access, unauthorized changes and loss of data all sit inside the same governance structure that owns the ICFR. The risk is concentrated, which makes it easier to see and test, but it also means no provider's report covers any part of the stack.

Access exposure: Privileged accounts on the database, operating system and application layers can each allow changes to financial data, so access reviews must cover every layer.
Change control: The organization controls every patch, configuration change and custom program, so change records must reach the production environment without gaps.
Backup and recovery: Management must prove that data can be restored and that the restore process is tested, because no provider holds this responsibility.
Physical and environmental safeguards: Access to hardware and the data center falls to the company, and auditors may ask how those controls connect to financial system integrity.
Evidence ownership: Every log, ticket and review record comes from the company's own tools.

Confirm with your IT team which layers of the stack are in scope, who holds privileged credentials at each layer, and where the logs that prove those controls are stored.

Where IT risk assessments go wrong and how to fix them

Most weak SOX IT risk assessments fail in predictable ways: they run apart from the financial controls they support, they list more IT controls than the auditor needs, or they miss the people and spreadsheets that quietly change numbers. Each card below names one error, why it matters for ITGC scope, and the fix management can apply before the auditor arrives.

Running a separate IT review

An IT risk review that is run apart from the key financial controls often produces a list of technology risks that nobody connects to a control over a financial assertion. SEC guidance says identifying IT risks and controls should be an integral part of management's top-down, risk-based evaluation. The fix is to start from significant accounts and key controls, then ask which IT risks could stop each control from working as designed. Record the link between each risk and the control it threatens, so the assessment and the ICFR documentation tell the same story.

Listing every IT control

Some teams document every IT control their platforms offer, including controls that only affect operational efficiency. SEC guidance says management need only evaluate the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. The fix is to keep the inventory tied to reliance: for each automated control, report, or interface an in-scope control depends on, identify the access, change and operations controls that protect it, and document why other IT controls were excluded.

Overlooking manual intervention and spreadsheets

Assessments often focus on systems and skip the manual steps around them. PCAOB AS 2110 lists inappropriate manual intervention as an IT risk, and auditors also expect understanding of the mix of manual and automated controls. Spreadsheets that calculate accruals, adjust balances or build reports can change figures without any change control. The fix is to inventory end-user computing used in key processes, note who can edit each file, and decide whether it needs its own access and change safeguards.

Missing privileged access held by IT staff

Risk assessments commonly look at business users and overlook IT personnel with access beyond what their jobs require. AS 2110 cites IT personnel holding access privileges beyond their duties as a risk because it breaks segregation of duties. Database administrators, infrastructure engineers and vendor support accounts can often alter financial data or change production code. The fix is to list every role that can reach financial data or production environments, including service and emergency accounts, and compare each role against the duties it needs.

Failing to refresh after system changes

A risk assessment completed once and never updated becomes wrong as soon as a system is upgraded, migrated, acquired or moved to a cloud provider. Each change can add new data paths, new administrators or new reports that management relies on. The fix is to set a trigger for reassessment, such as a major release, a new interface, a hosting change or a new entity, and to record the date and reviewer of each update. Confirm with the auditor how they expect the assessment to be refreshed during the year.

What this assessment costs and who pays for it

No supplied source gives a price or duration for an IT risk assessment for SOX, so the cost of this work has to be built from its inputs. The largest component is usually internal staff time. Finance has to identify significant accounts and assertions, IT has to describe how each system and report is used, and internal audit or the compliance function has to challenge the result. None of that is an external invoice, but it displaces other work and should be planned as a real cost. Ask management to estimate hours by function before anyone agrees to a timeline.

The cost moves mainly with scope. A risk assessment that covers one general ledger, its database and the operating system beneath it is far smaller than one that covers several entities, a cloud-hosted ERP, a data warehouse feeding close reports and a set of spreadsheets used as controls. Each additional location, provider or report adds mapping work. External help is optional and usually bought for specific gaps, such as documenting the IT risk narrative, facilitating workshops or checking the mapping against the entity's control inventory. Those services recur each year only if the scope or systems change materially. Ask whether the first-year effort is a one-time build and whether the annual refresh is priced separately.

The SEC's 2020 estimate in Release 34-88365 is often quoted in SOX budget discussions, but it does not describe this assessment. The release estimated 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. Management's assessment under Section 404(a) continues for those issuers. Ask any consultant or implementation partner for a written scope that lists the systems, locations, reports and hours included, the roles that will do the work, the deliverables, and which costs recur each year, before you compare quotes.

What to have in place before the assessment

Management needs a handful of current records before it can connect IT risks to financial reporting. Each card below names one record, why the risk assessment depends on it, and how to check that it is current and complete before the auditor asks for it.

Significant accounts and processes

Start with a current list of significant accounts, disclosures and the business processes that feed them, such as order-to-cash, procure-to-pay and period-end close. The IT risk assessment only works if each IT risk can be traced to a specific account or assertion. To check it, confirm that every account on the list has an owner, that the list matches the most recent ICFR scoping memo, and that any new revenue stream or system change since the last period is reflected.

Financially significant applications and hosting

Keep an inventory of every application, database and infrastructure component that processes or stores data for in-scope accounts, with where it is hosted, whether on premises, in a cloud account or with a managed provider. Auditors need this to decide which layers carry ITGCs. To check it, compare the inventory against the general ledger and subledger feeds, and confirm that each hosting arrangement names the party responsible for access and change.

Map of privileged access holders

List every person and service account that can change application logic, data, configurations or security settings, including database administrators, infrastructure engineers and vendor support accounts. AS 2110 names IT personnel holding access beyond their duties as a risk to ICFR, so this map is where that risk becomes visible. To check it, reconcile the list against the directory and the application role tables, and flag any holder who can both initiate and approve a change.

Spreadsheets and reports used in controls

Record each spreadsheet, report writer output and custom query that management relies on in a control, such as a reconciliation template, an aging report or a threshold calculation. Each one is information produced by the entity, and its accuracy depends on the ITGCs over its source data and on who can edit it. To check it, confirm that each item has a named owner, a stated source system and a record of who can modify the logic.

Change and access records for the period

Gather the change tickets, approvals, deployment logs and user access reviews covering the most recent period under assessment. These records show whether unauthorized changes or access are being caught, which is the risk AS 2110 lists first in its discussion of IT risks. To check them, sample a few changes from each month and confirm that each one has a request, a tested approval and a deployment that matches the approved version.

Named control owners

Assign one named person to every ITGC and every IT-dependent control, with a backup and a stated responsibility for evidence. Unowned controls tend to produce gaps in the evidence trail, and auditors test whether the person described in the documentation actually performs the control. To check it, ask each owner to describe the control and the evidence they produce, and confirm that the answer matches the written control description.

Who owns the assessment, who helps, and who signs off

Management owns the IT risk assessment and the ICFR conclusion. Under Section 404 of the Sarbanes-Oxley Act, management must assess internal control over financial reporting each year, and SEC guidance in Release 33-8810 says the identification of IT risks and controls should be part of that top-down, risk-based evaluation rather than a separate exercise. In practice, the finance and IT leaders who own the significant accounts decide which threats from the PCAOB list apply to each system, which ITGCs keep those automated and IT-dependent controls reliable, and whether any gap is a deficiency. An outside party can help with the work, but it cannot take over these judgments or sign the conclusion.

An implementation partner prepares the evidence, not the conclusion. A partner such as DeployOpen can help management assemble the inputs to the risk assessment: system inventories, user access listings with their approval history, change tickets with test and approval records, job schedules and backup logs, and the configuration data that shows how each in-scope application behaves. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, so the systems, the evidence set and the deliverables should be written into an agreed scope before work starts.

The external auditor tests and reports independently. Where the company is subject to the auditor attestation requirement, the external auditor tests ICFR under AS 2201 and must understand the IT risks and the ITGCs important to automated controls under AS 2110. The auditor forms its own opinion from its own testing, so it will not accept management's risk assessment as proof on its own. Before work starts, confirm with the audit firm which evidence it expects, how it will sample access and change records, and whether it will rely on any work by a partner or internal audit. Also confirm with the company's own counsel and audit committee who signs the management report under Item 308 of Regulation S-K.

Common questions about SOX IT risk assessment

Do we need a separate IT risk assessment for SOX?

No. SEC guidance says the identification of IT risks and controls should be an integral part of management's top-down, risk-based evaluation of internal control over financial reporting, not a separate exercise. In practice, you start from significant accounts and their assertions, then ask which IT risks could let a misstatement through and which IT general controls keep those risks in check. The output is a mapping from financial reporting risks to ITGCs, which feeds scoping and testing. A standalone IT review that never reaches a financial account usually produces a long list that auditors cannot use. Ask your external auditor how they expect the mapping to be documented before you build it.

How many IT risks should we list?

The number is less important than whether each risk traces to a financial reporting risk. PCAOB AS 2110 names a short set of IT risks to internal control over financial reporting: unauthorized access to data, IT personnel holding access beyond their duties, unauthorized changes to systems or programs, potential loss of data or inability to access data as required, and inappropriate manual intervention. Most organizations start from those categories and add risks specific to their systems, such as a report writer or an interface that feeds the general ledger. Avoid listing risks that only affect operational efficiency, since SEC guidance says those do not need to be evaluated for ICFR. Confirm the final list with your auditor early.

Can we do this ourselves?

Often yes, if your finance, IT and internal audit teams understand both the financial statement risks and how the systems process transactions. Management owns the assessment and its conclusions, so the work cannot be delegated to an outside party in a way that removes that accountability. Outside help is most useful for mapping IT systems to financial accounts, documenting data flows, and checking that the ITGCs chosen actually address the identified risks. An implementation partner can prepare systems and evidence, but only your independent auditor issues an opinion on ICFR. Ask any advisor to describe their role in writing so the division of responsibilities is clear.

How much internal time does the IT risk assessment take?

The effort depends mainly on how many financially significant systems you have, how many of them are integrated, and how well your process and system documentation already exists. Time is usually spent on three activities: confirming which applications and data flows touch significant accounts, interviewing system owners about access and change processes, and reconciling the result with the auditor's expectations. Organizations with clear system inventories and recent ICFR documentation generally spend less time than those reconstructing both from scratch. Ask any consultant to estimate effort from a written scope and to name the internal roles they will need, rather than accepting a generic duration.

Does the external auditor review our IT risk assessment?

Yes. Under PCAOB AS 2110, the auditor must understand how the company uses IT, the mix of manual and automated controls, and the IT general controls important to the effective operation of automated controls. That understanding is built partly from management's documentation, so the auditor will read your assessment, ask how risks were identified, and test whether the controls you selected address them. Gaps usually appear where a risk has no owning control or where a system was left out of scope without reasoning. Share drafts early and keep a record of decisions, including why excluded areas were excluded.

What changes when financial systems move to cloud or SaaS?

The risk categories stay the same, but the places where controls operate change. Unauthorized access and changes may now depend on the provider's administrative tooling, identity federation and release processes, while data loss depends on backup and retention settings you may configure but not fully control. Your assessment should record which controls remain yours, such as user access reviews and configuration changes, and which you rely on through provider reports or contractual evidence. Auditors will ask how you obtain evidence about the provider's controls and whether that evidence covers the period under test. Confirm these responsibilities with the provider and your auditor before you finalize the mapping.

How DeployOpen prepares systems and evidence for your SOX risk assessment

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the IT risks that threaten financial reporting are addressed where the systems run. We prepare systems and evidence for management's assessment; the organization owns its controls, and only the independent external auditor issues attestation conclusions.

How we scope

We agree in writing which financial applications, databases and infrastructure layers fall under the risk assessment before work starts.
We map each IT risk to the access, change and operations controls that keep the affected financial data accurate and complete.
Engagements are fixed-scope, so deliverables and timelines are defined in the written scope before any system changes begin.

How we build

We configure role-based access, segregation of duties and privileged access controls so access risks are limited by design.
We set up change workflows, logging and data backup and recovery so unauthorized changes and data loss leave a traceable record.
We document where manual intervention remains and build review steps so that it is visible and checked.

How we hand over

We deliver a risk-to-control matrix that links each identified IT risk to the controls, owners and system components that address it.
We produce the configuration baselines, access listings, change records and log samples that management needs to evaluate design.
We walk your team through the evidence so internal staff can explain each control to the external auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the risk assessment stays current as systems change.
We can revisit the risk assessment when new financial systems, interfaces or privileged roles are introduced during the year.
Confirm with your auditor which evidence formats and sample sizes they expect before we finalize the evidence package.