[5 min read]
Customers see a lot of confusing terms when they are looking at building a security program. Terms such as “regulatory compliance”, “security frameworks”, “Information Security Standards”, and “Security controls”. Of all the buzz words we hear these days “regulatory compliance” is a phrase that comes up frequently. But before we can talk about regulatory compliance we need to understand the words that are being used and define a regulation vs. framework vs. standard. So let’s delve into the nuts and bolts of the compliance industry with some basic background to help get properly established from the ground up.
Regulations, Frameworks, and Standards - what’s the difference?
As a basic overview we can differentiate Regulations, Frameworks, and Standards as follows:
A regulation is typically drawn up by elected lawmakers who are not usually industry experts. They are often broad and general in their scope. For example, the HIPAA Security rule requires organizations to “...train all workforce members regarding its security policies and procedures” but does not specify how often or to what extent, thus leaving a lot of room for interpretation. Regulatory compliance is the requirement to operate in line with a specific set of regulations, else face a consequence.
Regulations typically have a legal component that may lead to fines and even prosecution if the regulations are broken. For example, GDPR is a regulation, and companies who are found to be in breach of GDPR regulations can be fined by the governing body of each country in the European Union. Computer Weekly recently wrote about the dramatic increase in GDPR fines in 2020 as European regulators become more serious about enforcement.
A framework is a generic term for a collection of regulations or guidelines. Information security frameworks are typically a collection of industry best practices put together by a particular entity. They are not usually legally enforceable in any way but may be subject to certification or accreditation by the industry group that created them. For example, SOC 2 is a framework for data security issued by a CPA who is a member of the AICPA. A CPA auditor will offer an opinion on whether you are operating in line with the SOC 2 criteria.
A standard is a quantifiable and measurable reference point. A standard will include a formulaic process for assessing a specific outcome or result. A standard will typically include one or many units of measurement as well as a clear definition of success. For example, if the standard to qualify for the Olympic 100 meters was that athletes must run under 12 seconds, we can easily mark out two points that are exactly 100 meters apart, and then time athletes' ability to run between both points. An athlete that did this in 10 seconds would meet the standard and an athlete that did it in 14 seconds would not. The National Institute of Standards and Technology (NIST) publishes multiple security frameworks such as NIST CSF, NIST 800-171, and NIST 800-53, and these typically include, or at a minimum refer to, quantifiable standards.
How are regulations and frameworks enforced?
Regulations often don’t have any formal certification authority. Instead, adjudication is performed only after non-compliance is reported (or data breaches come to light) rather than proactively ahead of an incident. For example, companies holding Protected Health Information (PHI) are expected to operate in line with HIPAA regulations but they are not certified as HIPAA compliant and will only be fined if they are found to be in breach of HIPAA regulations. There is an expectation that companies will self-regulate and operate in line with the regulations.
Regulations may also be related to the organization that created them. For example, FedRAMP is specifically related to Federal Government hosted services. FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.
While the regulatory authority does not always define a quantifiable standard it will often refer to one. Otherwise, enforcement can be tricky. In addition, regulators may also set up a governance board to delegate authorization and accreditation to third parties. For example, FedRAMP and CMMC authorities certify independent Third Party Assessment Organizations (3PAOs) to help cloud service providers and government agencies meet FedRAMP and CMMC compliance regulations.
Limits of regulatory authority
Compared to frameworks, which are created by industries, regulations are usually geographically bound as their authority to enforce the regulation is limited by the jurisdiction of the entity enforcing them. For example, as a US federal regulation HIPAA does not apply outside of the US unless it is related to a US government entity operating overseas, eg. USAID, CDC. Commercial organizations operating outside the US do not fall under the jurisdiction of HIPAA for their overseas operations unless of course, those activities are linked directly to the US. Likewise, GDPR is a regulation written and enforced by the European Union, and even though it claims domain over any organization serving an EU citizen regardless of the geography where the breach occurred, such oversight is only enforceable should they have some form of jurisdiction, retain some form of leverage (for example they have subsidiary there) or lastly where they have negotiated a cooperation agreement with the government where the breach occurred.
Regulations can also be limited by context. For example, HIPAA is limited exclusively to Protected Health Information (PHI) managed by a covered entity or a Business Associate. Identifiable healthcare information managed outside of this context is not covered by HIPAA. Likewise, PCI DSS is associated with the payment card industry and is limited to protecting specific financial information such as social security numbers and credit card information. Other financial data is not covered. Other frameworks, however, are broad and apply to multiple data sets and industries. For example, ISO27001, AICPA SOC2, CSA, and even NIST are all used across the world and across many industries.
Enforcement of regulations
Some regulations define a broad interpretation around reach. For example, while GDPR is limited to the EU its remit is related to EU nationals and how they interact with a corporation and not the location of the corporation itself. So, an EU national resident in the US and interacting with a US-based business in the US may still be subject to GDPR rules. Likewise, while CCPA is a state regulation it also applies to corporations who operate outside of California when they are dealing with a California resident.
All regulations are only as rigorous as the authority in place to enforce them, so where limited powers of enforcement apply, then we typically see lower adherence to the regulation because there is no downside to non-compliance. Regulatory enforcement is rarely the primary driver for an organization to invest in compliance. Typically the primary driver for compliance is a requirement to demonstrate compliance to a customer.
While regulations are often quoted as a reason for organizations to be compliant, weak enforcement too often allows organizations to make false claims. Unless an organization has gone through a credible, third-party audit conducted by a reputable, independent certified auditor it is advisable to take broad claims of compliance with a pinch of salt, even for prominent regulations like HIPAA, PCI, GDPR, and CCPA.