Cross-Functional Transformation Review
A fictional property insurer is a year into a program that put an AI assistant into claims intake. At the quarterly review, the program director presents to the CFO, the CISO, and the head of claims. Finance sees \$4.1 million spent against a \$4.5 million budget, 91 percent, and calls the program on budget. Security sees a 90-day exception for customer identifiers in prompts sent to a hosted model, already renewed once. The head of claims sees the assistant used on 31 percent of eligible intakes, while the business case assumed 70 percent. Every figure is correct. Each executive leaves believing the program is in a different state, and the meeting ends with an action to take the open items offline. The program then asks for a second tranche of \$1.2 million, and nobody in the room can say who decides it or on what evidence.
A review across finance, security, and the business has three jobs that no one function can do alone: decide whether to keep investing, decide which risks the organization will carry, and hold someone accountable for the use that produces the benefit. The three jobs are coupled. The investment case depends on adoption, adoption widens the data exposure, and the exposure decides how much remediation must be funded before the next tranche. Reporting them in separate lanes hides the coupling, which is where most of the decisions are.
Three accurate views of one program
Finance measures money against an authorization. Security measures exposure against control requirements. The business measures change in how work is done. Each measure answers its own question and says nothing about the others. Spending 91 percent of a budget shows that the authorization was respected, not that the money is producing anything. A count of closed security findings does not show whether the use that creates the exposure is worth continuing. An adoption rate carries no cost and no risk. A review that circulates the three measures side by side has produced a status report, not a decision.
NIST SP 800-39 describes information security risk management at three levels: the organization, its mission and business processes, and individual systems. It also describes a risk executive function, an individual or group that makes sure risk from individual systems is viewed from an organization-wide perspective, stays consistent with the organization’s risk tolerance, and is considered together with the other risks that affect its mission. The publication addresses information security risk in federal systems. The same arrangement can be applied to a transformation program, where the cross-functional review plays the part of a function that looks across the program’s cost, exposure, and results, because no individual system owner is placed to do so.
Investment: decide on the forward numbers
The program’s spending history explains how the money was used. It cannot decide the next dollar, because the sunk cost of the \$4.1 million is the same under every remaining option. The forward question is what each option adds in cost and benefit from here. The worked numbers below are hypothetical and exist to show the mechanics. Suppose the assistant is eligible for 480,000 claim intakes a year. Each assisted intake saves a net \$5.00 after the reviewer time that remains. The service costs \$550,000 a year to run (model use, monitoring, and support). At full adoption the gross saving is 480,000 × \$5.00 = \$2,400,000.
| Adoption of eligible intakes | Annual gross saving | Annual run cost | Annual net | Source of the figure |
|---|---|---|---|---|
| 70% | \$1,680,000 | \$550,000 | \$1,130,000 | Business case assumption |
| 31% | \$744,000 | \$550,000 | \$194,000 | Observed at month twelve |
| 22.9% | \$550,000 | \$550,000 | \$0 | Break-even: \$550,000 ÷ \$2,400,000 |
The program is not failing at 31 percent. It is above its running break-even, but it earns \$194,000 a year instead of the \$1,130,000 the case assumed, a gap of \$936,000 a year in gross saving. A finance partner who sees only the spend line cannot see that gap. The business case gave the savings an owner and a number, and the review should test that number the way benefits realization prescribes: against a baseline, using a measure whose definition has not changed. The article on adoption and work redesign covers why use of a new workflow has to be measured case by case rather than by who has access.
The second tranche is judged the same way. It would extend the assistant to a new intake type with 240,000 eligible cases a year and would add \$250,000 a year in run cost. Its gross saving at full adoption is 240,000 × \$5.00 = \$1,200,000 a year. Over three years the tranche must repay its \$1,200,000 and three years of run cost, \$750,000, a total of \$1,950,000. Dividing by the three-year gross saving at full adoption, \$3,600,000, gives a required adoption of 54.2 percent. At the 31 percent the first workflow achieved, the tranche ends three years \$834,000 short; at 70 percent it ends \$570,000 ahead (undiscounted, for simplicity). The request is therefore a claim that a new workflow will be adopted more widely than the proven one has been. The forum can examine that claim, ask what is different about the new intake type, and decide how much evidence it needs before releasing money. The article on budgets and total cost of ownership covers building run costs like these into the case from the start.
Finance’s contribution to this review is therefore less about holding the budget than about insisting that the case is restated from current evidence each time money is released. Savings enter the operating budget when they are observed, not when they are forecast. Releasing money in stages, each with a condition the next stage depends on, turns a large commitment into a series of decisions with an evidence requirement.
Risk: acceptance belongs to someone with the authority
The exception in the case covers customer identifiers inside prompts to a hosted model whose retention terms have not been verified. Security’s remediation estimate is \$350,000 and ten weeks for redaction and logging (hypothetical). The 90-day exception was approved by the claims department, renewed once, and covers the current 31 percent of intakes. Extending to the new intake type would send a different and larger body of data through the same path. A residual risk accepted for one scope does not carry over to another; a material change in scope, volume, or data calls for a new assessment before the earlier acceptance is relied on.
The practical question is who may accept what. The decision rights must name an executive with authority over the business outcome and the exposure that comes with it, within a delegation that states the limits. Security states the exposure plainly, advises on conditions, and escalates when the proposed acceptance is outside the delegation or the organization’s stated risk appetite. Security does not silently approve, and the business does not silently renew. NIST’s AI Risk Management Framework makes the same division in its GOVERN function: senior management declares risk tolerances and remains accountable for the AI portfolio, and roles are documented so that development is kept separate from testing and independent oversight. The article on assessing and accepting technology risk explains how an acceptance is routed and recorded; a vulnerability exception shows the fields a time-limited deferral needs, including scope, period, and the remediation plan it depends on.
A renewal is a new decision. In the case, the second 90 days passed by agreement at a meeting that had no record of what had changed since the first. The exception should expire on a date, carry the conditions under which it may continue, and appear in the risk register as a pending decision with an owner until it is either renewed deliberately or closed by verified remediation. A planned fix does not reduce the exposure until it is implemented and checked.
Adoption accountability
The program team built the assistant, so the review often asks the program director why only 31 percent of intakes use it. The director does not control whether intake supervisors tell their staff to use it, how reviewers are measured, or whether claims are routed to it by default. The accountable person is the owner of the claims intake process, who owns the benefit claim and the work redesign that makes the saving real. The platform owner answers for availability and the cost of running the service; the program director answers for delivery. The prerequisite article on data, platform, and AI ownership boundaries develops how these owners and their service contracts fit together; this review is where they sit at one table.
With the right person asked, the 31 percent becomes a diagnostic problem. The process owner can report adoption by region and intake channel, the share of assisted cases that reviewers corrected, and the reasons supervisors give for not routing work to the assistant. Those answers separate a readiness problem from a design problem and from a weak incentive. Tying the next tranche to the same measure the case used, case-level use of the assistant on eligible intakes, keeps the conversation on whether the work changed.
Forums: what each one decides
Review forums fail when they receive status and are asked for nothing. A forum is a standing governance body only if its mandate states which decisions are its own and which it only advises on. The forums in this program can be distinguished by the decision each one makes, who sits in it, and how often it needs to meet.
| Forum | Who decides | Decisions it owns | Evidence it needs | Cadence |
|---|---|---|---|---|
| Program review | Process owner, platform owner, program director, with finance and security partners | Sequencing, adoption actions, and exception renewals within the delegation | Adoption by region, run cost against plan, open exceptions with expiry dates | Monthly |
| Investment gate | CFO or delegate with the executive sponsor | Release, hold, or stop a tranche | Restated forward case, current adoption, verified conditions | At each stage gate |
| Risk acceptance | The accountable executive, with security advice | Accepting residual risk within appetite; setting conditions and expiry | Scenario, residual risk, remediation plan, change since last acceptance | When an exception is requested, changed, or expires |
| Executive committee and board | Executives; the board oversees | Exposure above delegation; strategic scope; oversight of the program’s results and risks | One page of exposure, results, decisions requested, and open tradeoffs | Quarterly, with escalation between meetings |
Each item on a forum agenda states the decision requested and who holds it. Items for which no decision is asked go into a report that is read before the meeting and are not presented. The pre-read arrives early enough for a security or finance partner to challenge a number before the room meets. Every decision goes in a decision record with its conditions and review date, and the request is structured the way the article on executive communication describes. Measuring decision latency, from the moment a request is ready to the moment the decision reaches the requester, shows whether the cadence suits the work. A quarterly investment gate is slow for an exception that expires in three weeks, so the program review holds delegated authority over it.
Unresolved tradeoffs stay on the page
Some tradeoffs cannot be settled at the meeting that finds them. In the case, \$0.4 million of the budget remains. Remediation takes \$350,000 of it and leaves \$50,000, while the tranche needs \$1.2 million of new money. Claims wants the new intake type quickly. Security does not want more data through an unremediated path. Finance does not want to fund an extension whose adoption case rests on a number the first workflow has not reached. Three options exist: fund remediation now and hold the tranche for evidence; release the tranche with the exception continuing under a narrower data scope; or start the new intake type using only redacted fields. Each option moves cost, risk, and time to a different party.
A tradeoff the forum cannot settle needs a record with six parts: the tradeoff stated as a choice, the options, the person who decides, the evidence that would settle it, the date by which it must be decided, and an interim rule for what happens if the date passes. The interim rule matters most. Without one, the status quo continues by default, which here means the exception renews itself. The record belongs with the other pending decisions in the risk register, and the same list goes forward to the next review, so that an open question is visible until it closes.
In the case, the forum decides what it can. It funds remediation from the remaining budget, because the exposure is its own and the work is overdue. It sets a gate for the tranche with two conditions: remediation verified, and adoption in the first workflow at or above 45 percent for two consecutive months. The 45 percent is a judgment rather than a calculated value. It sits about three-fifths of the way from today’s 31 percent to the 54.2 percent the tranche needs, and it shows the mechanism for increasing adoption is working before more money depends on it. At the gate, the break-even is recomputed with the observed adoption. The exception is renewed once more with a narrower data scope and expires at remediation verification.
What reaches executives and the board
The executive committee and the board have a different role from the program review. They do not make program decisions; they oversee whether the management structures that do are working and whether exposure stays within what the organization has agreed to carry. For a public company the oversight of cybersecurity risk is a disclosed item: SEC rules adopted in 2023 require registrants to describe the board’s oversight of risks from cybersecurity threats and management’s role in assessing and managing them. A transformation program that sends sensitive data through new AI services belongs in that route. Organizations not subject to the rule benefit from the same route for the same reason.
A one-page report from the cross-functional review can carry five things. The first is cumulative spend against authorization, together with the restated forward case and the next gate. The second is exposure: open exceptions with expiry dates, set against the stated appetite, with past-due items marked. The third is results against the case, adoption and realized benefit with definitions unchanged since the last report. The fourth is the decisions or escalations being requested. The fifth is the open tradeoffs, each with its owner and date. In the case, the first page of this report would show \$4.1 million of \$4.5 million spent, \$194,000 net annual benefit against \$1,130,000 assumed, one exception renewed with narrowed scope, and the tranche decision scheduled for the gate. An executive can ask what evidence would change the recommendation, a question the forum should be ready to answer.
Triggers for escalation between meetings belong in the mandate. An exception that is about to expire without a decision, net benefit that stays below break-even for two consecutive reviews, and a gate condition that is missed should each reach the executive committee when they occur, in the same format. Waiting for the next quarterly page converts a decision into a surprise.
The next review
At the next quarterly review the process owner, not the program director, presented adoption by region. Remediation had been funded and was under way. The tranche carried a written gate. The renewed exception had an expiry date and a named acceptor, and the open tradeoff was on the page with its interim rule. Adoption had not yet moved much. What had changed was that finance, security, and the business were looking at one set of numbers and could name who would decide the next step.
References
- NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, including the risk executive function.
- NIST AI RMF Playbook, GOVERN function, especially GOVERN 1.3, 2.1, and 2.3.
- SEC, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, final rule (Release No. 33-11216), Item 106 of Regulation S-K.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.
