Continuous compliance: where controls stop

In September, the audit window opens. The compliance lead sends forty evidence requests to twelve owners. Over six weeks, they export access lists, screenshot settings and chase approvals out of Jira.

The evidence shows the controls working in those six weeks. For the other ten months, nobody can say. A March joiner never accepted the security policy, an admin account created inside the ERP never appeared in a review, and an April unsubscribe never reached the sales tool.

Continuous compliance means the controls run all year, and the evidence builds up as they do. This post walks through the seven parts of compliance automation, where each one breaks, and what to automate first.

What is continuous compliance?

Continuous compliance runs the recurring work behind privacy and security controls on its own schedule, and keeps the evidence each run produces. It covers policy acknowledgements, user access reviews, change approvals, consent, data subject requests, retention, and the audit evidence that shows each one ran. It spans HR, identity, business apps, engineering tools and the compliance tool.

The seven parts, and where each one breaks

1. Policy acknowledgement. Everyone accepts the policies for their role from their start date, and again when a policy changes. It breaks when a March joiner has never accepted the security policy, because the last round went out in January. The joiner nobody asked.
2. User access review. Each quarter, someone who knows the work checks who has access to each in-scope app. It breaks when the review comes from the identity provider and misses the admin account created inside the ERP. The admin nobody listed.
3. Change approval. Every change to production has a ticket, a reviewer who didn’t write it and tests that passed. It breaks when a pull request approved before its last commit ships a change nobody reviewed. The commit nobody reviewed.
4. Consent and preferences. One system holds each person’s consent, and a withdrawal reaches every tool that contacts them within seconds. It breaks when someone unsubscribes and the sales tool emails them nine days later. The email sent nine days later.
5. Data subject requests. Access and deletion requests are verified, searched across every system that holds personal data, and answered on time. It breaks when the search misses the support tool with years of tickets. The system nobody remembered.
6. Retention and deletion. Records past the period the policy allows are found, checked for holds and deleted in the source and every copy. It breaks when the help desk is cleaned up and the warehouse still holds every ticket since 2016. The copy that keeps everything.
7. Audit evidence. Each control’s evidence is collected on its own schedule, with its date and source, and gaps reach the owner that week. It breaks when evidence gathered in the six weeks before the audit shows only those six weeks. The six-week scramble.

Why compliance work stalls between systems

Controls run on the calendar. Reviews and acknowledgements happen in rounds, so new joiners and new apps fall between them.

Scope comes from one system. The identity provider lists the apps it knows about, and accounts made inside an app never appear.

Personal data lives in more places than anyone lists. Support tickets, spreadsheets and the warehouse hold copies nobody searches.

Changes reach some tools and stop. An unsubscribe or a deletion updates the system it started in, and the copies keep the old value.

Evidence is gathered after the fact. Screenshots and exports are collected for the audit, not as the controls run.

What to automate first

1. Start every control from an event. A hire, a role change, a new app or a policy update starts the work.
2. Build scope from every source. Combine the identity provider with each app’s own user list.
3. Map where personal data lives. Keep one list of the systems that hold it, and use it for requests and retention alike.
4. Send every change to every copy. A withdrawal or a deletion reaches each tool and the warehouse, and the result is logged.
5. Act on review decisions. Access marked for removal is removed, and the removal is logged as evidence.
6. Collect evidence as the control runs. Each run stores its date, source and result where the auditor will look.

Where AI agents fit

Agents do the reading and the sorting. They find personal data in free-text support tickets during a request, summarize why a change skipped review, and draft the explanation of an evidence gap for its owner to check. Removing access and deleting records run on fixed rules, with a person approving where needed.

How this differs from a compliance tool

A compliance tool tracks your controls, reads settings from connected systems and holds the evidence. Tray.ai runs the work a settings check can’t do: removing access after a review, searching every system for a data subject request, and deleting records past their date. It then sends the evidence back to the compliance tool.

Automation doesn’t make a company compliant on its own. Whether controls meet a framework is a judgment for the auditor or the regulator. Automation makes the controls run on time and keeps the evidence, which is usually the part an audit finds missing.

Tray.ai is audited for SOC 1 and SOC 2 Type 2 itself, and the reports are available under NDA through the trust page. They cover Tray.ai’s own controls. Yours are still yours, and your auditor still tests them.

Two neighboring processes feed the same evidence. Vendor risk assessment covers the suppliers in scope, and vulnerability prioritization produces the fix times auditors ask about.