How we replaced our SOC 2 compliance platform with AI and Google Drive

Most companies paying for compliance platforms are buying expensive organisation software.

I should know. At Tallyfy, we paid for one of these platforms for years. Thousands annually. Then we took a step back and asked what we were actually getting for that money.

A spreadsheet tracking our controls. A place to upload screenshots. Some reminders about when evidence was due. Integrations that promised to automatically pull evidence but still required manual screenshots half the time.

That is it. That is what the compliance platform industry has built billion-dollar businesses on.

Here is what took me too long to understand: the compliance platform does not do the audit. You still need a licensed CPA firm to review your evidence, test your controls, and stamp their attestation on the final SOC 2 report. That is the only part that actually matters legally. The platform is just where you put things.

So we stopped paying for this and built a system that works better. Our SOC 2 Type 2 is current. The only cheque we write now goes to our CPA firm. Everything else runs on tools we already had.

What compliance platforms actually provide

Let me be specific about what these platforms do. According to recent industry analysis, the compliance automation market has grown rapidly with companies like Vanta, Drata, Secureframe, and Sprinto all competing for the same pitch: they make SOC 2 manageable.

What does manageable mean in practice?

Control tracking. A database of your SOC 2 controls - typically 60 to 100 items depending on your trust service criteria. Each control has a status, an owner, evidence requirements, and due dates. The platform shows you which controls need attention, which have current evidence, which are overdue. This is a structured spreadsheet with conditional formatting. A YAML file with a script to generate status reports does the same thing.

Evidence storage. A place to upload screenshots, exports, and documents proving you did what your policies say. Screenshots of AWS IAM configurations. Exports of user access lists. Configuration pages from various systems. Documents showing policy acknowledgements. This is a folder. Google Drive does this. Dropbox does this. Any shared storage does this.

Reminders and dashboards. Notifications when evidence is getting stale. Visualisations showing compliance status across controls. Charts showing how many items are current versus overdue. Calendar applications and a simple status report handle this. A cron job that checks due dates and sends alerts handles this.

Integrations. Connections to AWS, GitHub, Okta, Google Workspace, and other systems that can automatically pull certain evidence. This sounds impressive until you realise the reality. User feedback on G2 consistently mentions that integrations work for some items but not others, leading to a patchwork of automated and manual evidence gathering. The integration pulls a user list from your identity provider. Great. But it cannot take a screenshot of your password policy configuration page. It cannot capture the specific settings in your firewall rules. It cannot document the manual review process your team follows.

Most evidence still requires someone to take a screenshot, name it sensibly, upload it, and mark the evidence as collected.

Policy templates. Pre-written policy documents covering information security, acceptable use, incident response, business continuity, and all the other policies SOC 2 expects you to maintain. These save time during initial setup. But they need customisation to reflect your actual practices. And after the first year, you already have policies - the templates provide diminishing value.

Readiness assessments. Questionnaires that evaluate your current state against SOC 2 requirements, identifying gaps before you engage an auditor. Useful for first-time SOC 2 efforts. Less useful once you understand what the framework requires.

The real value proposition is not technology. It is that these platforms make compliance seem manageable by breaking it into steps. They reduce the intimidation factor. They provide a structure that feels official and complete.

You can get this same structure from a well-organised folder system, clear documentation of what evidence you need to collect, and someone who understands what SOC 2 actually requires.

The system that replaced it

At Tallyfy, we moved everything off our compliance platform. Exported our data, converted it to portable formats, and built a system using three components we already had.

A Git repository. All our compliance data lives here. Version controlled. Auditable. Portable.

Controls are tracked in YAML files. Each control has an ID, description, owner, status, frequency, and mappings to Trust Service Criteria. The YAML format is readable by both humans and machines. When someone asks about a specific control, we can find it in seconds. When we need to generate reports, scripts can parse the files.

Evidence items are tracked similarly. Each evidence item has a description, the control it supports, collection frequency - 90 days, 180 days, 365 days depending on how quickly the evidence goes stale - and the date it was last collected. A dashboard script reads these files and shows what is current, what is coming due, what is overdue.

Risks are documented the same way. Risk ID, description, treatment approach, current status, mitigating controls. All in YAML. All version controlled.

Our policies live in the repository too. We maintain three formats for each policy: editable source files that humans write and update, markdown versions that AI can read and help review, and PDF exports that auditors receive. The markdown versions include YAML frontmatter with metadata - version number, last review date, next review due date, owner, and mappings to SOC 2 criteria.

Every change is tracked through git commits. Who made the change, when, what changed, why. Git blame shows the exact commit for any line in any policy. Git log shows the complete history of changes. Git diff shows exactly what changed between versions.

This is your audit trail, built into version control for free. Better than any platform activity log I have seen. Platforms show you that someone uploaded a file. Git shows you exactly what changed in that file, character by character, with the commit message explaining why.

Google Drive. This is where auditors look. We created a shared folder structure mirroring the repository. Policies organised by category. Evidence organised by quarter. Third-party SOC 2 reports from our vendors. Our own audit packages with the official reports from previous periods.

A Python script syncs files from the repo to Drive. It uses Google Drive API with a service account - programmatic access, no manual uploads, no human error. Run the sync after evidence collection, after policy reviews, after any updates. Auditors get read-only access to the Drive folder. They can browse, download, review - but cannot modify anything.

The repository is the source of truth. Drive is the read-only mirror for auditor access. Changes happen in the repo, then sync outward. Never the other way around.

This separation matters. The source of truth is version controlled, portable, owned entirely by us. The auditor view is a snapshot we choose to share. We control what gets synced and when.

AI assistance. This is where the real transformation happened. AI handles the tedious work that used to justify platform subscriptions.

Evidence collection follows a quarterly cycle. Check what is due in the evidence YAML file - filter by next_due date. Navigate to AWS or GitHub or whatever system holds that evidence. Take a screenshot showing current state and date. Name it with a consistent convention: date prefix, evidence ID, source system. Files sort chronologically by default.

Update the YAML with the new collection date and next due date - 90 days out for quarterly items, 365 days for annual items. Sync to Drive. Mark as done. Move to the next item.

Annual policy reviews work the same way. A script bumps version numbers and review dates across all policies. AI assists by reading each policy and identifying sections that might need updates - references to specific technologies that have changed, procedures that no longer match actual practice, compliance requirements that have evolved. Human reviews the suggestions, makes actual changes, approves the updates. Generate fresh PDFs. Sync to Drive. Done.

The whole system is portable. Clone the repository, you have everything. Export the Drive folder, you have all evidence. No vendor lock-in. No proprietary formats. No worrying about what happens if your compliance platform gets acquired, changes pricing, discontinues features, or goes out of business.

How AI changes the compliance workload

This is the part that matters. Compliance work is not intellectually difficult. It is tedious. Evidence collection is tedious. Policy reviews are tedious. Security scanning is tedious. Status reporting is tedious.

AI handles tedious. That is not a limitation - it is exactly what makes this approach work.

Evidence analysis. When you collect evidence - screenshots of AWS IAM settings, exports of user access lists, configuration pages from various systems - someone needs to verify that the screenshot actually shows what it claims to show. An auditor asks about your access control evidence. Is the screenshot you uploaded actually showing access controls, or did someone upload the wrong file?

AI can visually inspect images and describe what they contain. We ran visual analysis on our entire evidence library - every screenshot, every captured configuration page. Each screenshot now has a machine-generated description of what it shows, mapped to the evidence ID it supports.

This matters during audits. When an auditor asks about a specific evidence item, you can immediately confirm what the screenshot demonstrates without hunting through folders and squinting at images. The description tells you: this screenshot shows AWS IAM user list with 12 users, MFA status column visible, last login dates shown.

AI also catches problems. Screenshot shows wrong time period. Screenshot shows staging environment instead of production. Screenshot was taken before a policy change, not after. These errors get caught during the analysis rather than during the audit.

Policy reviews. Annual policy reviews traditionally meant someone reading through 30-plus policy documents, checking if anything needed updates, making changes, tracking versions. This takes days when done properly. Most companies either rush through it or skip meaningful review entirely.

AI can read your policies and identify sections that reference specific technologies, vendors, or practices that might have changed. References to specific software versions. References to deprecated services. Sections describing procedures that no longer match how the team actually works.

It can flag inconsistencies between related policies. Your incident response plan references a communication procedure that differs from what your business continuity plan describes. Your data classification policy uses different terminology than your data retention policy.

It can suggest updates based on changes in your actual practices documented elsewhere - commit histories showing new tools adopted, configuration changes showing new security measures implemented, incident logs showing response procedures that evolved.

The human still decides what to change. But the tedious reading and cross-referencing work that used to take days now takes hours. The AI surfaces what needs attention. The human applies judgment about what to actually update.

Security scanning. SOC 2 requires evidence that you test your security posture regularly. Penetration testing, vulnerability assessments, configuration reviews - these typically require external consultants charging significant fees per engagement.

We run automated penetration tests monthly using open-source tools. Nuclei for vulnerability scanning against thousands of known vulnerability templates. Testssl.sh for certificate analysis and TLS configuration review. Security header checks for HSTS, CSP, and other browser security policies. Port reconnaissance to verify only expected services are exposed.

The scans run automatically on a schedule. Raw results go into the repository. And then AI generates the reports.

AI takes raw scan output - technical, verbose, sometimes thousands of lines - and produces professional PDF reports. Executive summary with security posture score. OWASP Top 10 coverage showing which categories were assessed. Severity breakdown showing critical, high, medium, low findings. Individual findings with CWE classifications, remediation guidance, and references.

Most importantly: mappings to SOC 2 trust service criteria. This finding relates to CC6.1. This finding relates to CC7.2. The report speaks the language auditors expect.

What used to require a security consultant writing up findings now happens automatically. The scans cost nothing to run. The AI report generation costs fractions of what consultant time costs.

Dashboard generation. Parse the YAML config files, count what is current versus overdue, calculate compliance percentages, generate a status report showing overall health and items needing attention.

AI can produce a compliance dashboard by reading your evidence.yaml, controls.yaml, and policies directory. Current evidence count. Overdue evidence count. Controls with issues. Policies due for review. Risk items requiring attention.

No platform subscription required. No monthly fee for a dashboard that shows you information derived from your own data.

The pattern here is consistent. Compliance work involves lots of reading, lots of cross-referencing, lots of documentation. AI is excellent at exactly this. The platforms charged thousands annually for organising this work. AI actually does this work, and does it faster.

What you still need

Let me be clear about what this approach does not replace.

A licensed CPA firm for the audit. This is non-negotiable. No platform, no AI, no clever folder structure substitutes for the actual audit. A licensed CPA firm needs to review your evidence, test your controls through inquiry and observation, and provide the attestation that your customers and their security teams actually care about.

The platform vendors sometimes obscure this. They talk about compliance automation like the platform does the compliance. It does not. Your CPA firm does the compliance assessment. The platform - or in our case, the repository and AI - just organises the evidence they review.

When a customer asks for your SOC 2 report, they want the attestation letter signed by a licensed CPA. That letter is what carries legal weight. That letter is what their security team reviews. That letter is what matters.

Budget accordingly. The audit cost stays roughly the same regardless of how you organise your evidence. The CPA firm charges for their time reviewing, testing, and writing. What changes is the platform subscription you no longer pay.

Someone responsible for compliance. A human needs to own evidence collection, policy maintenance, and audit coordination. AI assists but does not replace judgment calls about what evidence to collect, how to respond to auditor requests, or when policies need substantive updates.

At Tallyfy, this is not a full-time role. Quarterly evidence collection takes a day or two. Annual policy reviews take a week. Audit coordination during the observation period takes more time but happens once a year. The role requires someone who understands the systems being documented, has authority to make policy decisions, and can communicate effectively with external auditors.

Understanding of what SOC 2 requires. This approach works because we already understood SOC 2 from years of working with compliance platforms and auditors. If you are starting from zero, the platforms do provide educational value. They break down the requirements and guide you through initial setup. They have customer success teams who can answer questions.

You can get this same education from your CPA firm, from the AICPA guidance, from compliance consultants who charge for initial setup rather than ongoing subscriptions. But you need it from somewhere before this approach makes sense.

Type 1 versus Type 2 considerations. SOC 2 Type 1 is a point-in-time assessment. Controls designed and implemented as of a specific date. The auditor tests whether your controls existed at that moment, not whether they operated effectively over time. Less evidence refresh burden because you are proving a moment, not a period.

SOC 2 Type 2 covers a period of time - typically 12 months. You need evidence that controls operated consistently throughout that period. This means ongoing evidence collection, not just a one-time effort. Quarterly evidence refresh for controls that change frequently. Annual evidence for controls that remain stable.

Our approach works for both, but Type 2 benefits more from automation. When you need quarterly evidence refresh across dozens of controls, having AI-assisted workflows matters more than when you are proving a single point in time.

When this approach makes sense

This is not for everyone. Let me be honest about the fit.

Good fit: Technical teams comfortable with Git and YAML. If your engineering team already uses version control, this approach feels natural. YAML config files, markdown policies, Python sync scripts - this is infrastructure your developers already understand. They can contribute to compliance work without learning a new platform.

Good fit: Startups trying to get SOC 2 without burning runway. Platform subscriptions represent significant annual cost - often equivalent to a meaningful percentage of monthly burn for early-stage companies. If you are pre-revenue or early-stage, that money might go further elsewhere. The approach here requires upfront setup work but eliminates ongoing subscription fees.

Good fit: Companies wanting full control over their compliance data. Everything lives in your repository. You can audit your own audit trail. You are not dependent on a vendor continuing to exist, maintaining specific features, or keeping pricing stable. When you need your data, it is already in formats you control.

Less good fit: Large enterprises with complex multi-team compliance needs. If you have separate teams responsible for different parts of SOC 2, if you need role-based access controls on who can see what evidence, if you have regulatory requirements about where compliance data lives - the platforms handle this complexity better than a repository does. They have features for workflows, approvals, segregation of duties. A Git repository with Drive sync does not replicate enterprise-grade access controls.

Less good fit: Teams that genuinely benefit from platform integrations. If your stack happens to match what the platforms integrate with, and those integrations actually work for your evidence needs, the automation might justify the cost. Check carefully though. Review which evidence items the integrations actually cover. Many teams find the integrations handle maybe 30 percent of evidence requirements, with everything else still manual.

Less good fit: Non-technical teams who need hand-holding. The platforms provide structure, guidance, and support. They make compliance feel achievable for teams without deep technical backgrounds. If you need that scaffolding, pay for it. The frustration of struggling with a DIY approach is not worth the subscription savings.

The honest assessment: you trade platform fees for your own time. Someone needs to set this up initially. Someone needs to maintain it. Someone needs to understand Git and YAML and how the pieces fit together.

But you own everything. Nothing is locked in vendor formats. Your compliance data is portable. And the AI that makes this practical is the same AI that is making the platforms themselves less differentiated.

SOC 2 is documentation. You are proving you do what your policies say you do. Policies, controls, evidence - organised, accessible, version controlled.

The compliance platform vendors built businesses on making this seem complicated. It is not complicated. It is tedious. There is a difference.

Complicated means intellectually difficult, requiring specialised knowledge to navigate. Tedious means time-consuming and repetitive, requiring attention but not genius. Tedious work has a specific pattern: read something, check something, document something, repeat.

AI handles tedious. That is what large language models do well. Read documents, cross-reference information, generate reports, check consistency. The same capabilities that power AI writing assistants work perfectly for compliance busywork.

What you are really buying with platform subscriptions is the comfort of not having to figure this out yourself. The organisation, the reminders, the dashboards, the sense that someone else has thought through how compliance should work.

Now that AI can help figure it out - can read your policies, analyse your evidence, generate your reports, assist with the actual compliance work - that comfort is worth less than it used to be.

Our SOC 2 Type 2 is current. Our auditor is happy with the evidence organisation. Our CPA firm does the attestation that actually matters legally. Everything else runs on Git, Google Drive, and AI.

The rest is just folders and files.