Meeting Regulatory Requirements

Subscribe to our YouTube playlist Compliance and Regulations.

As a "Security Guy" who has to deal with this, as well as a "Governance Guy," it is amazing how many companies aspire to meet regulatory guidelines but have no understanding of what that means.

Much like the Jeffrey Epstein meme that disparages the attempted political manipulation of the term "underage women" when the actual wording that should be used is "children". Regulatory requirements are very similar: meeting them is not the same as doing an awesome job in security... more like making a 70% on a test and barely making the grade. Sure, you may have passed the test, but who spends all that time in school, learning, studying, only to want to achieve a 70%?

So, I will refer to 70% a bit in this article. In an environment where data protection is imperative, meeting minimum requirements is not enough, and more people need to understand that. For example, if you needed surgery (of any kind), would you want the Doctor who made a 70% on his tests or would you like the guy who made top scores? So, as a security guy, you should never allow the client or your company to settle for meeting regulatory requirements, believing they passed the regulatory test by 100%. Because they certainly wouldn't.

For example, in the security world, we often deal with encryption. So, let's say you have critical information (highly regulated) that is so critical that failure to protect it will lead to sanctions, negative publicity, and possible criminal negligence charges. So, "Bad things" would happen with an unknown level of how bad it would be...but most assuredly, something bad would happen as a result of that encryption failure. Your regulatory requirement to protect this information is that the data in transit must be encrypted. A proposed solution is to use TLS 1.2 (which is acceptable at the time of this writing), but should the technical security controls stop there? In my opinion, the answer is "no".

You see, in any environment (especially a regulated environment), you have different levels of risk. Of course, these are my interpretations of risk areas, and they are simplistic by design. Let's start with the most basic risk: technology. Technological risk is simple... if you want to connect two or more devices but fail to plug in the cables, you have a technological risk. Plug in the cable, and your technology risk goes away. Then, because you plugged the cable in, you have regulatory risk, or the risk associated with not meeting regulatory requirements, and whatever bad outcome could occur as a result of not meeting those requirements.

Above that, you have political risk. Political risk can vary greatly and, almost always, involves negative publicity. Negative publicity can lead to stock prices dropping, increased regulatory scrutiny, client departures, etc. The possibilities are endless. To address all areas of risk, we have the concept of best practices.

Best Practice is simply taking everything that should be done, then applying other controls to make it better. So, back to my example of using TLS 1.2, should that have been the only control in place to protect sensitive data? IMHO, it is not enough. For example, in this case, a VPN could be used to encapsulate TLS 1.2 traffic. VPN technology has been around for decades, and the underlying technologies (cell, Wi-Fi, etc.) easily enable the unfettered movement of personnel and assets. So, if you could add another security layer, why wouldn't you? Of course, you have to adequately plan for your security controls (such as allocating bandwidth for a VPN), so you don't overdo it and make it so people can't do their jobs.

So, to come back to the start, just meeting regulatory guidelines is not the same as true security.... if anything, meeting regulatory guidelines is almost proposing a false sense of security. A sense of security, where a 70% score (while still a passing score) is not the same as making 100% score when, in reality, 70% is pretty far from 100%.

Check out our platforms that help reduce effort and risk

Arrakis has built over several months numerous platforms that can help reduce risk. Read more here and those platforms are listed below.

- Compliance Chatbot - a free chatbot relating to compliance, cybersecurity, and privacy.
- Prosikon - A feature rich vendor due diligence platform to help increase visibility and provide more information for safer decisions. Read more here.
- PolicyForge - Build out your policies based on the regulatory environment you care about. Policy and Procedure Templates are included as well as control mapping. Read more here.
- Fortuna Risk Compass - Feature rich risk assessment platform that helps you visualize risk and cost better. Numerous graphical displays and ability to export risks to Prothesis. Read more here.
- Prothesis PoAM Builder - Build your PoAMs to prove you are mitigating risk and demonstrating maturity. Expands on Fortuna risks and demonstrates the "why" on the need for PoAMs. Read more here.
- Mutina SecurePath - Construct your SSPs to meet CMMC, or other frameworks, to provide assurance to external parties. SSPs are required for CMMC compliance. Read more here.
- CyberPrep Test Engine - A subscription based practice test platform covering 50+ certifications. Designed to be more difficult than the actual test to increase certification chances.

Regardless of the platforms, Arrakis suggests contracting professional consultation when seeking certification or compliance.