How to Automate Evidence for "Not Monitored" Controls in Drata

If you use Drata for SOC 2 or ISO 27001, you know the dashboard reality. You connect AWS, GitHub, and your HR system, and watch the progress bar shoot up to 85%. Those are your monitored controls. They are green, happy, and automated.

Then there is the other 15%. The "Not Monitored" controls.

These are the controls where Drata has no integration. They cover your custom admin panels, physical security workflows, specific vendor reviews, and manual change management processes. For these, Drata is essentially a file storage bucket. You have to manually capture screenshots, log in to Drata, find the specific control, and upload the evidence file. Week after week.

This article explains how to automate evidence collection for "Not Monitored" controls in Drata, moving them from manual busywork to fully automated workflows using screenshot capture tools and the Drata API.

What Are "Not Monitored" Controls in Drata?

In Drata, a control is "Not Monitored" when it is not linked to an automated test from a native integration.

While Drata integrates with major SaaS providers (AWS, Google Workspace, Jira), it cannot see inside:

1. Custom Internal Tools: Your back-office admin panel where customer support agents grant refunds or reset passwords.
2. Legacy Systems: On-premise servers or older software that lacks a clean API.
3. Visual Workflows: Processes that require human judgment, like reviewing a vendor's security page or verifying a physical office visitor log.
4. Specific SaaS Tools: Any SaaS product Drata doesn't officially support yet.

For SOC 2, this often affects critical criteria like CC6.1 (Logical Access) and CC8.1 (Change Management). You might have a policy that says "Access to the SuperAdmin panel is reviewed quarterly." Since Drata can't connect to your SuperAdmin panel, you have to screenshot the user list manually and upload it.

Why Can't Drata Automate These Natively?

Drata works by querying APIs. If a system has a standard API (like AWS IAM), Drata can pull the configuration data (JSON) and validate it against a rule.

But auditors often require visual evidence (screenshots) for systems where API data is insufficient or unavailable. An auditor wants to see the actual "Access Denied" screen, or the specific UI toggle that proves MFA is enforced on a tool that doesn't export strict logs.

Drata does not have a "browser" engine. It cannot log in to your web app, navigate to /admin/users, and take a screenshot. It relies on you to act as the bridge between the system and the evidence library.

How to Automate Evidence for Custom Controls

You can automate "Not Monitored" controls by treating evidence collection as a code problem rather than a manual task. There are three primary ways to do this.

1. The "Custom API Integration" Method (High Effort)

Drata offers a public API that allows you to push evidence programmatically. You can write a script that queries your internal system's database, generates a CSV or JSON file of users, and pushes it to the Drata endpoint.

Pros:

• Clean data directly from your database.
• Fully automated once built.

Cons:

• Engineering tax: You have to build and maintain a custom script for every single manual control.
• Auditor pushback: Auditors often prefer screenshots over raw CSV dumps because CSVs are easily manipulated. A JSON file from your own database is less convincing than a screenshot of the system settings.

2. The "Browser Automation" Method (Medium Effort)

You can use tools like Puppeteer or Playwright to write scripts that log in to your portals, take screenshots, and save them.

Pros:

• Captures the exact visual evidence auditors want.

Cons:

• Maintenance nightmare: If a UI selector changes, your script breaks.
• Security risk: You have to manage service account credentials for your automation scripts.
• No direct upload: You still have to figure out how to get those screenshots into Drata (usually by combining this with Method 1).

3. The "Evidence Automation Platform" Method (Recommended)

This approach uses a dedicated tool (like Screenata) designed to capture compliance evidence. These tools connect to your custom applications, navigate through the workflows required by your controls (e.g., "Show me the user list," "Show me the MFA settings"), capture timestamped screenshots, and automatically push them into Drata's evidence library linked to the correct control.

This effectively turns a "Not Monitored" control into a monitored one. The "test" is performed by the external agent, and the result is pushed to Drata.

Step-by-Step: Automating a "Not Monitored" Control

Let's look at a real-world example: User Access Review for a Custom Admin Panel.

The Manual Process:

1. Set a calendar reminder for "Quarterly Access Review."
2. Log in to the Admin Panel.
3. Navigate to the "Users" tab.
4. Take a screenshot of the active users.
5. Log in to Drata.
6. Go to Control DCF-22 (or similar).
7. Upload the screenshot.
8. Mark the request as complete.

The Automated Process:

1. Map the Control: Identify the URL in your admin panel that shows the user list.
2. Configure the Agent: Set up an automation workflow (using Screenata or a custom script) to visit that URL.
3. Link to Drata: Map the output of that workflow to the specific Drata Control ID.
4. Schedule: Set the frequency (e.g., Weekly or Quarterly).

Now, when the schedule triggers, the system captures the evidence, timestamps it, generates a PDF, and pushes it directly into the Drata Evidence Library via API. In Drata, you simply see new evidence appear, ready for auditor review.

Where Traditional Drata Automation Stops

It is important to understand where the native Drata automation ends and where you need to layer in additional tools.

Feature	Native Drata Automation	Screenata / Evidence Automation
Cloud Infrastructure	Excellent. Connects to AWS/Azure/GCP APIs automatically.	Not needed (Drata handles this).
SaaS Settings (GitHub/Jira)	Excellent. Checks branch protection and ticket workflows.	Not needed (Drata handles this).
Custom Admin Panels	None. "Not Monitored" / Manual Upload only.	Full Automation. Logs in, screenshots, and uploads.
Visual UI Verification	None. Cannot see or interpret UI elements.	Full Automation. Captures and validates UI states.
Vendor Security Pages	None. Requires manual PDF upload.	Full Automation. Visits vendor trust centers and captures proof.
Evidence Format	JSON / API Data.	Visual Screenshots (PDF/PNG).

What Evidence Do Auditors Actually Accept?

When you automate "Not Monitored" controls, the quality of the evidence matters. You cannot just upload a text file saying "Checked it."

For a screenshot to be accepted by a SOC 2 auditor, it must include:

• System Time: The clock must be visible in the screenshot to prove when it was taken.
• URL Bar: The URL must be visible to prove where it was taken.
• Context: The screenshot must show the relevant settings (e.g., the column showing "MFA: Enabled").

If you build your own automation using the Drata API, ensure your script captures the full browser window, not just the data table. Auditors need to verify the source of the information.

Moving Beyond "Green Circles"

The goal of compliance automation isn't just to make the Drata dashboard turn green—it's to eliminate the engineering hours spent on audit prep.

If your team spends the week before an audit frantically taking screenshots of "Not Monitored" controls, you aren't actually automated. You are just using a digital filing cabinet. By layering a screenshot automation tool on top of Drata, you close the gap between "API-monitored" and "Manual," ensuring that your custom controls are just as rigorous—and just as automated—as your AWS configs.

Learn More About SOC 2 Evidence Automation

For a complete guide to automating SOC 2 evidence collection, see our guide on automating SOC 2 evidence collection, including how to capture application-level evidence that APIs miss.