• AJ Yawn

9 Facts about Cybersecurity Compliance from Compliance Gurus at ByteChek and Elastic

Updated: 6 hours ago



Last week I had the privilege to host a webinar with three of the smartest cybersecurity compliance professionals in the industry. Terra Cooke, Director of Compliance at ByteChek, Devin Harris Compliance and Customer Assurance Lead at Elastic, and Anthony Scarfe, Director of Information Assurance at Elastic and I chatted about common controls frameworks in compliance. If you missed the event, visit the NABCRMP site to sign up for a membership and watch the recording.


During the session, I was blown away by the knowledge bombs being dropped by Devin, Terra, and Anthony. I recapped the 9 compliance truth bombs from the webinar below:




1. Devin Harris reminded us of this quote: “Complexity is the enemy of security”


This quote rings true for compliance as well. When you make compliance complex for teams it becomes an arduous task that no one wants to participate in. Compliance professionals must focus on simplifying compliance for the internal teams impacted by the audit. This means going to your teams and understanding the way they do business and figuring out how to apply compliance to existing processes and not reinvent the wheel.


2. It’s not just one hour in front of the auditor, its multiple projects and actions before the auditor shows up:


Anyone that has been through an audit knows this point is so true. There is so much work done before the auditor shows up that often goes unnoticed. If you work in GRC you should acknowledge all the prep work that takes place before the auditor shows up and share some empathy with the teams helping collect evidence and build out the program. With that in mind, the famous quote “an ounce of prevention is worth a pound of cure” comes to mind. Doing your work early makes the audit a lot smoother for all parties involved.


3. Good security will get you further than good compliance.


We hear that compliance ≠ security, which I agree with. I do believe that security = compliance, though. This statement by Terra Cooke can be considered spicy by some but it’s the truth. If you focus on good security you will go further and faster than focusing on good compliance. Good security means focusing on protecting customers data and sensitive information, period. Good compliance will earn you a report or certification but it doesnt guarantee you’ve actually implemented the security controls necessary to protect yourself. Don’t worry about checking a box, focus on how you are protecting your customers data and compliance will work itself out.


4. Think of your compliance program like a product.


I absolutely loved this statement by Devin Harris! You have a non-conformity during the audit? It’s a bug. Do you want a new control to be implemented? That’s a feature request. The people in the business? Those are user personas. This mindset helps you operate in the same agile ways as your engineers, product managers, SREs, DevOps teams, etc. This shared understanding and language makes buy-in easier for the teams not in a compliance function.


5. Don’t focus on the checkbox.


Focusing on the checkbox will get you a compliance report. But it won’t build a sustainable cybersecurity program that protects you from bad actors. The whole point of compliance is to prove that you have the proper security controls in place to customers, partners or third parties. When you check the box you could potentially open yourself up to weaknesses that will be overlooked because you have a clean audit report. Focusing on the checkbox can leave you exposed to threats and provide a comfort to the organization that things are going well from a cybersecurity perspective. That comfort can lead to gaps, those gaps can lead to bad actors causing irreparable harm to your organization.


6. GRC is a three-letter acronym for a reason


GRC stands for Governance, Risk and Compliance. This is an important thing for anyone trying to start their career in GRC to understand and keep top of mind. Governance, Risk and Compliance all bring their own individual challenges and responsibilities. In large organizations, these functions are broken out into separate roles and sometimes departments. Just like the cybersecurity sector as a whole, the GRC space is a broad field with a wide range of potential roles.


7. Compliance professionals have to be prepared to do the work.


During the session, Anthony mentioned that compliance professionals have to be willing to get their hands dirty and do the work in the early days of building compliance programs. As an example, Anthony described a situation where he met with teams to understand their processes and the deliverable after that discussion was supposed to be a policy. Anthony knew writing policies is not something a lot of people enjoy and may struggle with so he took the notes from the conversation and drafted a policy for the teams. He was able to go back to them with a draft policy that gets them going down the path of solidifying policies. This obviously doesn’t scale and you can’t do this for every team but it’s a good example of being willing to do some work in the early days of building compliance programs to build trust with internal teams.


8. Start now, it doesn’t get easier


The best time to get started with compliance was yesterday. The second-best day is today. Waiting until you’re “more mature” or “we’ll start once we hire” or “customers aren’t asking yet.” Getting started on compliance in the early days helps establish a foundational security program that the company can build off of. You’ll identify organizational and technical guardrails that can make compliance a lot easier as the company scales.


9. Live off the land


A concept we teach in SEC 557 at the SANS Institute is to “live off the land” when it comes to compliance. Use the tools your DevOps teams are using to prove compliance, there is no need to reinvent the wheel and make teams use other tools to prove compliance. Your goal as a compliance professions is to use tools that are already installed and in use at your company and being used by your teams. Use the tools your team’s use and let them administer them. By using the tools your teams use you’ll get more technically accurate data and more buy-in from the individuals impacted by the audit.