What is a Security Audit Really About?

Having spent many years coaching and mentoring sales teams, at some point or other the topic of security audits comes up, whether ISO, PCI, HIPAA, or something else, and so we have a discussion about selling into this space.

Sales people often default to negative outcomes (don’t blame them, it’s usually years of training!), so when I ask the question “What happens when a company fails an audit?”, the usual response is a mix of:

• They’d get a (massive) fine
• They’d suffer (huge) reputational risk)
• They could even go out of business!

I wrote an article recently where I had a conversation with a couple of AI’s to leverage their large data sets to try extract some real world data to show evidence of any of these 3 things happening (AI Fireside Chat: Could you go out of business if you fail an audit? | LinkedIn). There is absolutely no evidence of any, and actually both AI made a similar mistake that we humans do, conflate audit and breach, and started giving me examples from Equifax, British Airways, and so on.

Selling against the risk of breach is totally valid, but that’s a whole other topic and I want to draw a clean line between the 2 topics, so here I’m specifically talking about audits, generally ones where an external auditor is involved, but these can be internal audits or self assessments even.

This time I wanted to talk to real people, with some real world experience. As people working directly for a company going through an audit, and as consultants helping companies with the auditing process. It was also a lovely excuse to just catch-up with some awesome people!

Glenn Wilson

CISSP & Systems thinking practitioner and leadership coach / consultant specialising in DevOps, Agile, and Cybersecurity

You don’t necessarily fail an audit, you generally build a relationship with an auditor and they produce a preliminary report (or reports, depending how you’re partnering with them), which you then work on together before the final report is produced. The final report shouldn’t be a shock to anyone and is unlikely to be seen as a failure by anyone.

Glenn talked about his experience working with a vendor that had to adhere to the toughest PCI requirements (basically all of them!) and his relationship with the auditors in this. They worked very closely with the auditors, to the point that they actually embedded them in their development teams. This meant that there were not surprises in the reports and actually it was a continual effort to review decisions, potentially audit recommendations, and areas of improvement. There was never a “failure”, but recommendations and guidelines around what to consider and things that maybe are non-negotiable. Some risks are acceptable by the business and signed off by the auditors, some are added to the backlog to be addressed.

You are paying these auditors to be there, so if you’ve paid someone to get involved in your business, make observations and recommendations, then you choose to ignore them all and all this comes out in the final audit report, someone is doing something very wrong! A significant part of the audit is seeing improvements, remediations and fixed being implemented.

Let’s also talk about the different types of audits. Generally if you are responsible for someone else’s sensitive data directly, such as say PCI or HIPAA, then these are more of a mandate than a guideline. You are expected to have encryption, potentially end-to-end if your level is high enough. PCI as an example is actually a very good framework to follow, even if you don’t handle card data.

Then there are other audits that are more like guidelines and frameworks, such as ISO or NIST standards. These focus a little more on documenting processes, analysing risk and documenting that risk. One example is that you must have security in your development lifecycle, but no detail on what that security looks like, or what that even means. Not to say these aren’t useful at all, again they can be incredibly useful as a score-card to look over what you should be considering. Depending on your industry, these may go out to an external regulator, or your customers may simply ask if you are following the guidelines.

For fines, generally these come from independent bodies, in the UK we have the Information Commissioner's Office (ICO) who should be contacted in the event of a breach and can issue fines if they find short-comings in security and data handling. These governing bodies don’t generally do regular audits themselves, instead they listen to complaints or whistleblowers and act on these. You may be bound by certain requirements simply because you do business in certain countries. In the UK if you identify a breach, you have 72 hours to notify the ICO. The ICO isn’t there to fine you but instead to help you with managing the incident. Of course if you don’t notify them you’re chance of a fine dramatically increases, and if you don’t have adequate security relative to your type of business and data you hold, they are likely not to be amused, but they aren’t auditors.

GDPR is similar, it is a specific mandate (like PCI), but it’s not always explicit - i.e. you must have encryption, but not you must have a minimum level of xyz encryption. GDPR also doesn’t perform audits and generally gets involved when there are complaints made or whistleblower notifications. Although they have the powers to fine a maximum of 4% of total revenue, this hasn’t been seen so far and they want to work with companies' poor data handling / poor security standards instead of just throwing out fines (although fines can be very motivating).

Theoretically a major PCI failure could force you to stop trading, for example if you don’t have encryption when handling payment card data, but it’s very unlikely and generally you are given a grace period. And with this, they aren’t necessarily looking for complete compliance or complete resolution, they are looking to see that you are making progress, making improvements, and generally showing attention to the areas you have “failed” in the audit process. It’s more about the direction of fix, and evidence of this.

We talked about the negative company impact of failing an audit, and we couldn’t recall any company having a major disaster due to an audit failure. Sure, companies get fines because of breaches, there are some companies that have been forced to close after catastrophic ransomware attacks, and I’m sure we’ve all read news articles about companies failing due to fraud, but these shouldn’t be confused with audit failures or the result of being or not being compliant to a certain standard. It’s worth noting that it appears Solarwinds had both ISO27001 and SOC2 around the time of their major breach.

Audit’s have a huge value in showing your security, but they don’t actually make you secure. Most of the standards are pretty good standards. As mentioned earlier, even if you aren’t handling payment card data, there’s a lot of value in following PCI. If you can tick as many boxes as you can (being honest with yourself!), then you are working to improve your security. Keep the auditing simple and honest, don’t try to be perfect. Set your results based on work as done, not work as imagined.?

For the sales people out there reading this, an audit is also a great metric to show security coverage. How do you know if your tool is helping? How have they improved their security coverage from their audit results? Focus on how you can help a company with their audits, or their audit results, don’t focus on the doom and gloom of failure, fines, or reputational damage.

Checkout Glenn's profile - Glenn Wilson, CISSP | LinkedIn

Michael Man

DevOps Evangelist & Community Leader

There seems to be a mental bias that auditors are bad and we love to demonise them, but the reality is (based on his own experience), they aren’t out to get companies and actually they want to help. Keep in mind that most auditors have their own reputation, both in terms of getting quotes and references from companies they’ve helped, but also in helping their clients avoid being in the press for breaches or other security failings. They want to actually measure where you are today, and what the perceived and agreed deficiencies are. If there are any deficiencies, you almost always get a grace period to address the issues or recommendations.

With PCI, you’re generally buying the service of a QSA (Qualified Security Assessor) who will build a relationship with the business to understand what they are doing, what is in scope, and what is the best sample set to use. They will generally take a sample set of services / servers and look into these. They’ll then draft up their findings and present this draft to have a discussion around, you can even argue with some of the findings, maybe there was a misunderstanding about what data is within a service, or how something operates. From here you then start talking about what changes might be made to change the findings. You don’t really fail an audit, you might have deficiencies, but you don’t really fail an audit.

While what-if scenarios and threat / risk modeling is incredibly important for a business to do, auditors generally won’t go through this in detail. They’re looking at a list of checks and to see how you’re handling or addressing these today. That’s also an important point, audits are point in time, and they are never 100%. Things change all the time (especially in a world of cloud and microservices), so what is compliant this week may not be next. Audits are never a guarantee that you are secure or that you can’t be breached. Remember what Yoda says: “only a Sith deals in absolutes”, he was clearly referencing that there is no 100% security coverage!

Unless you’re an audit service provider, it can be tough using auditing as a sales topic for your cybersecurity product. Auditors and compliance teams will need a way of being able to trace changes in a process or system to show that a fix or improvement has been made. Tooling should be more around applying controls and enabling the individual subject matter experts across the business to have conversations with the auditors and compliance teams. Leverage the capabilities your product provides to show how you can provide proof of coverage.

If the solution can be integrated with a CMDB, and show the relationship between the audited components, scope and controls, then even better! If you’re in the start-up world, there’s a fair chance that what your security product can offer is a small slice of what the security team needs coverage of. Is there really value-add by giving them another dashboard in another tool, regardless of how comprehensive and easy to use that might be? If you can’t integrate with the central CMDB, then the next best bet is to provide the relevant information to the domain subject matter experts to allow them to have the conversation with the audits or compliance folks.

Ultimately, find out the value you are bringing, the benefits you can provide, don’t go in there with scare mongering. How can you make someone’s life easier (and don’t pivot off how terrible things are without your tool, especially if you’re going to say anything negative about failing an audit!). Selling with fear and scare mongering is an old sales tactic that should be left in the 90’s and really most security buyers are now tired of. Focus on the benefits, the value, the personal gain even.

Checkout Michael's profile - Michael Man | LinkedIn

Michael and I ended the conversation talking about negativity vs positivity, and a personal experience of mine in coaching sales people. At the time I had an older car that had gearbox problems, the garage told us that at some point the gearbox would die and at that point it would need to be replaced. I was of the view that I could defer spending money on fixing or updating the car and just let it die, but I used to challenge my class of sales people to convince me to buy a new car.?

I don’t remember a single exception, everyone went to the negative side. What if the car breaks down, your wife could get stranded with the kids. Your wife will get mad at you for leaving her vulnerable and might leave you. What if the car broke down at speed, it could cause an accident and your family could die! I’m not exaggerating with these, although there was a little dark humour in the discussion as we were all friends (despite them threatening my marriage and family!).?

Fast forward to when we did change the car, we did so to enable us to make a major family lifestyle change for the good and travel around Europe. There was no negativity in our decision, no driven by fear, we made the decision to spend money because of the positive outcome it would have on our family.

I’d love salespeople to take this one lesson away, spend more time focusing on the positive benefits, the value added outcomes. Whether the topic is auditing, or used car sales, or something else, what is the positive outcome that you are delivering.