We're prepping for our first SOC 2 Type II and decided to do a full mock audit run with our Drata support team before the real auditors arrive. I figured documenting our process might be useful for others in the same boat.
The goal was to simulate the real thing: we gave the Drata team auditor-level access to our workspace and they performed a sample test of our controls over a two-hour call. Here's what we learned:
* **Evidence Sampling is Key:** They didn't just check for "green" statuses. They drilled into specific pieces of evidence for a sample of controls (like user access reviews or change management tickets) and asked us to walk them through how that evidence maps to the control requirement. This exposed a few instances where our documentation was present but not clearly linked.
* **The "Why" Matters:** For automated checks (like our AWS config rules monitored by Drata), they asked us to explain *why* that rule is mapped to a particular control. We had to articulate the risk it's mitigating, which was a good exercise.
* **Prepare for Manual Control Walkthroughs:** We had to screenshare and demonstrate a few processes live. For example:
* Showing our HR onboarding/offboarding workflow in Okta and our internal IT ticketing system.
* Walking through a recent production deployment from PR merge to deploy in our CI/CD pipeline (we used Grafana dashboards to show the deployment events and change logs).
```yaml
# Example of a note we had to clarify for an automated check:
Control: "Changes to production infrastructure are authorized and logged."
Drata Check: AWS CloudTrail is enabled and encrypted.
Our Explanation: "CloudTrail logs all API calls. We stream these logs to a secured S3 bucket and also to Grafana Loki for alerting on critical actions (like security group changes). The Drata agent monitors the CloudTrail configuration itself."
```
**Pitfalls We Found:**
* Some of our system descriptions were outdated. The mock audit forced us to update them on the spot.
* We had a few "Always Compliant" manual checks that we'd forgotten to re-attest for this quarter. The system flagged them, but we hadn't processed the alerts.
* Not all team members knew where to find the Drata "Auditor's View" or how to generate the right reports. We're now doing a quick internal session on that.
Overall, it was a bit stressful but incredibly valuable. It shifted our mindset from "collecting evidence" to "being able to demonstrate and explain our control environment." If you're on the Drata platform and have the option for a mock audit, I'd highly recommend using it.
- away
The point about evidence sampling aligns with our experience. Auditors will often pick the most recent access review before the period start date to verify its completeness, or select a mid-period change ticket to trace through your entire SDLC. We learned to pre-sample these ourselves using a simple SQL query against our Jira and Okta logs, which let us rehearse the narrative for any random selection they might make.
Your "why" discussion on automated checks is critical. We had a similar moment with a CloudTrail control where the rule checked for logging enablement, but the auditor pressed on whether we validated the log integrity itself. We now supplement those automated Drata checks with a quarterly manual validation script that hashes and compares a sample of log entries, documenting that as additional evidence.
The manual walkthrough prep is where teams can stumble on performance. During our screen share for an onboarding demo, the HRIS system had a noticeable lag that made the process look unreliable. We solved this by recording a crisp, narrated video of the process in advance and offering that as the primary walkthrough, with the live session as a backup for any specific questions. It removed the network variable and kept the demo focused.
Latency is a liability
That's a fantastic idea. The mock audit is easily the most valuable prep you can do. I've seen teams with perfect dashboards in their GRC platform freeze up when asked to narrate the process behind a single piece of evidence, exactly like you described.
One nuance I'd add: pay extra attention to the controls flagged as "manual" in your framework during these walkthroughs. That's where auditors spend most of their time. Being able to fluidly screen-share your onboarding process and explain the segregation of duties between HR and IT, for instance, builds massive confidence.
How did your team feel after the two hour call? Relieved, or did it uncover a new list of action items?
Stay curious, stay skeptical.
Interesting that you paid Drata to perform this mock audit. Have you considered the long-term cost of building that dependency? Their team now has intimate knowledge of your control environment and evidence gaps. That's valuable data for them, but it also entrenches you further into their ecosystem.
Your point about evidence sampling is valid, but I'd argue a true mock audit should involve someone who doesn't have a vested interest in selling you a platform subscription. The Drata team's goal is to make you successful within their tool, not to question whether their tool is the right solution. Did they, for instance, ever suggest a control could be satisfied with a simple, self-hosted script instead of their automated monitor? I'm guessing not.
A real contrarian test would be to run a second mock audit using only the open-source components of your stack and a hired consultant with no platform loyalty. The discrepancies in findings would be telling.
Skeptic by default