Who should be accountable for broadening risk assessment beyond ICFR-only thinking?

Accountability for risk assessment when ICFR is too narrow

Broadening risk assessment beyond ICFR-only thinking is primarily an accountability question, not just a technical one. Management owns the assessment process and must make sure it reflects entity-level risk, disclosure risk, and control changes that affect financial reporting indirectly. Auditors have a duty to challenge whether the scope is too narrow, while audit committees should ask whether the process is actually fit for oversight rather than merely compliant in form. In practice, this gap is often discovered only after a control issue has already affected a disclosure or forced a late management review.

For a useful comparison point on broader control governance, NIST Cybersecurity Framework 2.0 is helpful because it treats governance, risk, and oversight as part of the operating model rather than a narrow control checklist. The question is not whether ICFR matters, but whether it is being used as a ceiling instead of a floor.

What broadening the assessment changes in practice

ICFR focuses on controls that materially affect the reliability of financial reporting, so it is naturally narrower than enterprise risk review. The practical shift is to look beyond direct ledger and disclosure controls and ask whether other risks can still change the control environment, management judgment, or the integrity of what gets reported. That includes significant process redesign, third-party dependencies, IT changes, policy exceptions, and contradictory external statements that may not break ICFR on their own but still signal a broader governance problem.

Management should treat this as a scoping discipline. If a risk can influence estimates, assumptions, disclosure completeness, or remediation timing, it should be visible somewhere in the assessment even when it does not map neatly to a control deficiency. Auditors, in turn, need to test whether management’s process captures those connections or whether it is overfitted to a checklist that only works for formal ICFR testing.

• Entity-level risks matter when they change how controls operate, not only when they fail a specific test.
• Control changes should be assessed for knock-on effects on disclosures, escalation paths, and management review.
• Board and committee oversight should focus on scope, not just the final risk register.

The NIST SP 800-53 Rev. 5 control catalog is a useful reference when the discussion moves from governance intent to control coverage, because it shows how risk assessment, monitoring, and control integrity are meant to work across a broader environment. This guidance breaks down when organisations treat risk assessment as a periodic documentation exercise instead of an active view of how the operating model changes.

Where accountability gets blurred and how to keep it clear

Broadening scope increases review effort, so organisations have to balance precision against fatigue and false escalation. The tradeoff is real: a wider assessment can create more findings, more judgment calls, and more cross-functional ownership questions, but narrowing too far leaves blind spots around disclosures, control design changes, and tone-at-the-top issues.

There is also a genuine consensus gap in practice about how far beyond ICFR the formal assessment should reach. Some organisations extend only to adjacent financial reporting impacts, while others build a more integrated enterprise-risk view. The defensible line is whichever approach still lets management explain why material non-ICFR risks would or would not affect reporting, controls, or investor understanding.

Accountability is clearest when each party has a distinct question to answer: management owns completeness, auditors own challenge, and audit committees own pressure-testing. That division matters because no single group can independently see all the ways a broader risk can become a reporting issue, especially when the signal is indirect or emerges through process change rather than a control failure.

Practitioners should treat any repeated mismatch between stated risk scope and actual review scope as a governance defect, not a terminology issue.

Risk and Threat Considerations

The material risk is under-scoping. When assessment stays ICFR-only, organisations can miss entity-level conditions that change how controls behave, how estimates are made, or whether disclosures remain complete and consistent. That creates a governance gap even when formal control tests continue to pass.

Failure mechanism: Narrow scoping filters out non-obvious inputs such as process redesign, contradictory public statements, third-party dependence, or management override signals. Those factors do not always appear as discrete control failures, but they can still alter control effectiveness, delay escalation, or distort disclosure decisions.

Impact: The organisation can end up with an assessment that looks compliant but fails to surface material reporting exposure, leaving management, auditors, and the audit committee with a delayed or incomplete view of risk.

Practitioner Guidance

What to prioritise: Start with the boundary question: identify which non-ICFR risks can still change reporting, disclosure, or control effectiveness. If the team cannot explain that boundary in plain language, the assessment scope is probably too narrow.

Decision rule: If a risk changes management judgment, escalation timing, or the reliability of disclosures, it belongs in the assessment conversation even when it is not a direct ICFR deficiency. If it cannot plausibly affect any of those outcomes, keep it out to avoid scope inflation.

What to verify: Verify that management can show how entity-level risks are reviewed, how contradictory statements are handled, and how control changes are evaluated for downstream effects. The audit committee should ask for examples, not just process descriptions.

Practitioner takeaway: The right accountability model is one where management owns breadth, auditors challenge blind spots, and the audit committee tests whether the process can actually see risk before it becomes a reporting problem.

Related resources from NHI Mgmt Group

• Who is accountable for reducing the risk of malicious code review and assessment campaigns against developers?
• Who is accountable for cross-application access risk when emergency access is extended beyond ERP?
• Why do misconfigured guest users create identity risk beyond data exposure?
• Why do MCP deployments create NHI risk beyond normal application security?