Skip to content ↓ | Skip to navigation ↓

Security and compliance are often said in the same breath as if they are two sides of the same coin, two members of the same team or two great tastes that go great together.

As much as I would like to see auditors and developers (or Security Analysts) living in harmony like a delicious Reese’s cup, a recent anecdote reminded me that too often the peanut butter and chocolate sit alone on their own separate shelves. I was recently talking with our auditor, David, and he relayed the following story which got me thinking about how security and compliance intersect.

David was doing some work with a Bay Area company that is developing an SaaS product and operates the following of DevOps principles. He was talking with one of the developers, Candice. David mentioned that the work was not in compliance with the assessed framework. Candice, angry at this statement, said, “But it’s completely secure!” Replying, the auditor said, “Yes, it is. The security is well designed and implemented. However, secure is not the same as compliant.” The developer had the peanut butter but was missing the chocolate.

The converse is also possible. One can meet the letter of compliance yet miss the security goodness the criteria are designed to deliver. We’re all familiar with “checking the box” while failing to get the intended value from a particular control. If we illustrated this sad situation with a Venn diagram, it would be two solitary circles kissing on the margins. A better situation would be greater overlap as security and compliance align to meet their shared goals. What are ways security and compliance teams can work together to create a winning alliance?

Same Goal, Different Actions

When it comes to the goals of both security and compliance, it boils down to one word: risk.

Managing risk is the reason both groups exist, and that shared goal should inspire a combined effort to achieve it. Both groups design, establish and enforce controls to protect an organization. With so much in common,  it seems like these two should be natural allies, and often they are. So why does a situation like David and Candice’s occur? Perhaps grammar will point us in a helpful direction; in this case, verbs. Security and compliance are both something you have not something you do.

So what do you do to become secure and compliant?

Secure, prevent, protect, detect. These are the verbs of cybersecurity. Securing information assets from damage or theft is the mandate of the cybersecurity team, and the means by which they do that are predominantly technical.

The CIS 20 Critical Security Controls or the MITRE ATT&CK framework, for instance, are technical in nature. Much of the training from groups like SANS focus on technology, and the tools themselves can be extremely complex.

For example, a security professional may do asset discovery and vulnerability management with Tripwire IP360, file integrity and secure configuration management with Tripwire Enterprise or spend time configuring and managing firewalls. Developing and designing secure architectures to protect data in motion and at rest, preventing and detecting intrusions and monitoring and managing logs are all part of the cybersecurity daily routine. All these tools and processes are in place to protect and defend the information and technology assets of an organization. Compliance is not the primary concern or mandate of the security team, though it may be a business requirement.

Compliance teams are also interested in managing risk, though their mandate is often broader than just information assets. Policies, regulations and laws go beyond information risk to cover physical, financial, legal or other types of risk. The role of compliance is to ensure that an organization complies with those various requirements. In order to perform this work, compliance teams audit, interview, report and communicate. These are very different verbs than what security teams use, yet they are intended for the same purpose: protecting the enterprise.

If a security team lives in the world of technology, the compliance team lives in the world of text.

Words govern the compliance team because they need to understand the rules under which they are governed and develop policies to both follow those rules and protect the business from other known risks. While the security team is tasked with implementing controls, the compliance team is responsible for ensuring those same controls are implemented. The former need only have assured themselves that their controls are in place and functioning as expected; the latter requires proof which means generating evidence to satisfy a third party. It is evidence that creates the largest gap between security and compliance, and it can be one of the most challenging aspects of bringing the two together.

Let’s return to David and Candice. I don’t know the details of that particular engagement, though it isn’t hard to guess why there was a disconnect between security and compliance: Candice was doing all the right things from a technical perspective – her code was well-written, her architecture well-designed, her deployment process well-executed – yet perhaps she was missing some critical documentation to prove this was the case one-hundred percent of the time. An auditor can observe a point-in-time event, but without a paper trail, there isn’t a guarantee that processes and policies are followed every time.

And therein lies an important challenge. It’s tedious to document processes, and many requirements seem to put roadblocks in the way of rapid development and deployment. There is a tension between the competing interests of security, development and compliance as well as trade-offs between velocity, simplicity and documentation. Or is there?

A Winning Alliance

Does there have to be tension between security and compliance? It’s never been fun to have to show your work, and nobody wants to always be a nag, so what are ways to bring the groups together to create something better than the individual parts? Here are a few ways to bring those two lonely circles closer and create that winning alliance.


I wrote above that “communicate” was one of the verbs attached to the compliance group. If they do it well, everyone wins. The following are important things a compliance team can communicate in order to be better aligned and more successful:

  • The Requirements – It may seem obvious, yet in the story of David and Candice, she didn’t know the requirements. The sooner security and development teams understand what is required, the sooner they can find ways to meet those requirements.
  • The Details – When communicating requirements, the people responsible need to understand what an auditor will be looking for. It’s not enough to say “have a firewall.” Does that mean layer 3 is sufficient, or do we need a layer 7 firewall? Is a firewall required at all or is the control about regulating network traffic and a firewall is just one way of meeting the requirement? Communicating the requirements in a specific, detailed way allows security teams to find ways to meet them that fit within their current workflow and technology.
  • The Evidence – The teams that provide the evidence need to know what will satisfy the auditor. Will the auditor be looking for reports, screenshots, or policy documents? There are a variety of different things an auditor will want, and knowing what these are ensures that nothing is missed come audit time. Developing the processes and artifacts early and often will save a lot of scrambling when an auditor is onsite.
  • The Frequency – Many controls and requirements are frequency-bound. Does something have to happen annually or monthly? Perhaps the control is continuous, so how can you show that? Knowing how often something needs to happen allows security teams to plan ahead and schedule those tasks. This is especially important in situations where a missed task will be a finding because you can’t go back and make it up. A good practice is to perform compliance-bound tasks twice as often as required to avoid missing a control due to unforeseen circumstances like illness.


Documentation can be tedious and time-consuming, yet it is required for a successful audit. Documentation is both an internal reference and evidence an auditor will ask for. Here are what I see as the most important documents for a winning alliance:

  • The Controls – A list of all the controls the enterprise has agreed to follow. These should have an ID, name and description and may also include frequency, environment, compliance or regulatory framework reference along with any other information the teams find useful. This is the common list of things the compliance team says are required and the security team says they do. Auditors also like to see these since they make an easy reference for them when performing audit work.
  • The Evidence – I mentioned evidence under the “Communicate” section because it’s vital that everyone understand and agree on what is considered acceptable evidence. For this section, I want to focus on the artifacts themselves. It’s not enough to do the work; you should get credit for it! Meeting notes, access and rule reviews, reports and even email can be evidence. Develop a plan to create receipts for all the good work you are doing and be sure to have a known place to keep it. You don’t want to do all that paperwork and then not be able to find it when someone asks to see it.
  • The Calendar – Frequency has been communicated, so it’s useful to create a shared calendar to track both the frequency-bound events but also the audit schedule and any time off for the teams. Having a visual representation of what is required when and who is available makes coordinating all the security and compliance tasks easier.


For me, this is the biggest win of the winning alliance. Much of compliance is about producing the evidence and documenting the great work the security team does. Security benefits from turning manual processes and controls into automated tasks. The three areas of automation that will produce the greatest synergy are:

  • Workflows – It may seem obvious that workflows are low hanging fruit, yet how many still require manual steps or hand-offs? Look for opportunities to build documentation into steps and triggers to kick off next ones. For instance, in a DevOps pipeline, tools like GitHub make it easy to show code reviews and pull request approvals.
  • Reports – If you are going in and generating reports manually, there is always a risk of failure, particularly in frequency-bound controls. It’s easy to forget or miss a reporting window. Generating and distributing reports in an automated fashion ensures they go out on time, ideally to a group of people responsible for analysis and action.
  • Documentation – I mentioned building documentation into standard workflows, and this is a great way to build security and compliance into day-to-day work. Similar to reports, there are opportunities to automate documentation. For instance, asset and software lists can be generated based on triggers in the environment then reviewed for authorization. The same can be done for users in access reviews. And don’t forget leveraging collaboration tools. ChatOps can be a great way to create documentation based on processes you already have in place.

The winning alliance comes when a security team has put in place great controls to protect information assets and a compliance team validates that they are in place and operating as expected. This alliance ensures that security controls don’t atrophy and required documentation is in place come audit time.

If you are interested in solutions that can help with security and compliance, check out Tripwire’s security solutions including vulnerability management, secure configuration management and FIM, malware detection and log management. Whether you need protection for the data center, cloud or industrial and OT environments, Tripwire can help.