The Equivalent Zone: Using FAIR-CAM to Defend a Control to Auditors
Most of the regulations and standards against which your security program is measured give you an option you probably aren't using: implement a different control from the one the rule names, and show that yours achieves the same thing.This is what we called the Equivalent Zone in previous blog post.
New York's cybersecurity regulation lets a CISO approve in writing the use of reasonably equivalent or more secure compensating controls in place of the prescribed multi-factor authentication. HIPAA's Security Rule marks some implementation specifications addressable, meaning you implement the specification, implement an equivalent alternative, or document why it isn't reasonable and appropriate for you. NIST SP 800-53 has compensating controls in its tailoring guidance. ISO/IEC 27001 asks you to justify which controls you've included and excluded in a Statement of Applicability. You get the point.
Regulators have been writing these options into the rules for decades, and they aren't hidden. In several cases, the regulator even supplies the form you fill out.
So how often does your team utilize equivalency when addressing a compliance requirement? And when relying on an equivalent control, does it save you money, time, and effort, or does it let you reduce more risk than the prescribed control does?
For a lot of teams the honest answer to the first question is never. The answer to the second is often both savings and risk reduction.
What you have to show
Every one of those mandates or standards asks the same question in different words. Does your control achieve what the prescribed control was meant to achieve?
Most of them stop there and leave you to work out for yourself what a good answer looks like. PCI DSS is the exception, which is the reason I'm using it as an example here. The PCI Security Standards Council (PCI SCC) publishes its templates, and in June 2026 it released guidance with completed examples. Everything here applies wherever one of these options exists.
See the completed PCI DSS Targeted Risk Analysis template starting on page 19 for the customized approach. Section 1.3 captures the “mischief” (fascinating choice of words here) the requirement was designed to prevent. Section 3 assesses the “changes to the LIKELIHOOD of the mischief occurring" and section 4 analyzes “any changes to the IMPACT of unauthorized access to account data."
An asset, a threat, a method, an effect, and then two questions about likelihood and impact. That's a risk scenario and a two-factor risk model, sitting inside a compliance form that thousands of security teams fill out every year.
So how do we answer it? Section 3.3 gives you three checkboxes: mischief more likely to occur, no change, and mischief less likely to occur. The PCI standard asks for a risk analysis and hands us a multiple-choice answer sheet.
Two options, and most teams know only one
As I noted in last week’s post, the June guidance from the PCI SCC makes a distinction about equivalent controls. It’s worth repeating here, because it applies well beyond PCI DSS.
One distinction is compensating controls: these exist for entities that are unable to meet a requirement as stated, and they require a legitimate, documented technical or business constraint (typically a legacy system or process that can't be updated). The other is the customized approach: it’s for entities that choose to meet the requirement differently because it’s better.
One is for when you can't. The other is for when you can do better. In my experience, most security teams only know the first one exists.
Look at what that costs us. The worked example from the guidance describes a facility where users authenticate by voiceprint rather than keyboard, every command is re-validated against the logged-in user's voiceprint, and the session ends when the user badges out of the area. PCI DSS requirement 8.2.8 calls for re-authentication after fifteen minutes of idle time. Under the defined approach the entity in the example fails because its system has no concept of an idle session at all. Under the customized approach, the entity argues the prescribed control gives a threat actor a fifteen-minute window against an unattended session, and theirs (authentication by voiceprint) reduces that window to zero. Arguably, their approach is better.
So there are two reasons to make an equivalence argument with a customized approach: control cost and control effectiveness. Let’s look at both.
Your control may be just as effective in meeting the control objective but cheaper to build and run than the prescribed one. Holding risk at the same level for less money is exactly the right call, in part because it frees up resources to be spent on other risk mitigation efforts. A mature program makes that call deliberately rather than defaulting into a more expensive option because a rule named it.
Keep this in mind when considering cost as justification: the guidance says plainly that the documentation and effort required to validate the customized approach will be greater than for the defined (standard) approach. In other words, your savings from employing the control should outweigh the cost of the additional paperwork.
Your control might act on the same risk factor (e.g., susceptibility) more strongly, the way validating a voiceprint on every command closes a window the prescribed control leaves open for fifteen minutes. It might also act on a factor the prescribed control doesn't touch at all. It might also work in parts of your environment where the prescribed control can't be deployed. Or it might also be better in ways that don't sound like security at first (less friction for the people using it, fewer moving parts, less dependence on a specialist who could leave, easier to scale as you add platforms).
FAIR-CAM adds another dimension to effectiveness
Control and risk assessments often fail to consider the reliability of controls over time. That’s where FAIR-CAM's variance management controls should enter your analysis.
FAIR-CAM treats a control's contribution to risk as a function of how reliably it operates, not simply how it was designed. Variance management controls are what maintain that reliability; they detect when a control drifts, fails, or gets bypassed, and they drive it back into an operating state. FAIR-CAM assumes every control depends on them to some degree, which means no control's real effect can be assessed without asking how its variance gets managed.
So the equivalence comparison has a second dimension, and most substitution arguments never reach it. Beyond asking whether your control acts on the same factor as strongly by design, ask which of the two can actually be kept working. If nobody can tell when the prescribed control has stopped working, and drift stays invisible until the next assessment, then its operational reliability is lower than an alternative that surfaces its own failures. That isn't a matter of preference. It's a difference in the protection each control delivers, and because FAIR-CAM builds variance management into the assessment of any control, it's a difference you can reason about and, with data, reflect in your estimates rather than assert.
The rule prescribes designed protection. What you actually need is delivered protection. A control nobody can maintain has a wide gap between the two.
Using FAIR-CAM to assess equivalency
Equivalency means that your control provides at least equivalent protection to the defined requirement. It isn't a test of whether your overall risk is low, and it isn't satisfied by showing that you take security seriously. It's a comparison between two specific controls, and to make it you have to show that yours acts on the same risk factor and addresses the same control objective.
FAIR-CAM sorts controls by the mechanism through which they affect risk. Loss event controls act directly on the frequency or magnitude of a loss event; variance management controls affect the reliability of other controls; decision support controls affect the quality of risk decisions. Within the loss event category, controls act on different factors (e.g., how often a threat makes contact, how readily that threat succeeds, what the loss costs once it happens).
Place the prescribed control in that structure and the equivalence question becomes answerable rather than rhetorical. Which factor was the original control moving? Does yours move the same one? By at least as much?
Notice that the PCI template already forces this distinction without telling you how to reason about it. In the voice authentication example the entity marks likelihood as decreased, then states plainly in section 4.2 that its controls provide no reduction to impact. That's correct. Voiceprint validation acts on susceptibility, not on loss magnitude. The form separates the two questions, and FAIR-CAM is what tells you which of your controls answers which.
Working the example
The compensating controls worksheet in the guidance shows that sorting in action. The requirement is 8.4.2, multi-factor authentication for all access into the cardholder data environment. The constraint is a vendor-supported legacy payment platform that can't integrate with modern MFA mechanisms and can't be modified without invalidating support.
The entity's package has five pieces. Access to the platform is restricted to dedicated administrative jump hosts. Those jump hosts require a unique ID, a password, and a FIPS-validated hardware token. Firewall rules technically prevent access from anywhere else. Sessions are logged to a SIEM and retained twelve months. Sessions are recorded through a PAM solution, and the SIEM alerts on unauthorized attempts and privilege escalation.
Sort those five by control function and the argument organizes itself, which is exactly the work the worksheet never asks you to do. MFA at the jump host and the firewall restriction act where the prescribed control acted, making unauthorized access harder to achieve, and that's your equivalence claim. Logging, session recording, and alerting don't prevent the event at all. They shorten the window between occurrence and detection, which acts on what the event costs, and that belongs in the section about additional risk rather than the section about meeting the objective.
Then look at how the worksheet closes that reasoning out: "Residual risk is assessed as Low." Two pages of specific, well-documented control description, and the conclusion is a rating.
Lessons to consider
Four things the guidance is firm about, and all four apply well beyond PCI.
First, this path assumes risk maturity. The PCI SSC recommends the customized approach for risk-mature entities with a real risk management capability, and says an organization that needs its auditor to design its customized controls may not be a good candidate for the approach at all.
Second, quantification helps but isn’t required. You don't need a full quantitative analysis to make most equivalence arguments. But notice that the strongest sentence in the entire worked example is the one that reaches for a number anyway: fifteen minutes becomes zero minutes. That's the sentence an auditor remembers. If you can say by how much, say by how much.
Third, none of this is a one-time exercise. Compensating controls get reviewed annually by both the entity and the auditor, who is checking whether they're still necessary as well as whether they still work. An equivalence argument that held up two years ago may fail today.
Fourth, incomplete documentation fails. If the auditor can't validate the control from what you gave them, the finding is Not in Place.
Applying the equivalent zone elsewhere
Strip the PCI DSS vocabulary away and this approach works everywhere the equivalent zone exists. NYDFS asks for reasonably equivalent or more secure access controls. HIPAA asks for an equivalent alternative that's reasonable and appropriate.
Every one of them is asking the same thing. Does your control act where the prescribed control acted, and does it act at least as strongly?
Many teams never get to make that case because they can't produce the analysis. With FAIR-CAM and the discipline of FAIR you can, quantitatively or not.


.jpg)

