Security and compliance: Related but different

In the IT world, security and compliance are frequently mentioned in the same breath. While the two seem to be joined at the hip in this regulation-heavy era, it’s important to understand that the concepts are not synonymous. Failure to recognize the differences can impact your organization in undesirable ways.

Security is a necessary element for attaining compliance with common government and industry regulations, but it’s not the only element. And compliance requires a certain level of security, but it doesn’t always ensure the highest level.

Security is a strategy, whereas compliance is more of a process. Security is arguably far more complex than compliance. Let’s take a look at the differences between security and compliance, where they overlap, and the complicated relationship between the two.

Compliance = complacent?

It doesn’t have to, but there’s no denying that knowing your systems have been validated as compliant can sometimes breed complacency, and that comes from the misconception that compliance and security are the same.

In fact, in many of the high-profile data breach cases involving big companies, those companies had been found to be compliant with industry or government regulations shortly before the breach occurred. Target, Heartland Payment Systems, and other companies suffered major breaches despite being PCI-compliant.

In fact, many of the regulations and industry standards with which entities struggle to comply are narrowly focused on protecting privacy and personal data.  This is true of laws such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States and the General Data Protection Regulation (GDPR) in the European Union.

Specific security measures are necessary to protect personal data. Those measures alone, however, may not protect the network and systems from other threats. Data protection is only a part of an effective overall security plan. Hospitals that were secure in the knowledge that they had met HIPAA requirements were nonetheless vulnerable to attackers who had something a little different in mind: like making the data so “private” that even the hospital personnel couldn’t access it.

Both U.S. and U.K. hospitals were hit this past year with massive ransomware attacks that encrypted their systems and in some cases basically shut down operations. While the healthcare facilities may have been compliant with applicable regulations, they were lacking insofar as their overall security was concerned.

There are a number of factors that make medical entities especially vulnerable to attack. The requirement for systems to be up and running 24/7/365 make them a favorite target because the life-and-death nature of their business dictates that they do whatever it takes to keep their computers running, even if that means paying the ransom. But one also has to wonder whether some hospitals have left themselves open to threats that they should have anticipated and protected against because they were focused more on being compliant than on being secure.

Implementation and documentation

Both security and compliance are multi-step operations, and they share some common steps, but security is focused primarily on implementation, whereas compliance is mainly about documentation. Securing your network, systems, and data require you to:

1. Evaluate: assess the threats and discover the vulnerabilities
2. Plan: decide what you want to protect and discover the solutions that will best address the threats and protect those assets
3. Implement: deploy the software, hardware, configurations, and technologies that make up those solutions

Of course, security is not a destination. You don’t “get there” and then it’s done. It’s an ongoing journey, as new threats appear on the horizon, so you’re constantly repeating these steps.

Compliance begins with determining the security requirements. These are not specific security measures, but rather security goals. What must you accomplish to be compliant?  For example, one of the requirements of the GDPR is that you must “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” [Article 32(1)(b)].  Once you know what the requirements of the particular regulation or industry standard are, you can follow the steps to comply.

Adhering to regulation begins with the same general process, but it means something a little different:

1. Evaluate: assess the current state of your network, systems, processes and procedures, and whether and how they meet the requirements for compliance
2. Remediate: if there are ways in which your implementation is not meeting the requirements, put into place the measures needed to remedy that
3. Document: Show, in detail, exactly how your systems and processes meet the compliance requirements

Note that while security involves more than just compliance, as we discussed above, compliance also often involves more than just security. Once again taking the example of the GDPR, “Security of processing” is only one section of the law with which organizations that fall under its jurisdiction must comply. Other requirements aren’t categorized as security.

For example, there is an entire chapter (Chapter 3) that consists of articles 15 through 21 laying out a set of “rights of the data subject.”  To be in compliance with the law, organizations must be able to demonstrate that they are able to – and do – provide those whose data they collect or store with information about the purpose and nature of processing that data, rectify (correct) inaccurate data, erase data upon request of the data subject under certain circumstances or restrict the processing of that data, notify others to whom the data has been disclosed of any corrections or erasures, provide data subjects with a copy of their data in a commonly used format, and respond to objections and requests of data subjects.

The above are only some of the compliance requirements contained in the GDPR that are not about security, per se.

Even if your organization is one hundred percent in compliance with every single subsection of the regulation, though, that’s not enough. It does you no good unless you can demonstrate that compliance to the appropriate authorities if and when they come asking.

Some regulations require periodic audits to verify compliance. Others rely on organizations to self-police unless and until the regulating body gets a complaint or decides to conduct a random check. Some require that you conduct assessments of how your organization protects personal data.

For example, the GDPR requires that data controllers carry out a Data Protection Impact Assessment (DPIA) under certain circumstances, to determine what the impact of your processing of the data will have on those rights.  This includes when processing of personal data is likely to result in high risk to the rights and freedoms of data subjects, large-scale processing of special categories of data or data related to criminal offenses, and automated processing for profiling. DPIAs constitute an important element in GDPR compliance.

Summary

Security and compliance go hand-in-hand, but they are not the same. Compliance usually requires more than just security measures, and security – to be most effective – often requires more than just meeting compliance criteria. Compliance often means only that the minimal level of security is in place, and may apply only to a narrowly defined type of data. Yet one of the ultimate goals of both security and compliance is the same: protection of data from data breaches.  Compliance should be the result of implementing an effective security strategy – not the other way around.