First of three posts on how much discretion your obligations actually give you. Most security teams treat obligations as mandatory, without considering the options that many allow.
A finding lands on your desk. Maybe it came from internal audit, maybe from a regulatory examination, maybe from the assessor who just finished your SOC 2 or your PCI work. Watch what too often happens next. Somebody gets assigned as owner, a remediation date gets negotiated, and from then on the only question anyone asks is whether it will close on time.
Notice the two questions nobody asked. Are we actually required to do this? And is it worth doing?
The finding arrived carrying a due date and no price. On the way in it also picked up a status that nobody stated and nobody tested, which is that the work is required.
Most of it isn't, and the parts that are aren't required in the same way. Because we often treat obligations (i.e., regulatory requirements, standards, contracts, etc.) as a single undifferentiated block, we can't prioritize, since a due date isn't a priority. We also almost never use the flexibility written into the rules themselves, because we have no idea which obligations carry any.
So before you read further, answer the question in the title for your own program. What percentage of what you're doing is mandated by something outside your organization? I would argue that most security leaders guess high, and that the guess is the real finding, because they aren’t using a decision model that determines the optionality of their obligations. The result may be an excessive cybersecurity burden on your business or a misallocation of resources.
The thing that differs across obligations isn't how important the control is. It's what kind of argument the obligation will accept.
Some accept no argument at all. Some will accept an argument that you've achieved the same objective a different way. Some will accept an argument about the level of risk you face. And a large share of your program isn’t dictated by mandates. Call those four zones Verbatim, Equivalent, Risk Proportional, and Appetite Driven. The first three are mandatory and differ only in how much latitude the obligation hands you; the fourth isn't mandatory at all; and they run as a gradient, so one obligation will often put different requirements in different zones.
Knowing which zone you're standing in tells you what latitude (options) you have.
Interestingly, much of the friction security teams feel with auditors or regulators comes from assuming they have latitude they do not actually have.
Some obligations name a control and offer no alternative, such as breach notification deadlines, statutory prohibitions, and consent orders. PCI DSS Requirement 3.3.1 prohibits storing sensitive authentication data after authorization even when it's encrypted, and the only carve-out runs to issuers and the firms that support issuing services. If you're a merchant, there's no argument to make.
Contracts belong here too. Your customer and data processing agreements are frequently stricter than any regulation that applies to you, and they contain no risk-based escape. Clearing a regulatory analysis is no defense against a master services agreement that somebody in sales signed two years ago without asking you.
Risk quantification earns its keep in this zone not by getting you out of anything. Instead, it tells you what order to do mandatory work in; it helps you choose among implementations that are all compliant but differ in cost and effect; and it lets you tell the business the business impact of not complying (should you choose).
Here the obligation names a control but will accept an alternative that achieves the same objective. This is the zone many practitioners understand least and use least, and therefore leave money on the table.
The New York Department of Financial Services gives the clearest example. Section 500.12(b) of its cybersecurity regulation says a covered entity's CISO may approve in writing the use of "reasonably equivalent or more secure compensating controls" in place of multi-factor authentication, subject to review at least annually. That door has been written into the text of the rule since 2017. One precondition is easy to miss: the path is open only to entities that have a CISO.
PCI DSS gives you two mechanisms, and practitioners blur them constantly. One mechanism, compensating controls, requires a documented technical or business constraint, which means you're asserting you can't meet the requirement as written. The other mechanism, the customized approach, requires no constraint at all, only the supporting apparatus (e.g., a targeted risk analysis, a controls matrix, executive sign-off, an assessment producing a Report on Compliance). The PCI Security Standards Council published dedicated guidance on the difference in June 2026.
HIPAA's Security Rule splits implementation specifications into required and addressable, and addressable has never meant optional. It means you implement the specification, implement an equivalent alternative, or document why the specification isn't reasonable and appropriate for your environment. That distinction may not survive: HHS has proposed eliminating it, with a projected final action date of July 2027. The healthcare sector is fighting to keep this distinction (i.e., the optionality) in place, but many of its members have never actually taken advantage of it.
These options very often sit unused for a reason, and it isn't that they're hard to find. Instead, it means making an equivalence argument rather than an exposure argument, and most teams bring the second when the rule is asking for the first. Your alternative has to achieve the objective the rule set. Whether your overall risk is low has nothing to do with it, and neither does the fact that you've mitigated the loss (say, via cyberinsurance).
We’ll explore the equivalence zone more in the next post of this series. In particular, we’ll look at what has to be in the assessment and how FAIR-CAM can help.
Some obligations don't name a control at all. They tell you to be appropriate, reasonable, or proportionate, and they leave the determination to you. Here the level of risk isn't a supporting argument. It's the entire argument, and your analysis is the compliance artifact.
ISO/IEC 27001 is the anchor. Annex A is a reference set of controls rather than a mandate, and clause 6.1.3 requires a Statement of Applicability justifying which controls you've included and excluded on the basis of your risk treatment. An auditor who writes a finding because an Annex A control is absent has treated a menu as a checklist, and the standard is on your side.
European regulation states the principle more directly than anything in US law. NIS2 Article 21 requires appropriate and proportionate measures, weighed against the state of the art and the cost of implementation, with proportionality judged by the entity's exposure, its size, and the likelihood and severity of incidents. DORA Article 4 says much the same for financial entities, scaled to size, overall risk profile, and the nature, scale, and complexity of operations.
SOC 2 sits here as well; the trust services criteria describe outcomes, and you select the controls and defend the selection.
Underneath all of this sits a legal standard most security leaders never think about in these terms. Where liability turns on reasonableness, the test is already quantitative. Judge Learned Hand's formulation in United States v. Carroll Towing Co., 159 F.2d 169 (2d Cir. 1947), holds that conduct is negligent where the burden of precaution is less than the probability of loss multiplied by the magnitude of that loss. In other words, the cost of the control is compared to the loss magnitude (LM) times the loss event frequency (LEF).
That's a risk model, it predates FAIR by seventy years, and it's the framework a court will apply to the decisions you made. Which raises an uncomfortable question. If that's the language you'll be judged in, why are so many risk leaders still supporting their decisions with red, yellow, and green risk ratings?
Zone 4 is the largest part of your program and the least examined.
Above the mandated floor, nobody outside your organization has an opinion about what you do — not a regulator, not an auditor, not a contract. You and your business partners set the objective, the standard is your organization’s risk appetite, and the decision needs a named risk owner and a defined risk threshold rather than a security team's judgment alone. ISO/IEC 27001 clause 6.1.3 says as much, requiring risk owners to approve the treatment plan and accept residual risks against criteria set under 6.1.2. This is where marginal returns govern, and it's where quantification gets used least and is worth most.
The third post in this series will discuss the economics of the appetite-driven zone.
Take your open audit findings and sort them into the first three zones. How much of what you treat as mandatory turns out not to be? How many equivalence paths exist in rules you're already subject to that nobody has ever walked through? Where could you safely push back to free up resources that could be used elsewhere?
Then consider the basis you use to allocate the largest share of your budget, all of it sitting in the zone where the only appetite that governs is your own. Can you justify your investments based on the risks they address?
I don't expect the sorting to be comfortable. Most security programs can demonstrate that a control exists and can't demonstrate what it's worth. The danger is that cybersecurity costs too much or, perhaps worse, that investments are being misallocated, leaving some overfunded at the expense of others.