Shadow AI: The Risk Hiding in Your Company
Eighty percent of workers say AI has made them more productive. Only 37% of their employers can point to a single euro of it on the bottom line. Those two numbers come from the same study, McKinsey's State of AI 2026, fielded between May and June 2026 across 1,719 respondents in 97 countries. The gap between them is not a measurement error. It is a description of where the value is going, and it is not going to the company.
That gap has a name. It is called shadow AI: the artificial intelligence your people use every day that your organization did not approve, does not know about, cannot see, and therefore cannot secure, improve, or scale. Shadow AI management best practices are not a compliance nicety for large enterprises. They are the difference between a company whose employees are quietly getting faster and a company that actually gets faster.
I want to be blunt about the framing, because most coverage of this topic gets it backwards. Shadow AI is usually written up as a security scare story. The security exposure is real and I will put hard numbers on it below. But treating shadow AI purely as a threat leads to the single worst response available, which is a ban, and a ban makes the problem invisible rather than absent. The more useful reading is that shadow AI is the highest quality market research your company will ever receive for free. Your people have already told you which processes are broken. They voted with their own time and, in many cases, their own credit cards.
What Shadow AI Actually Is
Shadow AI is the use of artificial intelligence tools inside a company without the knowledge or approval of the people accountable for security, data protection, and technology decisions.
It is the direct descendant of shadow IT, the phenomenon of employees signing up for Dropbox and Slack and Trello a decade before the IT department did. But three properties make it materially more dangerous than its predecessor.
The barrier to entry is zero. Shadow IT required at least a signup form and often a corporate card. Shadow AI requires opening a browser tab. There is no procurement trail, no invoice, no line in an expense report to audit.
The data leaves in the payload, not the account. When an employee used unapproved file storage, the risk was where the file sat. With shadow AI the risk is what gets typed into the prompt: the customer list, the unreleased financials, the draft contract, the source code, the patient record. The exposure happens at the moment of use, not at the moment of storage.
It looks like nothing. A person pasting a contract into a chatbot on a second monitor is indistinguishable from a person reading a contract. There is no observable behavior to notice.
The scale question
The most widely cited number on employee-supplied AI comes from Microsoft and LinkedIn's 2024 Work Trend Index, which found that 78% of AI users bring their own tools to work. The figure rose to 80% at small and medium-sized companies and 85% among the youngest cohort of workers. That data is from 2024 and I flag the vintage deliberately, because everything about AI usage has moved since. But note the direction of the error: in 2024, using AI at work was still slightly transgressive. Two years later it is ordinary. If the number was wrong, it was wrong on the low side.
Cross-reference it against the McKinsey finding and the picture resolves. Eight in ten individuals report a productivity gain. Under four in ten organizations report a financial one. Employees are not lying about the gain. The gain is real, it is just landing in a place the company cannot reach: in individual output, on individual accounts, using individual prompts that nobody else in the building will ever see or reuse.
What Shadow AI Actually Costs
Now the security half, with numbers from a primary source rather than a vendor blog.
IBM's 2025 Cost of a Data Breach Report, conducted with the Ponemon Institute across 600 organizations, found the following:
A high level of shadow AI added USD 670,000 to the average cost of a breach. Not the total cost. The premium, on top of a global average that stood at USD 4.44 million.
97% of breached organizations that suffered an AI-related security incident said they lacked proper AI access controls. Ninety-seven percent. When a statistic gets that close to a ceiling it usually means the thing being measured is not a risk factor but a precondition.
63% of organizations reported having no AI governance policies at all, whether to manage sanctioned AI or to prevent shadow AI. Nearly two-thirds of companies are running with no rules of any kind.
13% of surveyed organizations experienced an attack that impacted their AI models or applications. IBM's own commentary calls that share small for now, and expects it to grow.
One more data point for the trajectory. The same report noted that global average breach costs fell 9% year over year, from USD 4.88 million to USD 4.44 million, driven by faster containment through AI-assisted defense, with mean time to identify and contain at 241 days, the lowest in nine years. IBM's subsequent 2026 report puts the global average back up at USD 4.99 million, with AI-driven attacks up 56%. The dip was temporary. The defenders got a one-year head start and the attackers took it back.
What I would flag about how this data gets quoted
You will find articles claiming that 20% of all breaches are caused by shadow AI. That number is not in IBM's own write-up of the finding, and I could not source it to the primary report. I have left it out. If you are building a business case for AI governance spending, build it on the USD 670,000 premium and the 97% access-control figure, both of which are directly attributable, because the first executive who checks your source will find the same gap I did.
The Four Kinds of Shadow AI
Lumping all of this together as "people using ChatGPT" produces bad policy. There are four distinct categories and they need different responses.
Category one: consumer chatbots handling company data. The employee opens a general-purpose assistant on a personal account and pastes in work material to summarize, rewrite, analyze, or debug. This is the largest category by volume and the easiest to address, because the same capability is available in a governed form for a modest per-seat cost.
Category two: embedded assistants and browser extensions. Meeting note takers that join calls, writing assistants inside the browser, sales tools that read the inbox. These are more dangerous than category one because they operate continuously and with broad permissions, and because the employee installs them once and then forgets they exist. A note taker sitting in your board meeting is a category all of its own.
Category three: personal API keys and self-built tools. A technically capable employee wires a model into a script, a spreadsheet, or a small internal tool, paying with a personal card. This category produces real business value, sometimes considerable, and creates a single point of failure attached to one person's private account. When they leave, it breaks, and nobody knows why.
Category four: AI features that appeared inside software you already approved. This is the one that catches governance teams flat. Vendors ship AI capability into existing products by default. Your data is now going somewhere new under a contract you signed before that destination existed. Nobody did anything wrong and your data map is out of date anyway.
Category four is why an approved-tools list is not a control. The list can be perfectly accurate and completely misleading at the same time.
Why Banning Shadow AI Fails
Most companies' first instinct is prohibition. It is a reasonable instinct and it does not work. Three reasons.
It does not reduce use, it reduces reporting. The employee who was using an assistant on the work laptop now uses it on a personal phone. Consumption is unchanged, visibility is gone, and you have converted a manageable problem into an unmeasurable one. You have also guaranteed that the day someone pastes something they should not have, they will not tell you.
It taxes exactly the people you cannot afford to lose. The employees experimenting with new tools are, as a rule, your most motivated. A blanket ban tells the most engaged fraction of your workforce that initiative is a disciplinary matter. Some of them will comply. Some of them will leave.
It confuses the tool with the behavior. The risk is not that an employee used a language model. The risk is that a specific class of data went to a specific destination under specific terms. A policy written against tools has to be rewritten every quarter as new tools appear. A policy written against data classes stays valid.
There is a fourth reason, less discussed and more important. A ban throws away the information. Every instance of shadow AI is a signal saying "this task is painful enough that I solved it myself, unpaid, in my own time." That is a prioritized backlog of internal friction, compiled by the people who actually do the work, at zero cost to you. Prohibition is the only response that destroys the signal without capturing the value.
Shadow AI Management Best Practices
Here is what actually works, in the order I would sequence it. This section is the heart of the article, and I have deliberately put governance last rather than first, because governance written before you know what people are doing governs the wrong things.
One: measure before you legislate. Spend two weeks finding out what is actually in use before writing a single rule. Every policy written from imagination regulates hypothetical behavior and misses the real thing. Detection methods are in the next section.
Two: provide a sanctioned alternative first, on the same day the rule lands. This is the non-negotiable one. A restriction announced without a replacement is a productivity cut, and your people will experience it as one, correctly. Enterprise-grade AI access costs a fraction of the fully loaded cost of the employee using it. If you cannot fund a seat for everyone, fund it for the functions with the highest exposure and say openly that the rest is coming.
Three: classify data, not tools. Write three tiers. Public material that can go anywhere. Internal material that can go to approved tools only. Restricted material, meaning customer personal data, financials before release, credentials, source code, legal matters, and health data, which goes to nothing outside your controlled environment, ever, no exceptions, no manager override. Three tiers is the maximum a person will remember. Five tiers is a document nobody reads.
Four: make the rule fit on one page and pass the corridor test. If an employee cannot state the rule accurately from memory while walking to a meeting, the rule does not exist operationally regardless of what your intranet contains. Length is not rigor. Length is avoidance of the hard work of deciding.
Five: run an amnesty. Announce a fixed window, typically thirty days, in which anyone can register a tool they are already using with no consequence whatsoever. Say plainly that the purpose is visibility, not discipline, and then honor that absolutely. The first person punished for an amnesty disclosure ends the program permanently and poisons the next three initiatives you attempt. I have watched exactly this happen.
Six: give approval a deadline. The single largest driver of shadow AI is not defiance, it is latency. If the sanctioned path takes six weeks and the unsanctioned path takes six seconds, you have designed the outcome. Commit publicly to a decision window, five working days is achievable for low-risk categories, and publish your record against it. A governance function that misses its own deadlines has forfeited the authority to complain about workarounds.
Seven: train on judgment, not on prohibition. The useful training is not a list of banned products. It is the ability to answer, unprompted, three questions: what class is this data, where is it going, and what happens if it appears publicly tomorrow. That is a fifteen minute conversation repeated quarterly, not an annual e-learning module. I have written about the structure of this at length in the AI training playbook for employees.
Eight: put a named owner on it. Not a committee. A person with a name, a mandate, and dedicated time. Shadow AI sits across security, legal, IT, and operations, which in most organizations means it belongs to nobody and each function assumes another is handling it. If nobody in your building can be named as accountable for this within ten seconds, it is unowned, and unowned means unmanaged.
Nine: harvest what you find. Every registered tool goes on a list with the problem it solves and the hours it saves. Review the list monthly. The items appearing repeatedly across teams are your automation roadmap, pre-validated by real users. This step is where the money is, and it is the step almost everyone skips because it belongs to no existing job description.
The broader operating model these practices fit into is covered in my guide to AI governance for business, which goes deeper on committee structure, risk tiering, and documentation than I can here.
How to Detect Shadow AI Without Buying Anything
You do not need a discovery product to get a usable picture. Five methods, in ascending order of effort.
Network and DNS logs. Your existing egress logging already knows which domains company devices reach. Pull ninety days, filter for known AI service domains, and rank by unique user count rather than total requests. Unique users tells you how widespread a practice is. Total requests tells you how loud one enthusiast is. You want the first number.
Browser extension inventory. If you manage devices at all, you can enumerate installed extensions. This surfaces category two, the continuously running assistants, which is the category most likely to be genuinely surprising. Expect to find at least one meeting recorder nobody authorized.
Expense report text search. Search reimbursements for the names of major AI vendors and for the small recurring amounts characteristic of individual subscriptions. This finds category three, the people who cared enough to pay. Treat every hit as a recruitment lead for your internal AI working group, not as a violation.
SaaS admin consoles. Go through the settings of every major platform you already run and list the AI features that have been enabled, by default or by an administrator, along with where the processing happens. This is the only reliable way to find category four, and it is manual, and it is worth the afternoon.
Ask people. Underrated to the point of absurdity. An anonymous four question survey, asking what AI tools they use, what for, what it saves them, and what would make them switch to a sanctioned option, will typically outperform your technical discovery by a wide margin. It also produces the answer to the only question that matters for policy design, which is why.
Run all five. Each finds a category the others miss, and the disagreement between methods is itself informative: a tool that shows in DNS but not in the survey is one people are not comfortable admitting to.
What a Usable AI Policy Looks Like
Structure, since the content is yours to determine.
Section one, the three data tiers, with five to eight concrete examples each drawn from your actual business. Not abstract categories. Real document types your people handle on a Tuesday.
Section two, the approved tools, with what each is for and, critically, a live link to the current list rather than a list embedded in the document. The embedded list is stale within a month and its staleness discredits the whole policy.
Section three, how to get something approved, with the actual form, the actual owner's name, and the committed turnaround time in working days.
Section four, what to do after a mistake. State explicitly that self-reporting a data exposure within twenty-four hours is not a disciplinary event. This clause does more for your real security posture than the rest of the document combined, because the average time between an accidental paste and its discovery by anyone else is measured in months, and the only reliable early warning system you have is a person willing to raise their hand.
Section five, what happens if you ignore this. Brief, proportionate, and honest. Most companies either omit consequences entirely, which signals the policy is decorative, or threaten termination for everything, which signals the same thing by a different route.
Five sections. One page, two at the outside. If your draft is running to twelve pages, you are writing to protect the drafter rather than to change behavior.
If you are reading this and recognizing that your organization has none of these five sections in place, the gap is not unusual. IBM measured it at 63% of companies having nothing at all. But the absence is now expensive in a way it was not two years ago, and closing it is a matter of weeks rather than quarters when someone with a clear picture of the failure modes is driving.
Self-Assessment: The Shadow AI Exposure Scorecard
Score one point per true statement. This measures exposure and readiness, not sophistication.
Visibility
- We have pulled network or DNS logs for AI service domains in the last ninety days.
- We know, approximately, what share of our staff uses AI weekly.
- We have inventoried AI features enabled inside SaaS platforms we already pay for.
- We know which employees pay for AI tools personally.
Provision
- Every employee who wants governed AI access can get it.
- The sanctioned tool is genuinely competitive with the consumer alternative, not a degraded internal version.
- Access is provisioned in under five working days.
Rules
- A written AI policy exists and is under three pages.
- It classifies data rather than listing banned products.
- A random employee could state the restricted-data rule correctly from memory.
- Self-reporting a mistake is documented as non-punitive.
Ownership
- One named person is accountable for AI usage governance.
- That person has dedicated time for it, not just the title.
- There is a defined route to request a new tool, and it publishes its response times.
Capture
- We maintain a list of what employees use AI for, reviewed at least quarterly.
Reading the score
Thirteen to fifteen: you are managing this. Move to optimization and to the capture question.
Nine to twelve: solid foundation with specific gaps. Close the visibility items first, since everything downstream depends on knowing what is actually happening.
Five to eight: you have policy without visibility, or visibility without provision. This is the most common position and also the most fragile, because it produces the appearance of control. Work through the ninety day plan below in sequence.
Below five: you are fully exposed and, more importantly, you are leaving the productivity gain on the table entirely. This is not primarily a security emergency, it is a value capture failure that also happens to carry a USD 670,000 tail risk. Start at day one.
The 30, 60, 90 Day Plan
Calibrated for an organization between fifty and a thousand people.
Days 1 to 30: See it
Week 1. Name the owner and give them explicit time. Convene one meeting with security, legal, IT, and one operational leader who actually runs a team. Agree on a single objective for the quarter and write it down as a number.
Week 2. Run the five detection methods in parallel. Pull the logs, inventory the extensions, search the expenses, audit the SaaS consoles, launch the anonymous survey. All five, same fortnight.
Week 3. Consolidate into one inventory: tool, category one through four, estimated users, data classes likely involved, business problem being solved. That last column is the one that will matter in six months, so do not let it be left blank.
Week 4. Rank by exposure, which is data sensitivity multiplied by user count, not by how alarming the tool sounds. Present the top ten to leadership with the estimated hours saved beside the estimated risk. Both columns. A risk register without the value column produces a ban, and you have already read why that fails.
Days 31 to 60: Provide and permit
Week 5. Procure governed access to the highest-value category one capability. Speed matters more than optimal selection here. A good tool available in week five beats the perfect tool available in month five, because the alternative is not "nothing", it is "the consumer version, on a personal account, indefinitely."
Week 6. Write the one-page policy using the five-section structure. Have three people outside the drafting group read it and state the restricted-data rule back from memory. If any of the three cannot, it is too long. Rewrite, do not append.
Week 7. Launch the amnesty and the policy on the same day, in that order in the announcement. Amnesty first, rules second. Leaders should register their own tools publicly and go first, which is the only part of this that cannot be delegated.
Week 8. Deliver the judgment-based training. Fifteen minutes per team, live, with real examples from your own inventory. Not a recorded module. The value is in the questions people ask when a peer is in the room.
Days 61 to 90: Capture and prove
Week 9 and 10. Work the amnesty registrations. Approve fast, migrate what should move to sanctioned tools, decommission what genuinely cannot be allowed, and in that last case explain the reasoning to the person individually rather than by broadcast.
Week 11. Build the harvest list. Cluster the registered use cases by the problem they solve. The clusters with three or more independent instances across different teams are your automation candidates, and they arrive pre-validated by people who chose to use them without being asked.
Week 12. Measure against week 3 and report. Registered tools, share of staff on sanctioned access, restricted-data incidents self-reported, hours saved on the top three clusters. Publish the numbers internally even where they are unflattering, because the credibility of the second cycle depends entirely on the honesty of the first.
At day 90 you will not have eliminated shadow AI. That is not the goal and any plan promising it is selling something. You will have converted an invisible liability into a visible, ranked, partly monetized asset, which is the achievable outcome. The adoption mechanics that follow from here are covered in the enterprise AI adoption framework.
Four Cases From the Field
Different sectors, same underlying lesson. All anonymized by industry.
A sports distribution company. The starting problem was not framed as shadow AI at all. Sales and marketing were operating on separate data with no shared view of the customer, and individuals had begun patching the gap with their own tools and their own spreadsheets. We unified the data foundation first and built segmentation on top of it. Sales grew 30%. The relevant detail for this article is that the individual workarounds had been running for months and had been correctly identifying the right problem the whole time. Nobody had asked.
A hotel. Revenue was flat around 9 million. The property management system was in place and functioning, but nobody was reading occupancy against booking channel, and the pricing decisions that mattered were being made on instinct with private side-calculations. We restructured the reporting and the dynamic pricing policy. Revenue moved to 10 million with no additional rooms. The private side-calculations were the signal that the official reporting was not answering the question people actually had.
A medical center. The bottleneck was scheduling and the handling of cancellations. Staff had built their own informal recovery processes because the system did not support one. We formalized and rebuilt the booking and slot-recovery flow. Delivered capacity rose 20% with no new equipment and no additional clinicians.
An agritourism business. Small operation, no structured systems at all, everything running on individual initiative and personal tools. Here the sequence mattered more than anywhere else: we defined the guest acquisition and management process first, then selected the minimum tooling that supported it. Guests doubled.
The common thread across all four is that the unofficial tooling was diagnostically correct and organizationally invisible. In each case the people doing the work had already located the constraint. The gain came from noticing, not from discovering.
If any of that pattern recognition feels close to home, the useful next step is usually a short structured look at where your own unofficial tooling is concentrated, because that map tends to be quicker to produce and more decision-ready than a full technology assessment, and it costs a fraction of what a misdirected platform purchase costs.
What Shadow AI Is Telling You
Return to the two numbers from the opening, because the whole argument rests on them.
Eighty percent of individuals report a productivity gain. Thirty-seven percent of organizations report an EBIT contribution, unchanged year over year despite substantially more scaling and more investment. McKinsey's own reading is that the constraint is organizational rather than technological: the high performers, still just 6% of respondents, are distinguished by fundamentally redesigning workflows rather than layering AI onto existing ones. Nearly three quarters of that group report such redesigns, against roughly a quarter of everyone else.
Shadow AI is what the 80% looks like from the inside when the organization has not done the redesign. The productivity is real. It is trapped at the level of the individual, unshared, unmeasured, and unreproducible, because there is no mechanism by which one person's prompt becomes another person's process.
That reframes the work. The question is not "how do we stop this." It is "how do we make what these people discovered available to everyone else." Those are different projects with different owners, different budgets, and different outcomes. The first one produces a policy document. The second one produces the EBIT line that 63% of companies are currently missing.
It also explains why the security-only framing underperforms. Run this purely as a risk programme and you will spend real money to arrive at a slightly smaller version of your current position. Run it as a value capture programme with a risk floor and the same spend produces both. The 30-60-90 plan above is deliberately sequenced to make the second outcome the default, which is why week 11 exists at all.
The change management dimension of that transition, which is where most of these programmes actually stall, is covered separately in my AI change management framework.
Where the Regulation Is Going
Two things worth tracking without letting either drive your timeline.
The first is that AI-specific obligations are arriving unevenly across jurisdictions, with the European framework furthest along. The practical consequence for shadow AI is narrow but real: obligations attach to systems you are deemed to be using, and "an employee was doing it on a personal account" is not a defense that has performed well historically in adjacent areas of data protection law. Your inventory is the artifact that makes any of this answerable.
The second is that the contractual surface is moving faster than the statutory one. The AI features vendors are enabling by default inside existing products are changing where your data is processed under agreements signed before those features existed. Category four is a contract management problem more than a technology problem, and the review cycle that catches it is the annual vendor review, not the security scan.
My working advice: do not wait for regulatory clarity to build the inventory, because the inventory is what you will need regardless of how the rules land, and it is useful on its own terms the day it exists.
What to Do Monday Morning
Three actions, in order, none requiring a budget approval.
Pull ninety days of DNS logs and count unique users per AI domain. Not total requests. Unique users. That single number is the most honest measure of how widespread this already is inside your company, and it usually surprises the person who requested it. It takes an analyst an afternoon.
Ask four questions, anonymously. What AI tools do you use for work, what do you use them for, roughly how much time does it save you, and what would make you switch to a company-provided option. Four questions, anonymous, one week open. The fourth question is the one that writes your provisioning strategy for you.
Name the owner. Before any of the rest. If you finish reading this and cannot say who in your organization is accountable for AI usage, that is the finding, and it is the only one that blocks everything else. Everything above is executable in ninety days by someone with a mandate. None of it happens without one.
If after those three steps the picture looks bigger than a policy problem, that is usually the correct reading rather than an overreaction, and it is the point at which an outside view of what to sequence first tends to pay for itself several times over. The companies that get this right are not the ones with the strictest rules. They are the ones that noticed earliest what their own people had already figured out.
FAQ
What is shadow AI in simple terms?
Shadow AI is any use of artificial intelligence tools inside a company that the organization has not approved and does not know about. In practice it usually means employees using consumer chatbots on personal accounts for work tasks, installing AI browser extensions or meeting note takers, or wiring model APIs into their own scripts with a personal credit card. It also includes AI features that software vendors have switched on inside products the company already licenses, which is the category most organizations miss entirely because nobody did anything unauthorized. The defining characteristic is not the tool, it is the absence of visibility.
What are shadow AI management best practices?
Measure before you legislate, and spend the first two weeks finding out what is actually in use. Provide a sanctioned alternative on the same day any restriction lands, because a rule without a replacement is a productivity cut. Classify data into three tiers rather than maintaining a list of banned tools, since data classes stay stable while tools change quarterly. Keep the policy to one page that a person can recall from memory. Run a genuine amnesty for existing tools and honor it absolutely. Commit to a published approval turnaround, since latency is what causes workarounds. Name one accountable owner with real time allocated. Then harvest what you find, because the recurring use cases are a pre-validated automation roadmap.
How much does shadow AI actually cost a company?
IBM's 2025 Cost of a Data Breach Report, run with the Ponemon Institute across 600 organizations, found that a high level of shadow AI added USD 670,000 to the average breach cost, on top of a global average of USD 4.44 million. The same study found that 97% of breached organizations that had an AI-related security incident lacked proper AI access controls, and that 63% of organizations had no AI governance policies of any kind. There is a second and larger cost that does not appear on any incident report: the productivity gain that stays trapped with individuals. McKinsey found 80% of workers reporting personal productivity improvements against only 37% of organizations reporting any EBIT contribution.
Should we just ban AI tools at work?
No, and the reason is practical rather than philosophical. A ban does not reduce usage, it relocates it to personal devices where you cannot see it, which converts a manageable problem into an unmeasurable one. It also guarantees that nobody will report a mistake, and self-reporting is the only early warning system that works, since accidental data exposure is otherwise typically discovered months later or never. A ban additionally penalizes your most motivated employees and destroys the diagnostic signal about which internal processes are broken. Provide a governed alternative and write the rule against data classes instead.
How do we detect shadow AI without buying a new tool?
Five methods, all using what you already have. Pull ninety days of network or DNS logs and rank AI service domains by unique users rather than total requests. Inventory browser extensions on managed devices, which surfaces the continuously running assistants and meeting recorders. Text-search expense reports for AI vendor names and small recurring charges. Manually audit the settings of major SaaS platforms you already run to find AI features enabled by default. Then run an anonymous four-question survey, which routinely outperforms the technical methods and is the only one that tells you why people chose what they chose. Run all five, since each finds a category the others miss.
Where do we start if we have nothing in place?
Name an accountable owner first, since nothing else proceeds without one. Then pull the DNS logs and count unique users per AI domain, which takes an analyst one afternoon and gives you the honest scale of the problem. Then run the anonymous survey. Those three steps take under two weeks, require no budget approval, and produce the inventory that every subsequent decision depends on. Do not write the policy first: a policy drafted before you know what people are actually doing will regulate hypothetical behavior and miss the real exposure.
Is shadow AI a security problem or a productivity problem?
Both, and treating it as only the first is the common mistake. The security exposure is documented and quantified. But the framing that produces better outcomes is that every instance of shadow AI is an employee telling you, at their own expense and on their own time, that a specific task was painful enough to solve unilaterally. That is a prioritized list of internal friction compiled by the people closest to the work. Companies that run this purely as a risk programme spend real money to end up marginally safer. Companies that run it as value capture with a security floor get both outcomes for the same budget.