Adopt v. Comply: The Difference Between Frameworks and Regulations

By: Josh Mayfield | 10/12/2018

Recent headlines would lead any rational person to conclude that topics like data security, data privacy, data breach, and ransomware would outrank seemingly solved problems, like compliance. But Google Analytics reveals that, in spite of the bleeding headlines, searches for IT compliance far outnumber the queries for more exciting noun phrases.

The statistician, Seth Stephens-Davidowitz has said, "Sometimes, statistical analysis is tricky. But other times, a finding just jumps off the page." When you try to discover which curiosities are pushing people to ask Dr. Google, you can see how Stephens-Davidowitz is spot on: IT compliance started high and hasn’t ceded its top spot in the last five years, while other ‘trends’ are lost in the noise. Yeah, that finding just jumps off the page.

To be sure, the concept of compliance is omnipresent in the collective minds of IT and security pros, but it is often applied broadly to include adopting frameworks, like NIST or CIS Critical Controls. This leads the uninitiated to assume that such security blueprints fall into the category of regulatory obedience. But there are no jackbooted regulators showing up to see if your awareness programs (CIS Critical Control #17) are satisfactory, for example. What do you do when your natural intuitions are in conflict with the real distinction between frameworks and regulations? 

Goal Orientation

The best way to understand the difference between a framework and a regulation is to think about the result you’re trying to accomplish. The compliance goal for both frameworks and regulations is the same: validate alignment. However, it is the ‘who’ you are trying to satisfy that becomes the pivotal point that separates compliance with frameworks versus compliance with regulations.

For regulations, you have authorities who want to ensure that you have everything buttoned down, airtight, and currently working to ensure data protection. That’s why regulations are written with binary stipulations, leaving little room for interpretation. By way of example, take the HIPAA Security Rule and its demand for a minimum of 128-bit encryption for PHI. Not much room for alternative facts here; you either have 128-bit encryption on PHI data or you don’t. This is what I mean by ‘binary’- a series of true/false assessments to determine if the current state of security is active as set out in the legal code.

When it comes to frameworks, the binding authority is ourselves. CIS, for example, does not employ prosecutors or civil rights investigators to put you under the microscope, testing you for a binary, true/false legal requirement. Instead, you satisfy your own cravings for strong cybersecurity by taking the framework’s map to your destination. There is a compliance element here, in the sense of ‘compliance’ that demonstrates an alignment, but in this, compliance is oriented around the general pattern of following practices rather than direct challenges to legal requirements.

To use an analogy from transportation, when cruising down the road in your automobile, you must obey laws that require certain behaviors: side of the road, posted speeds, etc. When you demonstrate your obedience to these laws, you are compliant with a regulation.

Within the confines of these requirements, your GPS is flashing the next turn, which is the faster route to the destination, and avoids any hazards. You don’t have to follow any of the GPS directions; they are simply there to give you a highly probable gateway to success for reaching your goal. To comply with such suggestions comes from your own self-interest, not to prevent citations and fees from the GPS Police.

Regulations are non-negotiable. You might get off with a warning, you may not see a fine. But those mercies do not absolve the reality that you stand in violation of current laws. Frameworks are guidelines, signposts, and nudges that come from historical and present-moment awareness of what one typically does to satisfy the goal of reaching the destination.

Top-Down, Bottom-Up

After you’ve come to grips with the goal-oriented differences with frameworks and regulations, you come to the inputs that feed into these structures. Frameworks are most effective when the practitioners are the authors of guidelines. After all, they have greater knowledge—much of it derived by trial and error—to use when fitting the guidelines to a specific discipline or best practice. Frameworks are bottom-up, not top-down.

The community itself is the mitigating factor. Which is one of the reasons you get a sense of hopeful anticipation when someone shares how their organization is adopting a framework, “We’re running a project right now to align with NIST 800. It’s gonna be tough, but I think we’ll be better for it.” The community has spoken, their judgment is trusted and the reaction to frameworks tends to reveal nodding heads and creative thinking about how to implement the framework within your personal context.

Regulations, on the other hand, are top-down impositions that spill out of the halls of legislative bodies. Though many legislators will convene hearings and panels to better understand the nature of an industry and its needs, the final product—codified regulations—are a standard to which each individual organization must conform, or pay the price.

Where frameworks tilt toward the conceptual ‘how,’ regulations are best understood as a list of ‘whats.’

To read more about the NIST Cybersecurity Framework, read Josh’s blog series. You can also learn more in his webinar with Forrester analyst, Renee Murphy in the webcast, Nailing It! 5 Ways to Win with the NIST Cybersecurity Framework.

Financial Services