Hi everyone! I've been tasked with helping my team get a better handle on how we track exceptions and risk acceptance workflows in Drata. We're migrating a lot of our manual compliance checks into the platform, and I'm feeling a bit lost in the weeds.
From what I can see in our instance, exceptions can be attached to controls, but I'm not entirely clear on the *best practice* for managing them at scale. We have a few recurring scenarios:
* A temporary exception for a system that's being decommissioned next quarter.
* A known risk we've formally accepted because the cost to fix it is too high.
* Failed automated tests that need a human to review and mark as "okay" for a specific reason.
Right now, it feels a bit scattered. We're adding notes to controls, but I'm worried about losing the audit trail. My main questions are:
* Do you create a separate "Exception" for every single instance, or do you group similar risks under one?
* What's the best way to document the approval? Just the Drata task completion, or should we link to an external document (like a signed PDF from security)?
* How do you make sure these exceptions get reviewed regularly and don't just sit there forever? Is there a good way to set reminders or tie them to a periodic task?
I'd really appreciate any screenshots of how your team has this set up (blur out any sensitive stuff, of course!). I want to make sure we build a process that's clean for the engineers and also makes our auditors happy later.
Thanks in advance for helping a newbie out
null
I manage compliance for a 200-person fintech. We've had Drata in production for 18 months tracking about 400 controls.
**Core Breakdown**
- **Exception Volume vs. Grouping:** Create a separate exception for every unique instance. Drata's audit trail links to the specific control evidence and test failure. We tried grouping similar risks under one umbrella exception and our auditor flagged it because the approval dates and context didn't match for each control.
- **Approval Documentation:** Use the Drata task for workflow, but attach the formal approval document. We link the signed PDF from our risk council in the "Supporting Documents" field of the exception. The completed task shows who approved it and when, the PDF shows the why.
- **Review Cadence Enforcement:** Drata doesn't auto-expire exceptions. We set a mandatory review task in the exception notes with a due date 90 days out. We also tag our #compliance Slack channel monthly with a report of all open exceptions.
- **Scale Limitation:** The main UI breaks down around 50+ active exceptions on a single control. The list becomes sluggish. For a system decommission with dozens of affected controls, we create a parent policy document externally and attach it to each individual Drata exception for reference.
**My Pick**
I'd recommend sticking with Drata's native exceptions but implementing a strict one-exception-per-instance rule with documented review tasks. If your exception volume is low (<10 per control), this is clean. If you're dealing with hundreds, tell us your average exceptions per control and whether you're SOC 2 or ISO 27001.
Benchmarks don't lie.
Great question, and your three recurring scenarios are spot on for where formal exceptions become necessary. Based on managing a similar volume, I strongly agree with user518's point on creating a separate exception for every unique instance. The audit trail is the primary reason. If you group risks, you'll lose the granular linkage between the specific control failure, its evidence, and the individual approval context, which auditors will absolutely scrutinize.
For your approval documentation question, the Drata task alone is insufficient as a formal record. We also link to an external document, but we go a step further by storing the signed approval in our centralized document management system and then pasting that immutable URL into the exception's description field, not just the supporting docs area. This creates a more direct narrative line for an auditor reading through the exception rationale.
Regarding review cadence, Drata's lack of auto-expiry for exceptions is a key gap. We mitigate this by using calendar integrations from the task assignments to schedule mandatory quarterly reviews in our GRC calendar. Any exception without a review task updated in the last 90 days is flagged in our weekly sync. It's a manual overlay, but it prevents anything from sitting dormant.
Support is a product, not a department.
Great questions - that scattered feeling is a real red flag for audit time.
On the grouping question, I have to echo the others: *always* create a separate exception for each instance, even if the root cause seems similar. I learned this the hard way when an auditor asked for the compensating control evidence for a specific EC2 instance, and it was buried in a group exception with five other instances. Took hours to untangle.
For approval docs, we embed a direct link to the Jira ticket (or PDF) in the exception description. The Drata task shows the workflow, but the link provides the full business rationale. Makes reviewer's lives easier.
Your point about reviews is key. We set a mandatory maximum review period (like 90 days) for every exception. The renewal task forces a conversation - either the risk is still accepted, or it's time to fix it. It's a pain to enforce manually, but it stops exceptions from becoming permanent blind spots 😅
security by default
>mandatory maximum review period
This is a great idea. We've been struggling with exceptions that just never get looked at again.
How do you actually enforce the 90 day renewal? Is it a manual calendar reminder for someone, or have you built something to automate it? Drata doesn't seem to have a built-in expiry from what I can tell, so I'm curious about the practical step.
Containers are magic, but I want to know how the magic works.
Ah, the eternal struggle of enforcement. The "mandatory maximum review period" is an excellent principle, but like most good ideas in GRC, it's fragile without a forcing function.
You're right, Drata doesn't have native expiry. That means the renewal is only as reliable as your noisiest manual process. We tried calendar reminders. They got ignored. We tried Jira tickets. They got deprioritized.
What finally stuck? We made the renewal task a prerequisite. If an exception lapses, the associated control is automatically flagged as "failed" in our weekly compliance dashboard, which goes straight to the CISO and the audit committee. Suddenly, the control owner is highly motivated to renew, because a red mark on that report requires a written explanation to leadership. It's a bit of a Rube Goldberg setup using their API and a simple script, but it works because it attaches real consequence.
Without that teeth, your 90-day rule is just a suggestion written in sand.
cg
I've seen this exact principle work, but it relies on a robust metric. Flagging the control as "failed" is effective, but only if your dashboard is the single source of truth for leadership. If they get status from five different places, the pressure dissipates.
We take a similar API-driven approach, but we tie the consequence to budget. An expired exception on a cloud security control, for example, triggers an alert that suspends the related IAM role's permissions. The financial and operational impact (a deployment pipeline halts) gets renewal attention within hours, not weeks. It's more aggressive, but for high-risk items, the forcing function must be immediate.
Less spend, more headroom.
Your point about the immutable URL in the description is crucial for audit integrity. The supporting docs field can feel like an afterthought, while the description is the primary narrative an auditor follows.
I'd add a technical caveat: the reliability of that "immutable" link depends entirely on your document management system's retention policy and access controls. If the URL structure changes or permissions aren't locked down, you've introduced a single point of failure in that audit trail. We had an issue where a DMS migration broke deep links; we now also store the document hash in a custom exception field for verification.
sub-100ms or bust
That's an excellent point about document system integrity being the foundation of an "immutable" link. Storing the hash is a smart forensic layer for verification.
It also highlights a related architectural risk, the platform dependency itself. If your document management system has an outage or a major version change that breaks APIs, your entire exception audit trail becomes inaccessible during a critical audit window. We mitigate this by having a secondary, read-only cold storage bucket that mirrors all approval documents with a predictable key structure, and we note that backup location in the control's notes. The primary link is for convenience, but the backup path is the fail-safe.
Plan the exit before entry.
Ah, the >manual calendar reminder... we tried that. It quickly becomes background noise.
What worked for us was linking the exception renewal to our quarterly SOX reporting. If an exception is past its 90-day review, the control it's linked to automatically drops to "At Risk" status on the report that goes to the audit committee. That visibility creates a powerful, organic forcing function without any extra tooling.
The key is making the consequence visible to people who care about compliance status, not just the control owner.
Cheers, Henry