To keep the security conversation going around 2017, we’re shifting focus from business leaders to compliance professionals.

These audit aficionados are driven to keep their companies in line and free of any fines for non-compliance. Whether they live an audit at a time or have streamlined their attestation through continuous compliance, their roles are ostensibly dedicated to ensuring the security and control of their customers’ data, per regulatory standards.

However, that’s where a critical distinction must be made: while compliance standards (HIPAA, PCI DSS, SOX, et al.) mandate security practices, they only go so far. Too many organizations believe that compliance is enough to protect them against cyber attacks and instituting elevated, risk-based security practices – the kind that evolve with advanced persistent threats.

That’s why for part two of our three-part blog series, we’re going beyond regulatory checklists and audit prep to explore why compliance professionals must build on their regulatory success to ensure the highest level of security and control for their organizations.

Compliance standards only set a baseline for security

We’ve said it before and we’ll say it again: compliance isn’t security. Despite our lambasting, however, too many organizations still consider being compliant as the sole indicator for having achieved cyber security nirvana. That shouldn’t be the case. Compliance shouldn’t be the ultimate goal. Rather, compliance standards should only set a baseline and the first step toward a more robust security program designed to address more sophisticated threats as they emerge.

The Limits of Compliance

Take ransomware as an example of how compliance standards are limited in their response to emerging threats.

As we know, data protection in the U.S. healthcare industry is regulated through HIPAA. But HIPAA was initially enacted in 1996. Although the HITECH Act, which enhanced HIPAA, was enacted in 2009, that’s still almost a decade ago. That’s a lifetime in cyber security.

As a result, when threat actors began targeting hospitals with ransomware, it initially created a considerable degree of confusion in the compliance community. For one, compliance officers wondered whether ePHI encrypted by ransomware should trigger breach notification – a necessary, albeit PR-damaging, breach response procedure.

The general mindset is that breach notifications are only required for unauthorized acquisition or disclosure of “unsecured” ePHI. In the compliance community, “unsecured” usually means unencrypted. Since most ransomware operators aren’t interested in acquiring ePHI; but instead only holding the data captive for ransom (ironically through encryption), it would appear that a data breach didn’t technically occur according to previous compliance standards.

Although the HHS eventually issued guidance for ransomware attacks, where it clarified that ransomware infections involving ePHI can actually be considered data breaches, it doesn’t erase the fact that new threats can catch compliance officers by surprise.

Threat actors don’t care if you’re compliant.

And, the proof is in the well-known, high-profile data breaches, of companies like Target, Home Depot and Heartland. The one thing they all had in common? They were all PCI-compliant before the attack.

How could that have happened? Wasn’t the rigorous process of PCI DSS compliance designed to eliminate vulnerabilities? Well, one logical explanation is that these companies may have fallen into compliance drift. Regulatory compliance audits are simply assessments at a moment in time. As time passes, most organizations fail to maintain their compliance posture. In a 2015 report on PCI compliance published by Verizon, it was revealed that only 28.6% of companies maintain full compliance within a year of validation.[1]

Unless you’re able to inculcate the importance of maintaining a security-conscious mentality, employees could revert to bad habits and your company could slowly drift out of compliance.

Another explanation is that the so-called ‘rigorous process’ of regulatory compliance may only be an idealization. Many companies approach regulatory compliance through a checkbox approach. That means, when given the opportunity, they answer in the affirmative to questions verifying the presence of certain controls – possibly without performing the due diligence to ensure that their submission is 100% accurate. This creates very serious – and exploitable – gaps in a cyber security program.

In a 2017 study, nearly half of surveyed organizations lacked processes to effectively monitor compliance adherence in third-party vendors2. You don’t have to look far for a relatable example. The initial compromise of the 2013 Target breach is believed to have originated with a third-party vendor. So, while the regulation-mandated paperwork was there, so where the vulnerabilities.

Regardless of any deficiencies in their approach to compliance adherence, the fact remains:  these regulatory “achievements” were meaningless when faced with persistent and constantly evolving threats. Any sense of security provided by their certifications or completed audits evaporated as soon as the breach was discovered.

While that’s not to imply that a security-first strategy guarantees 100% protection from data breaches, it does, however, illustrate the line between what you have to do (compliance) and what you should do (implement the highest level of data protection) when it comes to defending your sensitive and regulated data. And no one understands this distinction more than the threat actors seeking to exploit those who adhere to the bare minimum.

Compliance is nice, but reliable, responsive and robust cyber security program is better. It not only limits the impact of compromise or breach, this level of security and control also streamlines compliance attestation – an aspect we thoroughly cover in our white paper, Farewell to Audit Season.

Non-compliance can be costly

This fact is obvious and well-known; however, it bears repeating, especially when the potential costs of non-compliance can cripple even the largest organizations.

We’re not just talking about fines from failing an audit, which can be substantial (from Part 1, Advocate Health Care’s $5.55 million settlement for HIPAA violations). Non-compliance can result in a data breach, which cost U.S. companies an average of $3.62 million per breach2. And, that’s just the known cost. Once a breach is reported, organizations must also deal with the loss of reputation and potential business – aspects that can take years to rebuild and may never fully recover.

Compliance standards, while only a baseline for security practices (as mentioned above), were mandated for the protection of sensitive data. Adhering to these practices can at the least minimize the scope of a breach – an important detail when breached records cost companies $141 on average2 – and at the most prevent a breach outright.

Corporate responsibility for customer data

This fact may also be rote, but again deserves to be shouted: the security and integrity of your customer’s data is your responsibility. This goes far and above any corporate or role-related duty to adhere to prescriptive compliance standards.

It’s understandable that compliance attestation gets top billing; without it, most organizations wouldn’t be able to operate. However, if you’re in an industry that has compliance regulation, then you’re likely dealing with sensitive personal information (ePHI, PII, credit card data). As stewards of this data – regardless of how much or how little interaction you may have with it – your responsibility is to the individuals entrusting you with that data, not the auditors nor your board of directors. You’re liable to the individuals and businesses behind those ones and zeroes.

Next Week: Why Security Matters for DevOps professionals

For the next part in our Why Security Matters blog series, we’re focusing on why security is critical for DevOps professionals. Check back in as we decode the importance of security best practices and why this understanding is essential for the individuals responsible for the support and evolution of their organization’s applications.

[1] http://www.verizonenterprise.com/verizon-insights-lab/pci-report/2015/

2 https://advisory.kpmg.us/content/dam/kpmg-advisory/risk-consulting/pdfs/2017/03/compliance-journey-survey.pdf