Skip to main content
{ Reporting and Compliance }

Drata Failing Monitor Triage

Sorts each failing Drata monitoring test into a real control gap, a broken connection, or a resource outside the audit boundary, and proposes the fix with the evidence.

What this agent does

This read-only agent triages the monitoring tests that fail or error in Drata. For each failing monitor, it reads the failing resources and the connection that reported them. It checks each resource in the connected system when I grant read access. It decides whether the failure is a real control gap, a connection that stopped working, a resource that no longer exists, or a resource outside the audit boundary. It proposes the fix for each one and names the owner. A person makes every change.

The challenge

Drata turns a monitor red for every resource that fails it. One failing monitor can be one unencrypted volume, or every resource behind a connection that lost its role. A service account that cannot enroll MFA fails the MFA test, and the right answer is to exclude it with a reason, not fix it. Someone clicks through each monitor the week before the audit and decides from memory.

The solution

The agent separates the failures by cause before anyone opens Drata. It groups resources that fail for one reason, such as one broken connection, into one item. It proposes an exclusion only with a reason the auditor would accept, and it never excludes anything itself. Provides a short list of real gaps with owners, and a separate list of cleanup items.

Workflow

  1. 01

    Read failing monitors

    Read the monitors in the failed or error state with the controls and frameworks they support and the connection that runs them.

  2. 02

    Read failing resources

    Read the failing resources for each monitor with their identifiers and the time each one started failing.

  3. 03

    Check the source

    Where I grant read access, check each resource in the connected system to confirm the failure, confirm the resource still exists, and read its tags.

  4. 04

    Classify and propose

    Classify each failure as a real gap, a broken connection, a gone resource, or an exclusion candidate, and propose the fix with the owner.

  5. 05

    Report

    Publish the grouped list with the evidence for each item.

Agent template 

# Drata Failing Monitor Triage

## Measurable outcomes

Every failing or erroring monitor in Drata has a cause, a proposed fix, and an owner. Every exclusion proposal has a reason an auditor would accept. Track the triaged, real gap, broken connection, gone resource, and proposed exclusion counts on every run. The real gap count falls as owners fix resources.

## Procedure

Each run, read the monitors in the failed or error state for the frameworks I set. For each monitor, read the controls and frameworks it supports, the connection that runs it, and its remediation guidance. Read the failing resources with their identifiers and the time each one started failing. Check the connection. When it is disconnected, has not synced in 24 hours, or reports an error, classify every failure behind it as a broken connection and name the connection as the fix, unless I set another window. When I grant read-only access to the connected system, look up each failing resource. Confirm the condition the monitor describes, such as a volume with no encryption or a user with no MFA. A resource that no longer exists is gone. Recheck it on the next run, and report it as a sync problem when it persists. Read the resource's tags and environment. Propose an exclusion only when the resource is a non-production resource outside the system boundary I define, or a resource the monitor does not apply to, and write the reason the auditor would read. Never propose it for a production resource the monitor covers. Everything else is a real gap. Name the owner from the resource's owner tag or the control owner in Drata. Group resources that fail for one reason into one item with one fix. Rank real gaps by how long they have failed, oldest first. Never disable a monitor, exclude a resource, or change an owner in Drata.

## Requirements

It needs a Drata API key with read access to monitors, controls, frameworks, assets, and connections, and optional read-only access to the connected cloud, source code, and identity systems, and nothing more. It never changes anything in Drata or in a connected system. Tickets name the resource and the owner so a person can act. Reports show user names as stable pseudonyms.