How to handle a control that Drata says is auto-monitored but the auditor disputes

This is a classic FinOps-adjacent problem: a tool's automated compliance assertion versus a human auditor's interpretation. I've seen similar patterns with AWS Config rules where the console says "compliant," but an auditor requires specific evidence chains the tool doesn't produce.

In the context of Drata, if a control is marked as auto-monitored (e.g., "MFA enabled for all IAM users") and the auditor disputes it, you're typically facing one of three gaps:

* **Evidence Granularity:** Drata's automated pull from your IdP (like Okta or Azure AD) might confirm MFA is "enabled" at a policy level, but the auditor wants proof for *each individual user account*. The auditor may be looking for a per-user report, not a system setting.
* **Sampling vs. Full Population:** The auditor might have sampled a few user accounts manually and found exceptions (e.g., service accounts without MFA), while Drata's automation is checking the overarching policy. The control's scope in Drata ("all IAM users") may not align with the auditor's test of a random sample.
* **Timing & Freshness:** The evidence snapshot Drata captured and presented for the audit period might be from a weekly sync, while the auditor's manual check was performed at a different time. A configuration change in that window creates a discrepancy.

The resolution is procedural and technical. You must treat Drata as a data source, not the single source of truth. My approach is:

1. **Immediately document the discrepancy** in your audit trail. Note the control ID, the auditor's specific finding, and the exact point of contention.
2. **Bridge the evidence gap manually.** For the disputed control, generate direct evidence from the source system that meets the auditor's criteria. For the MFA example, run the authoritative CLI command or generate a report the auditor will accept.
```bash
# Example: AWS CLI command to list all IAM users and their MFA status
aws iam list-users --query "Users[*].[UserName]" --output text | while read USER; do echo "User: $USER"; aws iam list-mfa-devices --user-name "$USER"; done
```
Attach this output, timestamped, to the control in Drata as a manual evidence upload.
3. **Engage Drata support** to clarify the control's exact monitoring logic. Ask: "What API endpoint or check does this auto-monitored control query? What is the exact frequency?" Use this to explain any sampling or timing differences to the auditor.

Ultimately, you are responsible for the control's state, not Drata's dashboard. The tool reduces workload, but you must be prepared to validate its assertions with raw data. Consider this a requirement for your control implementation documentation.