Compliance Monitor Platform

Overview

Compliance teams need current evidence status for the controls they track. Monitors are how Automated Compliance keeps that status attached to the control. Each monitor tracks a requirement, like "all production devices are encrypted," and connects it to the evidence source or collection workflow used to evaluate it.

When I moved into monitor-side backend work, the product was still finding its shape: spec changes were moving through the models, evidence collection was uneven, and too much proof still came from manual uploads. My work was turning the monitor side into evidence paths that could survive the next product change.

What I built

The important architecture move was the split between controls and monitors. My work focused on the monitor side of that boundary: evidence paths, report-backed monitors, recurring manual evidence, and evaluation/read paths. In the model, a control is the requirement being tested, and a monitor is the evidence and evaluation path attached to that requirement. Keeping that boundary explicit let the product reuse the same control shape across frameworks while changing how evidence was gathered.

Once the model could separate controls from evidence paths, the next question was where each monitor should get its proof. Monitors pull evidence from Checkr, AWS, GitHub, and Rippling's first-party apps when the source system can answer the question directly. Where no source system can answer the evidence question directly, the monitor routes into a guided manual workflow.

The recurring manual evidence sources work lets a monitor request evidence on a schedule for items that are not practical to automate today. Scheduled evidence requests replaced a quarterly reminder loop that had been easy to lose track of outside the monitor lifecycle.

I also built manual evidence paths around scheduled requests, upload consolidation, and read hydration. The goal was to keep manual proof inside the same control history as automated proof.

Collaboration

Product collaboration shaped where standard monitors should stay opinionated. A solutions expert helped connect the monitor model to the report library behind many automated evidence paths.

The hard product conversation was the boundary between standard controls and customer-specific evidence. We kept the monitor model opinionated for standard controls and left a safety valve for customer-specific evidence.

Outcome

• Report-backed and integration-backed monitors became the main path for the automated evidence checks covered by this work.
• Recurring manual evidence sources kept non-automatable controls inside the same monitor lifecycle, including scheduled requests, uploads, consolidation, and hydrated reads.
• The data model absorbed repeated product reshaping without another backend rewrite.

The model works because it is explicit about the evidence boundary: automate when the source system can answer the question, ask the customer for proof when it cannot, and keep both paths inside the same control history.