In this final post of our three-party series, we’ll talk about how to optimize value, and not just risk, in the appetite-driven zone.
The first post in this series sorted security obligations into four zones of discretion, and the second worked through the equivalent zone where you can substitute a different control for the one a rule names. This post is about the fourth of those, the appetite-driven zone.
This fourth zone is arguably the biggest zone for most organizations. But it differs from the other three in a way that matters more than its size. In the first three, somebody outside the company set the objective, so the business's role really is to fund the work and sign. In the fourth, there is no external objective to meet. Most of a security budget sits there, and the standard for a good decision is entirely internal.
This raises the question of whose standard applies, and the name of the zone gives a misleadingly narrow answer.
Risk appetite is how much loss exposure a company is willing to carry, set as a threshold and approved (and owned) by whoever owns the asset at stake. It is a real and useful thing. A company that has never defined their risk appetite is missing a vital component of a properly defined enterprise or cyber risk management program, and getting those thresholds written down and owned is work worth doing.
But a risk threshold is a constraint rather than an objective, and no company has ever existed for the purpose of staying under some level of risk. The appetites that actually move a business forward are for other things entirely: for getting a product into the market before a competitor does; for running a process at lower cost than it ran last year; for customers who complete a purchase, are satisfied, come back, and recommend the product to others. Those are what business managers strive for. The risk threshold is a boundary drawn around the pursuit of them.
If you decide a question in this zone against the risk appetite alone, you are optimizing a constraint without considering the other side of the equation. The result is often an increase in business friction, because exposure always falls when a company does less. Ship less often. Collect less data. Ask customers for more proof of who they are before letting them spend money. These decisions move arguably risk in the right direction, but move the business backwards. Each can be defended on paper, even with a FAIR-based analysis.
Consider this control objective: keep sensitive data out of non-production environments. It’s usually a good idea: development and test systems get less scrutiny than production, they are copied freely, and oftentimes contractors or third-party developers have access to them. Loading them with sensitive data puts your business at risk.
There are ways to meet that control objective which starve the other business appetites: restrict who can request a copy; require approval; cut down on the number of dev and test environments; make developers wait for access; make vendors go through a lot of security hoops before onboarding. These work, in the sense that less data ends up in fewer non-production environments, but it’s paid for by slowing down developers and stifling innovation.
What if instead security and the development teams worked together on a solution? Might they come up with an alternative approach that could satisfy the control objective while improving developer productivity?
I worked for a company that offers a novel approach to do this, and the way they economically justify their solution is illustrative here. The company, Delphix (now part of Perforce Software), provides a platform that automates test data masking and provisioning for software development teams. As software vendors often do, they commissioned a study to demonstrate the benefits. In their case, IDC published a study in December 2024 based on interviews with ten different customers. From the analysis, the improvement in control is somewhat obvious: those organizations reported 77.2% more data and data environments were masked (i.e., sensitive data fields were altered or obscured to hide their true values) and therefore protected after adoption.
Just as importantly, the analysis showed that development teams became more efficient as a result of the solution. Application development was accelerated 58%; the time to stand up a testing environment fell from 25.8 days to 12.1; and the number of applications released each year rose 36 percent. Developers stopped queueing for masked data, so the control that protected the data also removed the wait. IDC was able to report the total benefits in dollars (at $7.15 million per organization per year), comprising development-related benefits, infrastructure cost reduction, revenue growth attributed to faster releases, and reduced security and compliance costs.
Interestingly, security was the smallest of the four categories, at roughly eight percent of the total benefit. But this is because security was measured based on cost reduction, not risk reduction. Risk reduction wasn’t assessed in the IDC study, likely because the studied companies didn’t have those numbers. Had they each performed quantitative risk analysis using FAIR, I am certain their benefits would’ve been much greater.
I’m not sharing this to make a case for Delphix’s product, and you don’t need to believe their numbers to understand the principle: sometimes, security solutions can improve outcomes other than cyber risk reduction. The study is a good example of assessing the non-risk benefits of a control. Companies that implement the usual approaches to protecting sensitive data in development and testing environments often fail to assess the impact on the business.
Too often, security picks a control, gets it funded, and mandates it on the business. Too often, failing to collaborate with business stakeholders results in risk reduction that comes at the expense of productivity, user experience, innovation, or something else that’s driving the business forward.
Collaborating at selection and design is a different activity, and a harder one. It means taking the objective to the business rather than the solution, and asking what else hurts in the same place. Where is this process already slow? What are we making people do twice? What would you fix here if security were not a consideration at all?
In my experience, the leaders who work this way often (but not always) come back with controls that lower exposure and improve something the business was already trying to improve. Those are not compromises struck between security and the business. They are better controls, and they are easier to fund, easier to operate, and far less likely to be quietly worked around by employees or customers. In other words, they reduce friction rather than increase it.
This is not merely a theoretical concern. Research has repeatedly found that security controls can impose meaningful friction on the business. A 2023 study of experienced CISOs and security consultants found that security managers themselves recognize security friction as a significant problem that can both reduce productivity and increase security risk. Subsequent research has documented these effects among employees and even measured the productivity consequences of more burdensome authentication controls. This is precisely the problem the appetite-driven zone is intended to expose: any reduction in risk must be weighed against its cost, including the operational friction it imposes on the business.
The payoff shows up when it is time to ask for money. What would have happened to a security leader who walked into that funding conversation carrying the $586,300 and nothing else? The request would have failed, and it would have deserved to, because the same control described completely returns four times its cost.
None of which is an argument against measuring risk. Quite the opposite. For most of this profession's history the exposure side was a color, and a color cannot be set against a budget, because one has units and the other does not. Risk managers who have learned and applied FAIR produce that number in dollars now, with a range and stated assumptions, and it turns up in real investment cases next to the cost of the control.
But a dollar figure on the exposure alone still speaks to only one appetite. It tells you what the company avoids rather than what it gains, and those are separate questions that get separate answers. The second half of the case lives with people who do not report to security: whoever owns release velocity, whoever owns unit cost, whoever owns the customers. For the study above it was an engineering leader. For a customer-facing control it would be whoever owns conversion and support volume.
The work worth doing, before the next funding request lands, is finding out what your organization is hungry for. What are its appetites beyond risk? Most risk functions can say something about the aversion, even if it is only a threshold nobody has revisited in two years. Far fewer can say what the company is trying to be fast at, where it is fighting for customers, which delays cost it real money, and which of those a control could plausibly move. Understanding this may take as much effort as the first, but it will be what sets your risk management approach apart from most others.
This analysis will not come out of a risk committee. It comes by collaborating with the people who own the revenue, the release schedule, and the support queue, and the conversation goes better before there is a specific control on the table to argue about.
Both appetites live in the fourth zone. A security leader who understands only one of them will often make decisions that are defensible in the risk register but wrong for the company.