The first month of a Drata implementation usually goes well. Integrations connect, tasks close themselves, and the readiness score climbs fast enough that leadership starts asking when the audit can be scheduled.
The trouble shows up later, and it usually shows up as a question. An auditor asks when a specific person's access was removed. Not whether offboarding happened, but when, and where that is written down.
Those are different questions, and the gap between them is where a lot of first-year SOC 2 programs get into trouble.
Green checks are not evidence
A compliance platform reports the current state of the systems it can reach. It tells you that MFA is enforced today, that no accounts are dormant today, that encryption is on today. That reporting is genuinely useful and it replaces a large amount of manual work.
An auditor is asking something else. They want to know what happened in March, in which system, who approved it, and whether the same thing happened the other eleven times it should have. The evidence they want is historical and event-specific, and it has to hold up when they pick a name from a list and follow it through every system in scope.
Those two things overlap. They are not the same thing, and the overlap gets thinner the further you get from the identity provider. Termination shows up cleanly in Entra ID. It shows up less cleanly in the CRM that a sales manager provisions by hand, the vendor portals with individual logins, and the shared password vault that half the company treats as optional.
The dashboard is accurate about what it can see. Scope is the part nobody checks.
Movers are harder than joiners and leavers
Onboarding and offboarding are discrete events with clear triggers. Someone starts, someone leaves, and both generate a record in the HR system that a compliance platform can act on.
Role changes have no such trigger, and this is where we see programs come apart.
Drata will sync updated personnel information from connected identity and HR systems, so a new department or job title flows through correctly. It does not, on its own, perform an access review or remediate permissions when someone changes roles. That capability is the paid User Access Review feature. Without it, the platform records that the person's department changed and stops there.
Everything that matters about a role change therefore happens outside the platform. Someone has to determine what access the employee should lose and what they should gain, make those changes in each affected system, validate that the changes took effect, obtain approval where the control requires it, and retain the evidence. Drata will hold that evidence once it exists. The organization has to run the process that produces it.
The reason this compounds is that nothing about a role change is alarming in the moment. A promotion adds access. A transfer adds access. Each grant is legitimate when it happens and no individual decision looks wrong in review. Three years later someone in finance holds standing permissions from two prior teams, and the first time anyone examines it closely is when an auditor pulls their name at random.
A control can exist and still fail
The most common finding we see is a control that technically operates but was never designed to be tested.
A company configures automated evidence collection for user termination reviews. The integration works, the evidence accumulates, and the task closes on schedule. What is missing is a defined offboarding process that revokes access consistently across every system in scope. The platform accurately reports that data is being collected. The auditor determines the control is ineffective, because collecting evidence of an inconsistent process is evidence of an inconsistent process.
Designing a control that survives testing means answering a short list of unglamorous questions before the automation is switched on. Who owns it. How often it runs. What specific artifact counts as evidence. What happens when the control cannot be met. Whether the review frequency matches how fast the environment actually changes.
None of those are configuration settings. They are decisions about how the business operates, and a platform cannot make them on your behalf.
Undocumented exceptions cause findings, not exceptions
Every environment we work in has conditions that cannot be brought into compliance on the ideal timeline. A legacy application that does not support SSO. A vendor who needs temporary elevated access. A patch that cannot be applied during quarter close.
Auditors expect this. A well-run compliance program has exceptions in it, and their presence is not a problem on its own.
What causes findings is an exception nobody wrote down. The compliance platform is often the first thing to detect these conditions, and detection creates the impression that they are being managed. Managing an exception means recording what the risk is, who accepted it, what compensating control is in place, and when it gets reviewed again. A platform can flag the condition and remind you it is still open. It cannot decide that the business will tolerate the risk for two more quarters, and it cannot sign that decision.
Where we start
We do not begin a Drata engagement in Drata. We begin by mapping controls to how the business actually operates, and the first week produces three things.
A spreadsheet of controls with a named owner for each one. Not a department, a person. Ownership that stops at a team name is ownership that nobody exercises.
A list of controls that do not apply, with the reason each was scoped out. This is the part organizations skip, and it costs them. Controls left in scope because nobody wanted to make a decision become tasks that sit open, alerts that get dismissed, and eventually an audit conversation about why a control was never operating.
A conversation with the CTO about which systems are genuinely in scope. This is usually the meeting where the shared vault, the CRM, and the two vendor portals nobody has thought about in a year come up for the first time.
After that, the platform gets configured against a picture of the environment that matches reality, rather than a picture assembled from whatever the integrations happened to reach.
The useful version of the tool
Compliance automation earns its cost. It removes manual evidence collection, it catches configuration drift faster than a person will, and it gives lean teams a way to run a program that would otherwise consume someone full time.
It works when there is a defined process behind each control it monitors, an owner who can explain that process to an auditor, and a documented answer for every place the environment departs from the ideal. The platform then becomes what it is good at being, which is a system of record for a program that already exists.
Buying it first and hoping the program forms around it is the version that produces a high readiness score and a difficult audit.
If you are running Drata and cannot say with confidence who owns each control or which systems are actually in scope, that is the work worth doing before the audit is scheduled. We can help with it.