Early in my cybersecurity career, I never gave much thought to audits. They were things that just happened to you like slipping on the ice or Mount Vesuvius. You knew there was a risk of it happening, but you didn’t need to spend much time worrying about it.
I’ve learned a lot about audits since then. Yes, they’re stressful and, no, they don’t generate a lot of joy; however, they can be incredibly useful to your organization if done properly and as part of a larger governance program. The hard truth is it’s rare for organizations to exempt themselves from information security (IS) audits. IS audits have become an expectation, and the growing number of requirements generated from these audits means the audit and compliance profession is firmly rooted in most companies, just like HR, Finance, and IT.
IS audits are relatively new as far as audits go, but there are many: SOC 2, ISO 27001, PCI, FedRAMP, HIPAA. Some of these aren’t actually audits but are associated with an audit. For example, FedRAMP isn’t an audit itself. But to be considered FedRAMP compliant an audit (technically, an assessment) must be performed. These assessments are performed by independent, third-party assessors (called 3PAOs in FedRAMPian) who will represent you to a US Federal agency. Just like you’re going to court. They will advocate that your ability to securely manage your enterprise satisfies enough requirements to be allowed to provide a service to the agency through the granting of an ATO by an AO. After (sometimes) years of preparation, an enormous financial cost, and many many frayed nerves, the agency can simply reply with ‘no’ and move on to the next applicant. I’ve seen it happen and it’s gut wrenching.
Excited about audits yet?
What is an Audit?
Whatever the effort and scope of an IS audit, they are all fundamentally a review and assessment of how your organization satisfies established requirements. That’s really all they are. If, and how well, your organization satisfies these requirements is for qualified audit professionals to determine. They come, they judge, they give their opinion. They can be performed by external or internal personnel. Most people won’t care about your internal audits, but care a great deal about your external audits.
There is a lot left unsaid in the preceding paragraph:
- What is a requirement? Who makes them? Can I make them?
- I’ve heard about “controls” – are they similar to requirements?
- Are all IS audits and assessments the same?
- Do companies want an audit or do they need an audit?
- Internal audit and external audit? Like, one is done in a conference room and the other on the patio?
For this article, I’m keeping the concepts high-level. We’ll dig into the various types of audits, what makes them unique (and similar), how they’re performed, what is generally reviewed and tested, how you can prepare, and anything else I believe will help you with coordinating and performing your own audits.
There are many loquacious definitions to describe an audit and you’ve surely read a few. Here is my AuditShot about audits:
Audits are:
> An evaluation of if, and how well, your organization satisfies requirements
> A means to establish and maintain trust with your organization
> Valuable to your internal stakeholders, customers, business partners, investors, and regulatory bodies
> NOT punishment, though they can feel like it sometimes
What is Compliance?
Compliance is equally straightforward in description: it is the degree to which an organization satisfies a requirement. If a requirement states you should enforce a minimum password length of 12 characters and it’s verified your password policy enforces a minimum password length of 20 characters (good for you!) you’re considered compliant with that requirement. Do you get extra compliance karma for really nailing that length and going an extra eight characters? No. Compliance doesn’t care how much you’re able to flex on requirements. It only cares that you aren’t doing less than what is expected.
There are many ‘sets’ of requirements (lets call them frameworks) and I mentioned some earlier: SOC, ISO, and PCI are some of the most common. If you are subject to only one, you can usually just work directly off the requirements for that particular framework. There is a 1:1 relationship with the requirement and how you meet it. Easy peasy – track all that work in a spreadsheet.
What if you are subject to multiple audits or want to track more than what a specific framework’s requirements stipulate? Let’s say one framework has 50 requirements, another one has 150, and another 75? Do you still track each requirement individually? Do we just add more tabs to our spreadsheet? How do you know you’re doing everything you’re supposed to do to pass a multiple of audits?
A key concept in compliance is “controls”. Controls tie similar requirements together, centralize what should be monitored within your organization, and minimize the effort necessary to ensure compliance with a variety of frameworks. They will save you, and I’ll talk about them in another post.
Compliance is:
> The degree to which an organization satisfies a(n audit) requirement
> An ongoing, perpetual verification of your organization’s control health
> NOT an annual event
Final Thoughts
If an audit is a test of if and how well you meet requirements, and compliance is ensuring you do actually meet the requirements, why is audit and compliance so hard? It seems pretty straightforward. Sadly, I feel many senior leadership teams hold this belief. And woe upon you if you successfully pass your first audit and find your C-suite is convinced that passing one type means it’s easy to pass another type. I’ve been in actual conversation where these words were declared, out loud, to a group of equally bemused leaders wondering why they don’t have more audit certifications that can be added to marketing material.
Let me illustrate audit and compliance complexity using an example. This one is fairly simple.
Given this requirement: Media used to store sensitive information must be decommissioned according to industry best practices rendering data irretrievable. How would you know if you comply and, therefore, would likely pass the scrutiny of an audit?
Before we can evaluate our compliance, we must first understand the requirement. How else can we test if we’re doing the thing and we don’t know what the thing is asking us to do? Here is how I would approach it from just the requirement language:
- What is “sensitive” information? Do we define it or is it defined for us?
- What does “decommissioned” mean? Destroyed? Secured? Unplugged?
- What best practices are being referred to? If our company manufactures envelopes, is it the envelope industry’s best practices? Can we choose the industry? I like movies, what does that industry do?
- Irretrievable by whom? Employees? Customers? Bad actors? Nation states?
Additional questions:
- When should sensitive information be decommissioned?
- Do media backups also need to be decommissioned? If so, do we use the same requirement?
- Are there data retention requirements that conflict with this particular requirement? If so, which one are we more concerned about complying with?
- Who is allowed or expected to perform decommissioning?
- If sensitive and insensitive data reside on the same media (bad design, by the way), is it all considered sensitive? Can they be decoupled?
None of these questions are embellishments or something I’ve added to inflate the complexities of compliance. They reflect both my actual thought process and experience of being asked as part of an audit. Also, requirements change – the questions above are illustrative for this example and will obsolesce over time. A compliance professional is expected to understand how changes will impact their organization. If you’re someone who likes to learn and is comfortable feeling a constant twinge of panic that something out there is changing, you’re perfect for this role!
The takeaway is this: compliance is hard and complex. Are audits hard and complex, too? Yes, they are; but if you’re on top of your compliance program, have a solid set of controls, and have a mature or maturing internal audit program, audits should really be a (figurative) paper exercise. Many companies I’ve worked or consulted with are laser-focused on audits and sort of work backwards into compliance if time permits. Don’t do that. Spend the time and effort on your compliance program first and the benefits will pay big during audit time.
