Banks have been auditing risk management functions for decades. Cyber risk management is now mature enough to deserve the same treatment.
Early in my career I worked on bank audits at EY, in the era when the Federal Deposit Insurance Corporation Improvement Act was reshaping what those engagements looked like. FDICIA, through what is now 12 CFR Part 363, required management at covered institutions to report on the effectiveness of internal control over financial reporting, and required the independent accountant to attest to it.
That requirement pulled us somewhere auditors had not routinely gone. The allowance for loan losses was the most judgment-laden number on a bank's balance sheet, and the controls over it were not a matter of checking approval signatures. They ran through the entire credit risk management function: how loans were underwritten, how borrowers were risk-rated, how deteriorating credits were identified, how the resulting estimate was built and challenged.
So we audited the credit risk management program.
Notice what that did and did not mean. We did not form our own view of the bank's portfolio credit quality. That was not our job and we had no basis for it. We assessed whether the machinery the bank used to identify, measure, approve, monitor, and report credit risk was designed properly and working. We sampled loans, but as a test of the machinery rather than as an attempt to re-underwrite the book. If management had graded a deteriorating credit a 3 when the file supported a 6, that told us something about the rating process, which was the thing under review.
I have thought about that work often over the past few years, because a growing number of organizations now run a cyber risk management function that does structurally similar things, and too few are auditing it. I’ll share why auditors should be.
Imagine a credit auditor reporting this:
Finding: annual financial reviews were not completed for 7 of 50 loans tested. Severity: High.
Any competent credit risk organization would come back immediately. Which loans? What exposure? What risk grades? Seven missed reviews on seven small, well-secured, high-grade credits is not remotely the same problem as seven missed reviews on seven large deteriorating ones. The control failure rate does not tell you the risk.
Now the cyber version:
Finding: 7 of 50 privileged accounts were not recertified. Severity: High.
That report goes out routinely and rarely draws the same challenge. Not because the question is less relevant, but because in most organizations there has been nothing to answer it with.
That is changing. Where a cyber risk management function is running quantified analysis, the organization can state its exposure to a defined loss event in dollars, with documented assumptions and a range. Those numbers increasingly reach the board and inform budget decisions, risk acceptance, and materiality determinations.
Which raises the question this post is about. Who is auditing the function that produces them?
There is a framing problem that stops many audit functions before they start. Assessing the risk management program feels like audit stepping into risk management's territory, and auditors are rightly cautious about that.
The FAIR Controls Analytics Model (FAIR-CAM) resolves it. FAIR-CAM sorts controls by the mechanism through which they affect risk. Loss event controls act directly on the frequency or magnitude of loss. Variance management controls affect the reliability of other controls. Decision support controls affect decisions.
Risk analysis primarily sits in the third category. FAIR-CAM says so explicitly in its treatment of how variance corrections get selected and prioritized, noting that because selection and prioritization are acts of decision-making, that function is served primarily by decision support controls, with risk analysis and cost-benefit analysis given as the examples.
So the cyber risk management program is a control. Auditing it is auditing a control, which is the most ordinary thing an internal auditor does. There is no boundary being crossed.
It is also, arguably, the control with the widest reach in the organization. FAIR-CAM notes that decision support controls affect decisions about loss event controls, variance management controls, and other decision support controls. A deficiency there propagates into every subsequent control decision. Weak analysis produces misallocated budget, mispriced risk acceptance, and misdirected remediation, across the entire program, quietly.
The same was true of credit risk ratings. They fed monitoring intensity, provisioning, pricing, and portfolio limits. Getting them wrong was not a documentation problem. It was a solvency problem, eventually.
There is a second reason to care, and it is buried in the audit planning standards where it is easy to miss.
The Global Internal Audit Standards require the internal audit plan to rest on a documented assessment of the organization's strategies, objectives, and risks. The implementation guidance under Standard 9.4 then says the internal audit function should independently review and validate the key risks identified within the organization's risk management system, and that it should only rely on management's information about risks if it has concluded that the organization's risk management processes are effective.
Read that condition carefully. Audit may lean on management's risk information only after reaching a conclusion about the process that produced it.
This matters more than it sounds. Risk-based auditing depends on knowing what the risks are. If that knowledge comes from the organization's risk register and nobody has assessed whether the register is any good, the whole chain is resting on an unverified input. Auditing the risk management program is what earns audit the right to rely on its output.
Standard 9.5 fills in the other half. It requires the chief audit executive to coordinate with other assurance providers and consider relying on their work, and it names risk management among the internal providers. Its guidance lists creating a shared risk register or list of risks as an example of coordination, and it requires that any reliance be based on an evaluation of the provider's independence, competency, objectivity, and due professional care, documented, with the chief audit executive still answerable for the conclusions.
That is the right relationship. One shared inventory of risks, jointly maintained, which audit validates rather than duplicates.
Bank auditors developed a layered approach to credit risk management. The layers translate almost directly.
Governance and appetite. Credit auditors examine whether the board set credit risk appetite and limits, whether management operates within them, and whether breaches are escalated and reported. Concentration limits, single-obligor caps, loan-to-value floors.
The cyber parallel is risk thresholds and appetite. Standards such as ISO/IEC 27001:2022, NIST Cyber Security Framework 2.0, and our own FAIR Cyber Risk Management Program (FAIR-CRMP) standard require acceptable risk thresholds to be established and approved by the risk owners, meaning those accountable for the business assets or processes at stake. The board of directors must approve the organization’s risk appetite. Audit can test whether those thresholds exist, who approved them, whether they are expressed in terms that permit a yes or no answer, and whether exposures sitting above them are actually escalated.
Origination. Credit auditors sample loans and test whether they were underwritten, rated, approved, and documented according to standards. This is conventional control testing, but tied to a measurable underlying exposure.
The cyber parallel is scenario intake. How does a scenario get defined and admitted to the inventory? Is the scoping consistent? Does the organization's scenario taxonomy get applied, or does each analyst construct scenarios their own way? Inconsistent scenario definition is the cyber equivalent of inconsistent underwriting standards, and it produces the same result, which is a portfolio you cannot aggregate.
Risk ratings. This is the closest parallel and the most important one. Credit auditors independently review a sample of borrower files and compare their own assessment against management's assigned grade. Disagreement is a finding about the rating process.
Cyber auditors can do exactly this. Take a sample of completed cyber risk analyses. Re-examine the inputs. Are the frequency estimates supported by the data cited? Are the loss magnitude figures traceable to business input, or did somebody in security estimate them alone? Is the reasoning documented well enough that a competent analyst could reach the same range? Where audit's read differs materially from the analyst's, that is a finding about the estimation process.
Monitoring. Credit auditors test whether annual reviews happened, covenant violations were caught, collateral was revalued, and deteriorating credits moved onto the watch list promptly.
The cyber parallel is reassessment. FAIR-CRMP contemplates agreed reassessment intervals and business triggering events. Audit can test whether analyses are refreshed when the environment changes, or whether the number reported to the board this quarter rests on estimates made eighteen months and one acquisition ago.
Models. Banks depend on models, and internal audit assesses model risk management: conceptual soundness, data reliability, assumption support, back-testing, calibration, control over overrides, monitoring for drift, and whether independent validation occurred.
This layer is largely unexplored in cyber and it is where the most interesting work is. Is the simulation implemented correctly? Are the distributions appropriate to the data? Where do the frequency estimates come from, and are those sources suited to the question being asked? Are analysts calibrated, and has anyone tested them? Who can override an estimate, and is that governed?
The consequential decisions. Credit risk measurement drives loan pricing, limits, reserves, and capital. Auditors follow it through to those outcomes, because an allowance is not adequate merely because management followed a process.
The cyber parallel is whether the analysis actually drives anything. Does the budget reflect the exposures? Do risk acceptances cite thresholds? Does the materiality determination process for disclosure draw on the loss estimates? This layer matters because a decision support control that produces excellent information nobody acts on is not effective. FAIR-CAM makes this point directly, noting that even robust risk analysis may fail to prompt necessary action when incentives are misaligned.
I want to be careful not to oversell this, because the differences are real and a practitioner will raise them.
Credit risk arrives denominated in money. A loan has a principal balance. Exposure at default is largely a matter of record. In cyber, loss magnitude has to be constructed, scenario by scenario, with business input. It is harder, more contestable, and more dependent on judgment.
Back-testing is much harder. Banks observe defaults. They can compare predicted default rates against realized ones across thousands of loans and recalibrate. Cyber loss events are comparatively rare at the level of any single organization, and the counterfactual is unobservable. This is a genuine limitation on how far the model validation parallel can be pushed, and an auditor should not demand back-testing evidence that cannot reasonably exist. What can be assessed is whether the organization compares its estimates against realized incidents at all, and whether it revises when reality disagrees.
There is no regulatory scaffolding. Bank model risk management developed under supervisory expectations, with prescribed validation practices and examiners checking. Cyber risk quantification has nothing that’s quite the equivalent. Standards exist, but regulatory requirements are spotty at best. That means auditors have to establish criteria rather than inherit them.
Independence within the second line. In banks, credit risk management is structurally independent of loan origination. In cyber, the risk management function frequently reports to the CISO, who also owns the controls the analysis assesses. That means the function estimating control effectiveness may be assessing its own parent organization's work.
That last difference is not a reason to dismiss the parallel. It is a finding waiting to be written. It is also the single most useful thing internal audit can test, because the second line cannot independently verify its own control assumptions and audit can. Every FAIR analysis embeds them. This one assumed MFA is enforced on privileged accounts. That one assumed segmentation holds. Testing whether those assumptions survive contact with the environment is squarely third line work, and when they do not, the finding is not that a control failed. It is that the exposure figure reported to the board was built on an assumption that does not hold.
The Global Internal Audit Standard 13.4 requires auditors to identify the most relevant criteria for evaluating the activity under review, and to assess whether the board and senior management have established adequate criteria for judging whether the activity is meeting its objectives. If those criteria are adequate, auditors must use them. If not, auditors must identify appropriate criteria in discussion with the board or senior management.
Its guidance is pointed for our purposes. In assessing adequacy, auditors should consider whether the organization has developed and clearly articulated its risk tolerance, including materiality thresholds, and whether it has articulated a satisfactory level of control.
Where an organization has defined its own criteria for what its cyber risk management program should achieve, use them. Where it has not, the FAIR Cyber Risk Management Program standard offers a structure: agile governance, a risk-informed system, risk-based strategy and execution, and risk escalation and disclosure. It is not the only available structure, and I am not suggesting audit should hold organizations to conform with a standard they never adopted. But it describes what a functioning program consists of, which is what an auditor needs before assessing whether one exists.
Worth noting that FAIR-CRMP contemplates the audit role directly. It names internal audit among its intended audiences, and it places audit principles in three of its four components, including one on auditing against risk thresholds and one on auditing escalation and disclosure processes.
Some readers will get this far and think none of it applies, because their organization has no cyber risk management function to audit.
That is a finding, and it may be the most valuable one in this post.
The absence of a risk analysis capability is a missing control in the FAIR-CAM sense, and a missing control of the highest-leverage kind. Without it, nobody can say which controls are key, because a control is only key in relation to a risk. Nobody can say whether a given exposure falls within appetite, because appetite has not been expressed in terms anything can be compared against. And nobody, including internal audit, can honestly justify how assurance resources are allocated.
That last point makes the absence audit's problem specifically, not just management's. An auditor reporting it is not asking for a new capability out of professional preference. They are reporting that a condition their own standards assume is not present.
The thing I keep coming back to is that none of this requires inventing an audit approach. Bank auditors worked out how to audit a quantitative risk management function decades ago, under regulatory pressure, and the layers they settled on transfer with surprisingly little modification. Governance and limits. Intake standards. The ratings themselves. Ongoing monitoring. Models and their validation. Whether the output actually drives decisions.
Cyber risk management is now mature enough in a meaningful number of organizations to warrant the same scrutiny. In most of them it has never received any.
An open question I would put to readers who work in banking: Does your internal audit function actually use the quantitative credit information available to it when scoping engagements, selecting samples, and rating findings? Or does it fall back to control-centric auditing even with better information at hand? The answer would tell us a good deal about how far the cyber version of this can go, or what objections auditors might encounter.