Security or compliance? Stop choosing between them

The difference between security and compliance is more than just process. It’s philosophy and practice.

Compliance can be one tactical execution of a great security strategy or potentially a bureaucratic check-the-box effort. While security and compliance share similar goals, IT too often meets specific requirements for system compliance but misses the underlying security needs of the whole organization.

I’ve been in the InfoSec space for more than 20 years, and I’ve seen so many smart, talented security practitioners make that mistake. I sympathize. With so much pressure to keep data secure, and so many systems to manage, it’s easy to lose sight of security strategy and instead focus on compliance tactics.

Here is my advice on how to navigate the challenge.

First, take a step back

Modern IT work feels like it moves so fast, it’s always changing. But here’s the thing: it’s not. I’ve said before that I challenge the idea that cybersecurity is becoming more complex because the fundamentals of our work – confidentiality and integrity of data – actually have remained constant for decades.

Rather than focusing on how fast you must move to implement a new platform, system, or app in a way that is compliant with regulations and requirements, ask yourself what the implementation is really trying to solve. Who will be impacted, and how will their workflows change when the stack changes?

You also must ask yourself what security risks could emerge with the new system in place – that might be the risk of a data breach from a known weakness or vulnerability in the new system or application, or the risk of user misuse due to a lack of identity authentication strength, or a host of other considerations. You might find that you identify security risks that aren’t specific to the new tech but have been exposed by a fresh look at an existing system.

Recognize the difference

Security and compliance are intertwined but are still separate disciplines. Good security strategy includes compliance, but it technically is possible to practice compliance without making security a priority.

A home inspector looks at a house that’s for sale with a list of things that might be broken or below standard—the condition of the roof, the age of the heating system, the state of the foundation, the age of the fire extinguishers. That inspector would make notes on a list and the value or viability of the home sale would be adjusted accordingly.

But the home inspector doesn’t enter the house thinking about whether the driveway is at an angle that makes backing into the street dangerous. They wouldn’t consider if there’s noise on the street from children playing outside, which might be a sign of a neighborhood that’s considered safe for young kids. They wouldn’t test the response time from police if an alarm system were triggered.

In the same way, compliance can show that you have met certain standards, but it doesn’t help you understand the security of the entire system in which your business is operating.

Identify the breakpoints and the compliance requirements

Sometimes, it helps to literally map this out: take a blank sheet of paper. Draw a picture that shows the ecosystem in which the new app or system will operate. Make a list of the jobs and processes it touches and identify the points at which risk gets introduced into workflows.

Once you have your risk map, make your compliance checklist: the regulatory and other requirements that this new operating system, application or other technology must meet, based on your existing business processes and operational needs. With this list in hand, you can manage the reporting and audit processes (both internal and external) that oversee compliance.

Now, lock your strategy in place

Compliance and security go hand in hand, but they are not equals. Compliance shouldn’t hinder security, but security goes far beyond compliance. You need a strategy that encompasses both, but starts with a security mindset.

Getting perspective by looking holistically at the security needs that surround a system and the workflows it helps to govern is crucial. That perspective will set you up for the development of a sound strategy, if you take the time to see things from new and different angles.

At the same time, remember that you are not alone: you need the insights of your colleagues and stakeholders whose work is impacted by the system to design security for it. When you are mapping out your risks, solicit inputs so that you design security that serves the system, not the other way around.

Finally, position compliance as a natural output of security strategy, not the driver for it. For some businesses, that means changing perceptions across the IT organization. Remember that as a security leader, you’re responsible for keeping the organization safe. But you’re also responsible for keeping it smart.