Reconciling Two Risk Registers After a Health System Merger

The scales cannot be converted by arithmetic. Both are ordinal; mapping 4x4 to 5x5 by multiplying by 1.25 produces numbers that look precise and are not comparable at the band edges, where decisions actually get made. Instead, publish one canonical enterprise 5x5 scale and a translation table anchored to the decision boundaries of the risk appetite statement (acceptable / tolerate with monitoring / escalate / unacceptable), not to the raw numbers. Each legacy scale keeps its own vocabulary for local use; every entry into the enterprise register carries the canonical band plus the original score and scale ID, so a clinician's 4x4 judgment is never silently reinterpreted.

Separate the three quantities. Record inherent risk, control effectiveness, and residual risk as distinct fields. Control effectiveness must be evidence-based (test result, monitoring data, audit finding) with a date and a source, not a self-assessment percentage. Residual is then derived from an approved rule set per risk category, and the derivation is stored, so an examiner can replay it. Aggregation rule: a service's rating is the maximum residual of its components, never an average, which otherwise hides a single unacceptable component.

Fix ownership at the service level, not the application level. 1,140 owners will never be maintained. Assign risk owners to roughly 40 business services; application owners report into them. This cuts the ownership gap from 38 percent of applications to a tractable number of accountable executives.

Stop the bypass with a fast lane, not a wall. A 20-minute online screen with five questions and automatic escalation triggers (patient data, external exposure, new vendor, payment data) lets clinical integrations proceed same-day with a recorded decision, while anything that trips a trigger goes to the ARB. Bypass happened because the ARB was slower than the business need; the fix is cycle time plus a documented, auditable exception path, and a standing report to the audit committee on exception volume and aging.

An attestation is an assertion about design and operating effectiveness at a point in time, signed by a named individual. The CISO cannot delegate the accountability and cannot hedge it in the press release afterwards. The decision therefore turns on one question: can I support each assertion in the required scope with evidence I would defend to an examiner and, if necessary, to a regulator's enforcement staff?

On the facts, three assertions fail that test. Thirty-eight percent of applications have no risk owner, meaning no one has accepted the residual risk for those systems; 62 projects went live without review, so the population of unreviewed changes is unknown and possibly larger; and control effectiveness is not recorded at all, so no assertion about operating effectiveness can be made.

Approach:

1. Quantify before refusing. Sample the unreviewed projects and the unowned applications, estimate the error and exposure rate, and document the method. A qualified position backed by a measured estimate is far stronger than 'we think it is bad'.
2. Read the attestation wording with legal. Many regulator forms permit a qualified submission with an exceptions schedule and a remediation plan. If so, sign qualified, attach the exceptions, and get the audit committee to acknowledge them in writing.
3. If the form admits no qualification, do not sign an unqualified statement. Escalate in writing to the CIO, the CEO, and the audit committee, stating exactly which assertions cannot be supported, what evidence would change the answer, and the earliest date it could be available. Record the escalation.
4. Ask for the risk acceptance in writing if the organization chooses to proceed anyway, signed at the level that owns enterprise risk, and confirm who is legally the signatory if that is not the CISO.

The professional obligation is not to refuse to help; it is to refuse to certify what is not true while making the path to a clean signature explicit and dated.

A useful indicator has four properties: it measures something the board actually cares about, it is computable from systems of record without a monthly manual exercise, it has a named owner who can move it, and crossing a threshold triggers a defined decision rather than a discussion.

Structure: for each appetite statement (for example, 'we accept limited risk of unauthorized disclosure of member data'), define a tolerance expressed in the same units the operating teams use, then two to three indicators per statement. Cap the total at roughly fifteen to twenty indicators; beyond that, nobody reads the pack.

Candidate indicators on these facts:

• Percentage of Tier-1 services with control effectiveness validated in the last 12 months (owner: control owners; red below 90 percent).
• Percentage of projects reaching production without ARB or fast-lane screening (owner: ARB chair; red above 2 percent).
• Open risk acceptances past their expiry date (owner: enterprise risk; red above zero).
• Mean days to remediate critical findings, and count of repeat findings on the same control (repeat findings indicate the fix was cosmetic).
• Percentage of applications with no assigned risk owner (owner: service owners; this should decline to zero within two quarters).
• For the merger specifically: number of systems still scored on the legacy 4x4 scale with no canonical mapping.

Thresholds to decision rights: green requires nothing; amber requires a documented plan and reporting at the next risk committee; red requires a decision at a defined level within a defined period, which is either remediation funding, a formal time-bound risk acceptance at the correct authority, or suspension of the activity. Publish the mapping. An indicator without an attached consequence is a dashboard ornament, and the board will discover that the first time a red indicator sits unchanged for three quarters.