Notifications
Clear all
Topic starter
25/06/2026 1:00 am
TL;DR: ICFR turns financial reporting accuracy into a control discipline, tying transaction approval, evidence retention, and governance to frameworks such as SOX and COSO, according to Pathlock. The lesson for identity teams is that access, privileged change, and audit evidence now sit inside the same assurance chain as the numbers themselves.
NHIMG editorial — based on content published by Pathlock: Internal Controls over Financial Reporting and related governance guidance
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams govern access in ICFR-controlled finance workflows?
A: Security teams should treat finance approvals, postings, and exceptions as identity-governed actions.
Q: Why do service accounts create ICFR risk in finance systems?
A: Service accounts create risk when they can post, approve, or alter financial data outside the same review expected of human users.
Q: What breaks when evidence for financial controls is incomplete?
A: When evidence is incomplete, auditors cannot verify that controls operated as intended, even if the process looked correct in the moment.
Practitioner guidance
- Map financial control points to governed identities Inventory every approval, adjustment, and posting path in finance systems, then identify the human, privileged, and service identities that can act in each path.
- Add identity evidence to ICFR testing Require audit-ready logs, approval records, and change history for each control objective.
- Review privileged finance access on a fixed cycle Re-certify finance administrators, ERP superusers, and service accounts that can post or approve transactions.
What's in the full article
Pathlock's full article covers the operational detail this post intentionally leaves for the source:
- The full ICFR breakdown of control objectives across authorisation, evidence, and reporting accuracy.
- The regional regulatory examples for the US, UK, Canada, Australia, and the Middle East.
- The COSO component-level explanation of control environment, risk assessment, and monitoring.
- The internal audit discussion on testing methods, remediation, and audit committee oversight.
👉 Read Pathlock's full ICFR guide and regulatory breakdown →
ICFR and identity governance: what IAM teams need to watch?
Explore further
25/06/2026 10:08 am
ICFR is increasingly an identity governance problem, not just a finance control problem. The article frames financial reporting as a control environment that depends on authorisation, evidence, and oversight. That is structurally the same governance pattern used in IAM, PAM, and NHI programmes when access creates financial or operational risk. Practitioners should therefore treat financial reporting controls as part of the wider identity assurance model.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when ICFR failures involve access and system controls?
A: Accountability sits with the control owner, but it is shared across finance, IT, and identity governance when access enables the failure. Boards and audit committees need a clear line of sight to who approved the control design, who operated it, and who verified its effectiveness. Without that chain, remediation is too easy to defer.
👉 Read our full editorial: ICFR shows why identity controls now sit inside financial reporting
