Nov 11, 2026

Our SOC 2 program has pull requests

How Prodos built a SOC 2 Type 2 program into the same engineering system that ships the product, by our CTO, Rafael Paulino.

Our SOC 2 program has pull requests

By Rafael Paulino, CTO at Prodos

When Prodos set out to earn a SOC 2 Type 2 report, my first question was simple: how do we build a compliance program that fits the way we already work? We're a small team shipping hundreds of product changes, and the audit couldn't slow that down.

Our clients are regulated wealth management firms, so we went straight to Type 2, which shows controls kept working over time, not just on one day. That set the clock: our auditor would watch our controls for 90 days over the summer, and everything had to run from day one.

The program lives in Git

A compliance program is mostly documents: policies, procedures, templates and the records that prove each one ran. We already had a system for keeping text current, reviewed and traceable. It's the one we use for code. So the working copy of our program lives in a Git repository, and Oneleet, our compliance platform, holds the published policies and runs our monitoring.

Changing a policy works like changing code. I open a pull request, someone other than me approves it, and the merge leaves a permanent record of who changed what and when. An export turns the repository into PDFs for the auditor, each stamped with the commit, author and date.

A policy change, start to finish: pull request, review by someone else, merge with permanent history, change record

Every policy has to be provable

The auditor tests you against your own words, so we tailored every line of our policies to how we actually work. An AI agent reviewed each policy for consistency, conflicts and SOC 2 coverage, and I worked through every finding. We kept policies and procedures separate, so each requirement has a clear line to the procedure, tool or dated report that proves it ran.

The checks come to us

Nobody on a small team can watch dashboards all day. Threat detection, container image scans, device checks and open-source vulnerability checks post to Slack automatically. Oneleet monitors our cloud, code, devices and identity providers, and its MCP server lets our AI agents read those results directly. Once a month, an AI review pulls every source together, removes duplicates and drafts the report. We work through each finding, and I review the report before it merges as evidence.

From alert to approved evidence: signals feed a monthly AI review, the CTO approves, and the evidence lands in the repo

AI drafts, people decide

AI is what made this workable for a small team. The rule is that nothing it drafts becomes evidence until it has run against real systems and a person has reviewed it. That rule earns its keep: the first run of our audit-log review showed the query was reading the wrong log source, and we fixed it the same day.

The answer to my first question was to stop treating compliance as a separate project. We build the product with reviewed changes and automated checks, so we run compliance the same way. You can learn more about our security program, or request our SOC 2 report, at trust.prodos.dev.

This is a short version of an article Rafael published on LinkedIn. Read the full article or follow Rafael on LinkedIn.