Okay, so I’ve been knee-deep in our company’s SOC 2 Type II prep for the last six months, and I kept hearing “just use Drata, it automates everything.” But I’m the kind of person who needs to open the hood and see the gears turning, you know? 😅 After living with it daily, I think I can break down what it *actually does* during the audit process in a way that’s less marketing-speak and more… mechanical reality.
In the simplest terms, Drata isn’t the auditor. It’s your continuous evidence-gathering and policy-enforcement machine that feeds the auditor. The auditor still makes the final judgment, but Drata tries to make 80% of their job a verification exercise instead of a scavenger hunt. Here’s what that looks like in practice:
* **It acts as a persistent, automated evidence collector.** This is the biggest chunk. Instead of you manually taking screenshots of AWS configs, exporting Google Workspace login reports, or proving your code is in GitHub, Drata has pre-built “integrations” (they call them Monitors) that ping these services daily or weekly. It pulls in things like:
* User access reviews from your HR platform (like Okta or Azure AD)
* Cloud security group configurations from AWS/Azure/GCP
* Vulnerability scan results from tools like Snyk or Qualys
* GitHub branch protection rules and commit histories
* It stores this evidence, stamps it with a date, and links it directly to the specific SOC 2 control it satisfies.
* **It turns policies into enforceable, testable rules.** You upload your “Access Control Policy” into Drata. Then, you don’t just hope people follow it—you configure Drata to check. For example, if your policy says “all employee laptops must have disk encryption,” Drata’s integration with your MDM (like Jamf or Intune) will continuously check every device and flag any that aren’t encrypted. A failing check becomes a task in someone’s queue to fix. The auditor can see the policy, the automated test, and the historical record of passes/fails.
* **It creates a single, living audit trail.** Every piece of evidence, every policy acknowledgment by an employee, every completed risk assessment, and every exception logged is woven into a timeline. When the auditor asks “Prove you reviewed user access in Q3,” you don’t scramble through email. You pull up the Drata timeline, show the automated collection of the Okta report, the review task that was assigned to the manager, their completion, and any follow-up actions. It’s all timestamped and unchangeable.
The “during the audit” part is really about the auditor logging into your Drata portal (they get a read-only view) and doing their fieldwork there. They can navigate by control (CC6.1, CC7.1, etc.) and see all the linked evidence, tests, and policy documents in one place. Your job shifts from frantic evidence compilation to explaining contexts and handling the exceptions Drata couldn’t auto-verify (like interviewing employees for the “tone at the top” stuff).
It’s not magic—you still have to configure it correctly, triage the fails, and manage the human elements. But it changes the process from a chaotic, quarterly fire drill into a managed, continuous workflow. It’s less about *doing* the audit for you and more about making your entire operation inherently auditable all the time.
Hope that demystifies it a bit! Would love to compare notes on setting up specific monitors or which ones tend to be the most finicky.
—Jake
Spreadsheets > opinions