The Fence in the Middle of the Road
Back in 1929, G.K. Chesterton described a scene that every GRC professional has lived through, whether they realized it or not. Picture two reformers walking down a country road when they come upon a fence built squarely across it. The first reformer says something to the effect of, “I don’t see the use of this. Let’s clear it away.” The second, wiser reformer replies that if he can’t see the use of it, he definitely shouldn’t be allowed to remove it. Go figure out why someone built it in the first place. Then, once you can explain its purpose, come back, and maybe we’ll talk about taking it down.
That little parable became known as Chesterton’s Fence, and I’d argue it belongs on a T-shirt because if you’ve spent any real time in the trenches of implementing NIST SP 800-171, CMMC, ISO 27001, or really any framework worth its salt, you’ve heard some version of the first reformer’s argument. “This requirement is dumb.” “FIPS validation on that box is pointless.” “Why do we need to review logs on a system nobody touches?” “Can’t we just get a waiver?”
Sometimes, the person saying it is even right! Some requirements really don’t fit certain environments, and here’s the part that might surprise you: the frameworks themselves often agree. Most mature frameworks have a built-in gate in the fence, a formal mechanism for varying from a requirement when you can justify it. The problem is that many reflexive pushback never gets anywhere near those mechanisms. It sometimes stops the expression “this is dumb” in frustration and never arrives at the better conclusion “here is why this requirement exists, why it doesn’t achieve its purpose in our environment, and the sanctioned path we’ll use to address that.”
So, in this blog, I want to give you a framework for pushing back on controls responsibly instead of reflexively. Along the way, we’ll untangle one of the most persistent misunderstandings in the Defense Industrial Base (the mythical “CMMC waiver” for individual controls), walk through the variance mechanism that actually exists under DFARS 252.204-7012, and look at how other frameworks like ISO 27001 institutionalized Chesterton’s Fence through the Statement of Applicability. Let’s take a stroll, shall we?
Why the Fence Isn’t Just for Looks
As said, before we talk about removing fences, we need to understand why they get built in the first place. Security requirements are almost never arbitrary. They’re usually downstream of one of three things: an incident that already happened to somebody, a threat model that somebody probably smarter than both of us spent months developing, or a legal and contractual obligation that flows from the sensitivity of the information involved based on the two other things.
Take the 110 security requirements in NIST SP 800-171. They weren’t invented from scratch. They were derived from FIPS 200 and the moderate baseline of NIST SP 800-53, then tailored specifically for the scenario of Controlled Unclassified Information (CUI) living on nonfederal systems. Every requirement in there traces back to a confidentiality protection objective. The discussion sections in the publication, and the assessment objectives in NIST SP 800-171A, exist precisely so you can trace that lineage. The fence has a blueprint, and the blueprint is public. In fact, one of my favorite underused habits for GRC practitioners is the following: When a requirement feels pointless, read the discussion text and other guidance (even if it’s not authoritative) to help answer the question “what is the specific risk that this requirement exists to mitigate?”. Most of the time, the “pointless” requirement suddenly makes perfect sense once you understand the attack it’s designed to frustrate. The rest of the time, you’ve now earned the right to have the conversation.
And that’s really the heart of Chesterton’s point. He wasn’t saying fences can never come down. He was saying that the ability to articulate why the fence exists is the price of admission to the conversation about removing it. Reflexive pushback skips the admission fee. Responsible pushback pays it gladly, because paying it usually makes your case stronger, not weaker. It’s just like the old proverb, “Desire without knowledge is not good, and whoever makes haste with his feet misses his way”.
“Just Get a Waiver” and Other Countryside Legends
Now let’s talk about most misunderstanding in the DIB. A contractor hits a requirement that’s genuinely painful in their environment, and someone in the room says, “We’ll just get a waiver for that control.” And that may sound like an actual possibility seeing as the word waiver is thrown around all the time and it’s mentioned within the respective regulations. But I need to be the bearer of some clarifying news: there is no such thing as a contractor-requested waiver for an individual CMMC security requirement. That mechanism does not exist, and believing it does can put your assessment, and your contract eligibility, at risk.
Waivers do appear in the CMMC Program rule, but they live somewhere most contractors never look: on the government’s side of the fence. Under 32 CFR 170.5(d), in very limited circumstances, a Service Acquisition Executive or Component Acquisition Executive in the DoD may elect to waive the inclusion of CMMC Program requirements in a solicitation or contract. Read that carefully. The waiver applies to a procurement, it’s requested and approved entirely within the DoD, and it’s reserved for situations like mission-critical operations that can’t absorb a delay. And even then, the rule is explicit that contractors remain obligated to comply with all applicable cybersecurity and information security requirements. A CMMC waiver is not a hall pass for your organization, and it is definitely not something you can request for that one pesky control in the Audit and Accountability family.
“But Steven, I’ve definitely heard people says that they’ve gotten approval to vary from individual 800-171 requirements based on their circumstances. Are you telling me that’s all folklore?” I’m glad you asked! No, it’s not folklore. It’s just a different gate in the fence, with a different name, a different owner, and a much more rigorous toll.
The Gate the DoD Actually Built: CIO Adjudication
The real mechanism lives in DFARS 252.204-7012(b)(2)(ii)(B), and it’s been sitting there since before CMMC was a twinkle in the DoD’s eye. Under that clause, a contractor may submit a request to vary from a NIST SP 800-171 security requirement, in writing, to the Contracting Officer, for consideration by the DoD CIO. If an authorized representative of the DoD CIO adjudicates the requirement as not applicable to your environment, or agrees that you’ve implemented an alternative but equally effective security measure, you’re not required to implement the requirement as written. Its companion provision, DFARS 252.204-7008, covers the same concept at the proposal stage before award.
Notice what this process demands of you. You don’t get to declare a requirement inapplicable yourself, and you don’t get to decide unilaterally that your alternative is “just as good.” You have to make the case, in writing, to the entity that built the fence, and they decide. It is Chesterton’s Fence rendered into federal acquisition language: articulate the purpose, demonstrate how your situation relates to that purpose, and let the fence’s owner adjudicate.
And here’s where it connects beautifully to CMMC. Under 32 CFR 170.24, if you previously received a favorable adjudication from the DoD CIO, that adjudication must be included in your System Security Plan (SSP) to receive consideration during an assessment. A requirement covered by an equally effective alternative that the DoD CIO blessed is assessed as MET, provided there have been no changes in your environment since the adjudication. The CMMC rule also recognizes enduring exceptions for special circumstances where full compliance isn’t feasible, think medical devices, test equipment, and systems that must replicate fielded configurations. When those are described in the SSP along with any mitigations, they’re assessed as MET too. Temporary shortfalls, by contrast, belong in an operational plan of action, which is a bridge to compliance rather than an exit from it. Notice the pattern in every one of these mechanisms. The relief is only as good as the documentation behind it.
ISO 27001: Chesterton’s Fence with a Signature Line
Chesterton’s principle for control implementation variances isn’t just locked in to NIST SP 800-171 implementation. Other frameworks also have a great track record of granting flexibility for organizations where the letter of the law for a certain security control doesn’t seem to fit all that nicely. For example, ISO 27001 has an incredibly straightforward approach to variance without even having to go through some hierarchical approval process.
Here’s how it works. The 93 controls in Annex A of ISO 27001:2022 are not a mandatory checklist. They function as a reference set. Under clause 6.1.3 of the standard, your organization determines the controls necessary to treat the risks you’ve identified, then compares your list against Annex A to verify you haven’t overlooked anything necessary. The output is the Statement of Applicability (SoA), and this is the part I love: the SoA must contain your necessary controls with justification for their inclusion, their implementation status, and, critically, justification for excluding any Annex A control you’ve deemed unnecessary.
Sit with that for a second. ISO 27001 doesn’t just permit you to take down a fence. It requires you to write down why the fence isn’t needed on your property, and your certification auditor will read that justification and test whether it holds up against your actual risk assessment. “We didn’t feel like it; gone fishin’” ain’t gunna cut it, pal. Something like, “We do not develop software, therefore the secure coding control does not apply to any risk in our register” has a way better shot of being defensible. The standard literally will not let you be the first reformer in Chesterton’s story. Every exclusion must come with an articulated purpose and a reasoned dismissal of it.
Other Pastures, Same Principle
Once you start looking for it, you’ll find this pattern nearly everywhere. The HIPAA Security Rule labels many of its implementation specifications as “addressable” rather than required. Contrary to popular belief, addressable does not mean optional. Under 45 CFR 164.306(d), a covered entity must assess whether the specification is reasonable and appropriate for its environment, and if it decides not to implement it as written, it must document why and implement an equivalent alternative measure where reasonable and appropriate. Sound familiar? Articulate the purpose, justify the departure, document the alternative.
Side Note: If implemented as is, the HIPAA Security Rule’s Notice of Proposed Rulemaking (NPRM) would remove the “addressable” terminology since covered entities were frequently misunderstanding controls in the “Addressable” category as being “Optional”. However, the Proposed Rule would still allow for documented exceptions and alternative measures through compensating controls. The need write down a legitimate justification for an exception to the letter of the law and the implementation of an appropriate alternative approach does not change, even under the NPRM.
PCI DSS does the same dance with compensating controls, and its newer customized approach goes further by letting mature organizations meet a control’s stated objective through different means, backed by a documented targeted risk analysis.
The lesson across all of them is consistent: mature frameworks expect that some fences won’t fit every field.
How to Take Down a Fence Responsibly
So how do you actually do this well? Whether you’re a DIB contractor staring down a genuinely inapplicable 800-171 requirement, or an ISMS owner scoping your SoA, here’s the framework I recommend.
Pointer #1: Articulate the fence’s purpose before you argue against it. Read the requirement’s discussion text, its assessment objectives, and the threat it addresses. Write one sentence: “This requirement exists to prevent X.” If you can’t write that sentence, you’re not ready to push back, and honestly, you’re not ready to implement it well either.
Pointer #2: Check whether the framework already has a gate. Before inventing your own exception, find the sanctioned mechanism. For DFARS 7012, that’s a written variance request through your Contracting Officer for DoD CIO adjudication. For ISO 27001, it’s a justified exclusion in your SoA. For HIPAA, it’s the addressable specification analysis. Using the built-in gate keeps you defensible. Don’t be climbing over the fence at night. That’s trespassing!
Pointer #3: Write the justification like an assessor will read it, because one will. Whether it’s a C3PAO assessor checking your SSP for that DoD CIO adjudication or a certification body auditor probing your Annex A exclusions, assume a skeptical professional will test your reasoning against your actual environment. “Not applicable” claims backed by nothing are among the fastest ways to erode an assessor’s trust in other things you’ve documented. And that’s if you even get to those other things since you’ll probably have such significant issues with the underwhelming “N/A” justifications and it’ll just stall your assessment out. I’ve seen similar things happen. It’s not pretty.
Pointer #4: Route the decision to the fence’s actual owner. Your CISO cannot waive a DFARS clause, and your MSP definitely can’t. Only the DoD CIO can adjudicate a variance from 800-171 under 7012. Conversely, for your own ISMS, your governance body genuinely is the owner, so use your risk acceptance and SoA processes with confidence. Knowing who holds the deed to each fence is half the battle. Leadership has to be involved in making informed decisions on which fence to tear down.
Closing the Gate Behind Us
At the end of the day, Chesterton wasn’t anti-reform, and I’m certainly not anti-pushback. Some of the best security programs I’ve seen had alternative implementations, Enduring Exceptions, Specialized Assets, and different risk-based approaches to implementation. But there’s a world of difference between the reformer who says “this is dumb, remove it” and the one who says “I understand exactly what this fence was built to keep in/out, here’s why it doesn’t serve that purpose in our pasture, and here’s the formal gate we’ll walk through to address it.” The first gets ignored, or worse, gets a negative result during an audit or assessment, but the second earns adjudications, clean SoAs, and the respect of their assessor.
If your organization is wrestling with a requirement that doesn’t seem to fit, deciding whether a variance request is worth pursuing, or building out a Statement of Applicability that can survive an auditor’s scrutiny, we’d love to help. At IntelliGRC, we spend our days helping organizations navigate exactly these judgment calls across CMMC, NIST SP 800-171, ISO 27001, and beyond. Feel free to reach out through our contact form at https://intelligrc.com/contact-us or shoot us an email at sales@intelligrc.com.
As always, Happy Implementing!
Steven Molter
Lead GRC Consultant and GRC Evangelist at IntelliGRC. Connect with me on LinkedIn if you want to keep the conversation going!
Key Takeaways
- Chesterton’s Fence teaches that the ability to articulate why a requirement exists is the price of admission to arguing against it. Reflexive pushback skips that step; responsible pushback starts with it.
- There is no contractor-requested waiver for individual CMMC security requirements. CMMC waivers under 32 CFR 170.5(d) apply to solicitations and contracts, are approved by DoD acquisition executives, and are reserved for very limited circumstances.
- The real relief mechanism for individual requirements is the DoD CIO adjudication process under DFARS 252.204-7012(b)(2)(ii)(B): a written variance request, through your Contracting Officer, arguing non-applicability or an alternative but equally effective measure.
- Under 32 CFR 170.24, favorable adjudications must appear in your SSP and are assessed as MET absent environmental changes. Enduring exceptions, documented with mitigations in the SSP, are assessed as MET as well.
- ISO 27001 institutionalizes the same principle through the Statement of Applicability: Annex A controls can be excluded, but every exclusion requires a documented justification that your auditor will test.
- HIPAA’s addressable specifications and PCI DSS’s compensating controls and customized approach follow the same pattern: departures are allowed, undocumented departures are not.
Frequently Asked Questions
What is Chesterton’s Fence?
Chesterton’s Fence is a principle drawn from G.K. Chesterton’s 1929 book The Thing. It holds that you shouldn’t remove a fence (or a rule, or a security control) until you understand why it was put there in the first place. In GRC, it means articulating a requirement’s purpose before arguing that it doesn’t apply to you. Being able to do so may actually inform you as to the actual applicability of the requirement in your system.
Can a contractor get a waiver for a specific CMMC control?
No. There is no mechanism for a contractor to request a waiver of an individual CMMC security requirement. Waivers under 32 CFR 170.5(d) are decisions made within the DoD by Service or Component Acquisition Executives to omit CMMC Program requirements from a specific solicitation or contract, and they’re reserved for very limited circumstances. Even when a waiver applies, contractors remain obligated to comply with applicable cybersecurity requirements.
How do I request a variance from a NIST SP 800-171 requirement?
Under DFARS 252.204-7012(b)(2)(ii)(B), you submit the request in writing to your Contracting Officer for consideration by the DoD CIO. The request must explain why the requirement is not applicable to your environment or how an alternative security measure is equally effective. If adjudicated favorably, keep the adjudication on hand and document it in your SSP for the relevant requirement(s).
How are DoD CIO adjudications treated in a CMMC assessment?
Under 32 CFR 170.24, a favorable DoD CIO adjudication must be included in the System Security Plan to receive consideration during an assessment. A requirement covered by an adjudicated equally effective alternative implementation or variance is assessed as MET if there have been no changes in the environment since the adjudication.
Can I exclude ISO 27001 Annex A controls?
Yes, with justification. Annex A functions as a reference set rather than a mandatory checklist. Clause 6.1.3 requires you to compare your necessary controls against Annex A and produce a Statement of Applicability documenting included controls, their implementation status, and a justification for every exclusion. Your certification auditor will evaluate whether those justifications hold up against your risk assessment.
Does “addressable” mean optional under the HIPAA Security Rule?
No. Under 45 CFR 164.306(d), an addressable implementation specification must be assessed for whether it’s reasonable and appropriate for your environment. If you choose not to implement it as written, you must document why and implement an equivalent alternative measure where reasonable and appropriate.