GRC Destroyer #8: THE MODERN AUDITOR MANIFESTO (Part 1: GRC = Internal Audit)
Part 1 of a deep dive. How to run an audit program ALONE in 2024. I'll address compliance-in-a-box solutions vs. old-school methods and what your main objectives should be.
Why am I writing this?
It’s helpful for me to reflect what “GRC” means from the ground up. I’m in a unique spot to do that because I’m largely a one-man team quarterbacking external audit, internal audit, risk, and all the sales enablers that go into it like customer due diligence and trust. At a larger company, you’d have many teams of many people doing these things so their perspective would be detailed but not cohesive. If you ask a small startup how they do GRC it would be closer to my perspective - it’s reactive and scrapped together - “this customer said we need to get SOC 2 certified so we bought Drata and got our least favorite employee to work with an audit firm”. The innovation happens between [big and established] and [small and scrappy]. It’s where I’m at - how do we build a top-tier GRC function with limited resources?
Spoiler alert - “it’s an art not a science. Like great art, you would draw inspiration on the old while embracing the new”.
- Jack R, guy who cares too much about compliance
There’s so much hype in the GRC space right now - the Drata’s and Vanta’s getting clout, a crazy amount of new initiatives and frameworks (essential eight, NIS2, ISO42001, the new CMMC rule, US privacy laws, etc..), people asking me all the time “how can we automate compliance”, everybody has an idea for a new product but no one is giving good info about how to do the job. If you try and figure it out yourself, you’ll go down a rabbit hole of compliance frameworks and shit like “how to conduct a risk assessment” or “establishing an audit program” - while there’s unlimited info and products to help, there isn’t a soul offering a modern strategy to understand these new tools, work agile and efficient, but without sacrificing the real reason you’re doing it…. which is to ultimately make sure there’s good and stable internal controls. I’m going to break down the smoke and mirrors with the THE MODERN AUDITOR MANIFESTO. Some people are already calling it blog of the year. Substack hit me up and said people need to know about this.
PART 1: GRC = INTERNAL AUDITOR
GRC stands for “governance, risk, and compliance” - but what does that mean on day 1? Let’s say you just landed a job as Head of GRC at a small SaaS startup. What is your f*cking job? And that’s not my mom asking it, that’s me asking it.
80/20 rule…phase:
Like I said above - a startup is going to be reactive and scrapped together when it comes to GRC. 80% of what you COULD be doing is probably not going to make the slightest difference so in the day 1 phase you’re looking for the 20% good use of time - a low hanging W that drives an impactful outcome. Being real - you’re going to lead the company through it’s first SOC 2 Type 2 audit, get the report, and boom… sales enabler.. the mandatory ticket to jump on the SaaS train. You’re a temporary hero - the SOC 2 is your 20%.
Internal audit could be sick but at what cost
If you’re still following this - the SOC 2 Type 2 is the most important early W a GRC team can get. So that means your job as Head of GRC is first and foremost an auditor. You are technically an internal auditor because you are gathering all this evidence to get it into a tool for your external audit firm to inspect. The market has well identified this problem and spit out a ton of products. This is compliance-in-a-box. A SaaS tool that has all of the controls in a framework mapped for you and points at what tools to connect to get you evidence. As you advance the GRC program you add other frameworks like ISO27001 or PCI DSS and the compliance tool is going to link the work you’ve done for SOC 2 in the new framework - saving a ton of repeated work and brain power because now you don’t have to think about these idiotic frameworks all you have to do is use your tool which is a glorified checklist exercise.
The difference between compliance-in-a-box and a traditional internal audit program
Compliance-in-a-box is going to offer you a guide on how to paint the picture of a control with evidence whereas an internal audit is typically a time-intensive, resource-intensive process where you look at the design and effectiveness of your controls, create custom ways to review the control activities, and heavily document all that you did in hopes that leadership will give a shit about what you found.
Let’s look at a fictional example from SOC 2:
Compliance-in-a-box
Control Description - AICPA’s description of the control coming right from the SOC 2 guidance.
Control Implementation - Your own description of how your organization carries out the control (in this case describing how you do access provisioning).
Requirements - Pre-populated suggested pieces of evidence to look at.
List of users with access to database: Showing a list of users that have access to the database of your product. It’s in here because the compliance tool offers an integration with the database vendor so this is what the market is considering “compliance automation” in that an API call is going to continuously pull in evidence of this user listing.
List of users with access to Infrastructure: Similar to 1 - just pulling in users from an AWS IAM integration on a continuous basis.
User access request tickets: Up to you to upload or connect - likely you would show an example of an access request ticket (how it’s designed - probably showing a ticketing system like Jira). You could also go a step further and bring in ALL of the access request tickets that have been made over the audit period.
Analysis of compliance-in-a-box example
In 2024, what we see above is really all it’s going to take to pass an audit. You used a tool to show you have evidence for a control. You have multiple pieces of evidence that are collected on a continuous basis. Only a well-seasoned, more expensive, auditor is going to poke holes in this. It wasn’t time intensive to populate this info and you’ve got enough to accomplish your objective (get SOC 2 to enable sales).
BAD NEWS: What your missing with this approach is basically all of the important things. The auditor doesn’t know your company, only a few employees in the company really know your company, and because of this there is an immense amount of detail missing to achieve true assurance that this control is doing anything. Compliance-in-a-box doesn’t force you to think about other systems in scope. In this example, you could have an observability tool that allows people with access to query sensitive information about the application, users, data, etc.., you have completely missed privileged access requests to the application itself (as in the the application your SaaS company is providing to customers) like for your support team that has god level access to production environments. Except for firms like Schellman (probably some others but definitely not most), auditors don’t really ask additional questions about the scope and it’s getting worse and worse as the market becomes even more saturated with audit firms. Even if they did ask some follow up questions, you can literally know nothing and say something like “this is who has access to production” and that’s all she wrote.
to continue…
No one is necessarily cross checking the access requests tickets to the date that each user was provisioned on each system so you have no proof that “an access ticket is put in before access is granted”. There is no detail regarding who is allowed to approve access for each system and furthermore who is the restricted group allowed to actually provision the account on the respective system. Sure, you could technically put this immense detail in the little description box but these products are obviously not designed to go into that level of detail. They ARE designed to connect to a bunch of your tech stack to give the illusion of automated compliance. In many specific cases they make automated compliance a reality. For instance, you can see that users have MFA enabled on their account through an integration and that’s great.
NOTE: There are products like Auditboard that allow you to go into a great amount of detail about internal narratives and interviews, testing strategies, etc.. but they’re serving a different part of the market (a large company with an internal audit team of 20+ might use auditboard or equivalent).
Traditional Internal Audit Approach
Too long to explain in detail but general knowledge would say if you want to audit something like access requests tickets that would be included as control in an internal audit engagement. The general guidance to conduct an internal audit is first:
Making a detailed audit plan that outlines the scope, criteria, timeline, and resources
Schedule interviews with people carrying out the control
Review policies and procedures
Develop a test plan and testing attributes
Inspect the evidence and look for exceptions or findings
Document a bunch of shit
This is already taking too long
No one is going to care unless something bad happens
How would anyone at a SMB have time to do this without a team of at least 10
Striking a balance between not enough and too much
The best position to innovate is one where you need to do things efficiently and you know what a quality job looks like.
You DON’T need to do a full fledged internal audit to review controls in adequate detail.
You DO need to do more than put evidence in a compliance tool with 0 rhyme, reason, or intention.
The modern auditor approach
In order to make a sound control environment you need to abstract the control activities away from the framework. If you’re just starting to build a control environment for the company there’s no shame in following the controls of SOC 2 Type 2 but you need to do more than just blindly put evidence in a tool.
Step 1: Create a one-page “Control Overview” in your company knowledge base
This first step indeed will be annoying and time consuming but will lay the foundation of your GRC program and save a ton of time in the long run. A control overview is my version of a policy and procedure combined. It’s basically one brief document explaining all the relevant information for all parties. There’s not a one-size fits all of what this looks like. Here’s a general example.
Why is this important?
It’s more specific than a policy
With adequate context it will explain the who, what, where, why, and how to get evidence for the next external audit
It’s framework agnostic, meaning you can plug in this activity like a lego block to any audit framework you want. NOTE: still included a general control family for basic organization purposes (more on that in part 2)
How else can it help?
Once you get this detailed enough you can ingest this into a knowledge base to help answer security questionnaires
This makes the program turnover proof - instead of having the next person try and piece together old evidence in the tool
Using the lego block idea again - you can basically audit the control ad-hoc based on what’s written - no need to make a bunch more testing documents.
If you’re a next gen absolute compliance legend you could take what you’re doing in the “how do we test it” and ACTUALLY automate the process.
Automation Tangent - skip next paragraph unless you also drink 4+ cups of coffee a day among other things
In a perfect world you could use something like Swimlane to glue together the employee email on the access ticket and cross check the email to the respective user listing of that system creating an audit record when there’s a match indicating a “passing” occurance of the control. Or the opposite, pulling a user listing with user creation dates over the last week and then querying the ticketing system to ensure an access request was made for that same email. If no match a record would spit out as a finding and notify the GRC analyst for follow up. (« if you can follow that kudos. That level of automation is absolutely possible with today’s tools. Only the brave would attempt though.
PART 1 CONCLUSION:
GRC at its core is being a good internal auditor for the org
Compliance tools can help you get easy external wins but you’re building the program on a house of cards if you only rely on said tool
Think agile and don’t spend too much time over-documenting internal audit activities
Build control overview 1 pagers outside of the compliance tool to help build a better foundation for the control environment
There are many levels to “compliance automation” but if you don’t understand what your automating it means absolutely nothing.