We have been working with companies to go from zero to compliant with something for over ten years now. That something has included SOC 1, SOC 2, HIPAA, FedRAMP, ISO, PCI and a bunch of other sets of requirements that get a bit esoteric to include at risk of making your eyes glaze over from the acronyms. We’ve shepherded these companies through gauntlets of auditors with their never-ending requests to ultimately result in an official audit being completed.
The Hardest Part of Passing an Audit
I often get asked what the hardest part of preparing for audit is – and I usually end up giving the same response:
Most companies will start the process with about 80% of the requirements already met and then the other 20% will need to be implemented. However, from a documentation perspective, most companies will have 20% documented and need to document the other 80% to be successful in their first audit.
At a first glance, this seems relatively simple. Most companies are already in “OK” shape from an overall security posture perspective as they’d be out of business after being completely pwnt to a crisp. Sure, there might be some enhancements that can be made to make the overall security posture match with what some would call “industry standard” levels, but there’s usually not a ton of work to do here. The difficult thing in recent years has been the dearth of audit preparation platforms banging the drum of compliance automation being the way to audit success when they’re mostly hitting the low hanging fruit of confirming that the 80% is mostly in place and pointing out the other 20%.
However, the hard part here is documentation. Specifically, the 80% of it that you’re not doing because you have a “day job” that doesn’t include generating paperwork to be reviewed in a future audit because there are “more important things to do” or “it’s not fun”. Most people jump to the conclusion that documentation means you’ve got a set of policies that you’ve found on the internet and changed the company name to your own. Unfortunately, that’s not what’s usually missing and is part of the 20%. The other aspects of documentation such as procedures to describe how you do something and knowing what evidence is being produced in order to prove that you actually did the thing is where everyone struggles.
Documentation
Auditors love documentation. Documentation includes policies, procedures and evidence that you’re actually following those policies and procedures. The documentation that you generate demonstrates to auditors that you’re doing all the things and doing them consistently over the course of time. Here’s a quick breakdown of the documentation elements that go into your first audit:
Policies
Policies are high level documents that give a general outline of all the things that a company should be doing and these policies are usually reconciled to various compliance requirements. For example, SOC 2 may want to see that you’re training your employees and contractors in information security and other relevant topics, so you’ll have some sort of training and education policy that states, at a high level, what you’re going to do. This policy won’t necessarily describe how you’re doing to do it, but just declare that you will.
Procedures and Standards
Procedures and Standards is where it gets a bit more difficult. Extending the training example below, a procedure document will describe exactly how the policy will be implemented. For example, it might say that on the first day of employment, the training administrator dispatches some courses via the learning management system to the new employee and tracks it to completion. If the employee doesn’t cooperate, then there may be a described escalation process as well. Overall, procedures and standards are much more tailored to exactly what you do to implement the policy.
Evidence Documentation
The hardest part of documentation is generating evidence that you followed your procedures and standards. For the training courses, the auditor will want to see evidence for a sample of new hires that they completed the assigned training in accordance with your policies/procedures (within some number of days of hire). They’ll also want to look at your annual recurring training and whether everyone took their refresher training. This may seem like something that’s automagically handled by your learning management system, but you’d be surprised – we’ve run into these systems that will delete training evidence/history for terminated users which makes it impossible for you to demonstrate to an auditor that they in fact, took the training. Doing a dry run of collecting evidence for each audit objective goes a long way to being ready because you know where to find this.
This is also not too dissimilar from my SOC 2 CC8: Change Management post started going on about evidence of testing getting generated. As the evidence bar for an auditor is one that they can look at it and understand what is done without any other context, the amount of testing documentation in tickets for the typical startup is usually very lacking. Fixing this particular documentation habit is not something that any level of automation can help you with – you’ve got to actually talk to people, get them on board and make it part of their job at the expense of potentially slowing down development/testing productivity. All I can say is that I’ve never met a product manager that’s been a fan of this trade off.
Conclusion
Wrapping things up, it would be easy to turn this into a sales pitch, but I’ll leave you with this thought instead: When preparing for your first audit, focus on the documentation that you’re generating to prove that you’re compliant with whatever requirements you want to be. What would a third party auditor that is not familiar with your company be able to determine from you put in front of them?
Go Back to Availability
