How to Build Compliance Automation Software Like Vanta: Evidence Collection, Audit Readiness, and Real Costs

An MSSP serving 20 clients at Vanta's pricing spends up to $500,000 per year on a tool it doesn't own. When a client churns, the evidence history lives in Vanta's system. When Vanta changes its pricing tier, you absorb the cost. And when a client needs a framework Vanta doesn't fully support, you tell them you can't help.

According to Gartner, 85% of organizations that fail a SOC 2 audit cite incomplete or missing evidence as the primary cause, not actual control gaps. The compliance software problem is evidence collection, not policy writing.

The economics of building your own compliance automation platform break even before the third client renewal. The architecture is not trivial, but it is well-understood.

This guide covers what compliance automation software does, where the hard problems are, and what it costs to build.

Who builds custom compliance automation software

Managed security service providers are the clearest case. An MSSP with 20 clients at $15,000-$25,000 per year is writing a check to Vanta for up to $500,000 annually. Building their own platform costs $200K-$320K once. The math works before year two ends.

IT consulting firms that want to productize compliance work build their own tool to differentiate from competitors using the same commercial platforms. When your compliance offering runs on the same Vanta dashboard every other MSSP uses, you compete on price alone.

SaaS companies targeting enterprise customers often need to offer compliance status as a feature. A healthcare SaaS selling to hospital networks needs to show HIPAA control coverage to their enterprise buyers. Embedding compliance reporting directly in the product is more compelling than sending a PDF export from a third-party tool.

Healthcare IT companies managing HIPAA compliance across dozens of integrated tools find that commercial platforms cover the common integrations (AWS, Google Workspace) but miss the healthcare-specific systems (EHR APIs, medical device management, clinical data platforms). Custom software handles the full stack.

Defense contractors managing NIST 800-171, FedRAMP, or CMMC requirements often find that Vanta and Drata focus on commercial frameworks. Federal compliance has specific evidence requirements, assessment procedures, and documentation formats that general-purpose tools handle poorly.

What compliance automation software does

A compliance framework (SOC 2 Type II, ISO 27001, HIPAA, PCI DSS) is a set of controls. Each control has requirements. The software maps those requirements to evidence.

Evidence is anything that demonstrates a control is met: a screenshot of an MFA configuration screen, a written security policy, a log showing that access was reviewed last quarter, or an automated check confirming that no S3 bucket is publicly accessible.

The alternative to software is a spreadsheet. Compliance managers maintain a master spreadsheet listing each control, its requirement, and a link to a file on Google Drive. Before an audit, someone spends 200 or more hours pulling together screenshots, policy documents, and configuration exports. Auditors wait. Controls that should be continuously verified are checked once per year.

Compliance automation software replaces the spreadsheet with a system. Controls are defined once. Evidence is attached or collected automatically. Audit packages are generated on demand. Continuous monitoring checks run daily so failures surface in real time, not the week before an audit.

The control library

Every framework is a set of controls. SOC 2 has five trust service criteria and 64 common criteria. ISO 27001 has 114 controls across 14 categories. HIPAA has administrative, physical, and technical safeguards. The software needs a data model for all of them.

The Cloud Security Alliance reports that organizations using automated compliance tools reduce audit preparation time by 60-80% compared to manual evidence collection. The control library schema is what makes that automation possible.

Build a control library with each control carrying: a unique ID, the framework it belongs to, a description of the requirement, the evidence types accepted (document, screenshot, automated check), whether automation is possible (yes or no), and the check frequency (continuous, quarterly, annual).

Controls are grouped into frameworks. One piece of evidence can satisfy multiple controls across frameworks. A written password policy satisfies SOC 2 CC6.1, ISO 27001 A.9.3.1, and HIPAA 164.312(a)(2)(i). Map those relationships explicitly so clients in multiple frameworks don't upload the same document three times.

The control library is the schema around which everything else is built. Spend time designing it before writing integration code.

The integration layer

This is where compliance automation software gets hard.

"The single biggest mistake teams make when building compliance automation is underestimating integration maintenance. An AWS API that worked perfectly in Q1 can break silently in Q2 when AWS updates their IAM schema. You need automated tests for every integration check, not just the initial build." - Dave Shackleford, SANS Institute Fellow, speaking at RSA Conference 2024

Automated evidence collection means connecting to the systems where evidence lives: AWS, GitHub, Okta, Google Workspace, Azure AD, Jira, Slack. Each integration is an OAuth 2.0 connection plus a set of API calls that retrieve data and run checks.

An AWS integration might run these checks: all IAM users have MFA enabled, no root account access keys are active, CloudTrail logging is enabled in all regions, no S3 buckets have public access. A GitHub integration checks: no repositories are public without approval, branch protection rules are enforced on main, and required code review is enabled. An Okta integration verifies: all active users have MFA configured, terminated employees have been deprovisioned within 24 hours, and admin roles are assigned to fewer than five accounts.

Each check extracts data from the provider's API, evaluates it against the control requirement, and records a pass or fail result with a timestamp and the raw data that supported the determination. That raw data becomes the evidence record.

For HR integrations (employee onboarding, offboarding, role changes), use Merge.dev or Unified.to. These aggregators provide a single normalized API across BambooHR, Rippling, Workday, ADP, and similar systems. Building direct integrations with ten HR systems is a multi-quarter project. Merge.dev reduces it to one.

For major cloud providers, build direct. AWS, Google Cloud, and Azure each have well-documented APIs and SDKs. The integration complexity is manageable, and these are the checks auditors care most about.

Each new integration adds two to four weeks of development. Budget accordingly. A platform launching with eight integrations takes four to six weeks of integration work alone.

Continuous monitoring

Running checks once before an audit is not compliance. Running checks daily is.

The monitoring system executes checks on a schedule: some run hourly (MFA status), some daily (terminated employee offboarding), some weekly (access control reviews). Use BullMQ with Redis for the job queue. Each check job fetches data from the relevant integration, evaluates it, and writes a result to PostgreSQL.

When a check fails, three things happen. First, an alert is created with the control ID, the check that failed, the affected resource (for example, "user [email protected] does not have MFA enabled"), and a timestamp. Second, the relevant owner is notified via email or Slack. Third, the failure is logged in the evidence trail with enough detail for an auditor to see what failed and when it was resolved.

The gap record matters as much as the resolution. An auditor reviewing SOC 2 Type II evidence wants to see that a control was continuously monitored, that failures were detected quickly, and that they were resolved. A system that only records passing checks is not useful for Type II audits.

Store check results in PostgreSQL. Each row carries the check ID, the control ID, the pass/fail status, the timestamp, the raw response data from the integration, and the resolution timestamp if applicable. This table becomes the backbone of the audit evidence trail.

The evidence library

Automated checks handle the controls that have clear, machine-verifiable requirements. Plenty of controls require human-uploaded evidence: written security policies, penetration test reports, employee training completion records, vendor risk assessments, board approval documents.

The evidence library is a file management system tied to controls. Users upload documents, screenshots, and PDFs. Each evidence record carries: the file, the control or controls it satisfies, the date it was collected or created, an expiration date (annual policies expire in 12 months, continuous checks never expire), and the user who uploaded it.

Show coverage as a ratio per framework: 74 of 92 SOC 2 controls have accepted evidence. Expired evidence drops the count. A control with a failed automated check shows as a gap. The dashboard tells a compliance manager exactly where they stand before the auditor arrives.

S3 stores the actual files. PostgreSQL stores the metadata and the control mappings. Keep files versioned: when a policy is updated, the previous version stays in the record with its valid-through date. Auditors sometimes ask for historical evidence.

Audit package export

When an external auditor requests evidence, they should receive a complete package without getting a login to the system.

The export function generates a structured download containing: all controls in the selected framework, the status of each (passed, failed, not evaluated), the linked evidence for each passing control (file or automated check log), a summary of failed controls and their resolution history, and timestamps throughout.

Export format is either a structured ZIP (folder per control, files attached, summary CSV) or a PDF document with evidence embedded. Some auditors prefer the ZIP because they can navigate controls directly. Others prefer PDF for filing. Build both.

The export process should be triggered by the client, not by a support request. The auditor flow is: client triggers export, reviews the package, shares it with the auditor. Your system is not in the loop during the actual audit engagement.

Risk register

Compliance frameworks require organizations to maintain a risk register: a catalog of identified risks, each with a likelihood score, an impact score, a treatment decision (accept, mitigate, transfer, avoid), an owner, and a next review date.

The risk register connects to the control library. A risk in the register links to the controls that address it. When a control is failing, the associated risk is highlighted. When a risk is accepted (no control remediation planned), the acceptance is documented with a rationale and an approver.

This is not a complex feature, but it is required for SOC 2 and ISO 27001. Build it early. It is a standard CRUD interface with a linked data model to controls. The complexity is in getting the UI right so risk owners can review and update their entries without needing a compliance manager to facilitate every interaction.

Tech stack

Node.js handles the API and the background check jobs. PostgreSQL stores controls, evidence metadata, check results, users, and the risk register. BullMQ with Redis manages the scheduled check queue. React builds the dashboard. AWS S3 stores evidence files.

Each integration requires a separate OAuth 2.0 implementation. AWS uses IAM roles and the AWS SDK. GitHub uses a GitHub App with fine-grained permissions. Okta, Google Workspace, and Azure AD each have their own OAuth flows and API schemas. There is no shortcut: each integration requires a purpose-built client.

PDF generation for audit exports uses Puppeteer or Playwright. Both can generate PDFs from HTML templates with enough fidelity for professional audit packages.

The architecture is not exotic. The complexity is in the integration layer, the check scheduling logic, and the evidence expiration tracking. A team that has built similar systems before will move faster because they know where the edge cases live.

Cost and timeline

A full compliance automation platform with a control library covering four frameworks, eight to ten integrations, continuous monitoring, evidence library, audit export, and risk register costs $200,000-$320,000 and takes 20-26 weeks.

The integration layer drives the range. Each integration adds $15,000-$25,000 and two to four weeks. A platform launching with five integrations sits toward the lower end. A platform launching with twelve integrations, including custom cloud and HR connectors, sits toward the higher end.

A focused build covering one framework (SOC 2 only), manual evidence upload with no automated checks, and basic audit export costs $60,000-$90,000 in 8-10 weeks. This is a reasonable starting point for a firm that wants to test the market before investing in the full integration layer.

Adding AI features, such as control gap analysis from uploaded policy documents, risk scoring from check history, or natural language querying of the evidence library, adds $40,000-$80,000 depending on scope. See our guide on AI agents for fintech for patterns applicable to compliance AI features.

Build vs. buy

Buy Vanta or Drata when you need compliance for a single organization, once or twice a year. They handle SOC 2, ISO 27001, HIPAA, and PCI DSS well for standard commercial software companies. The integration library covers the common cases. The audit workflow is proven. At $15,000-$25,000 per year for one company, the cost is reasonable.

Build custom when the economics of serving multiple clients make ownership the clear choice. An MSSP at 10 clients is spending $150,000-$250,000 per year on commercial tools. At 20 clients, that number doubles. The platform pays for itself.

Build custom when compliance is a product feature, not just an internal requirement. A SaaS company selling to regulated industries needs to show compliance status in-product, not in a third-party tool. Custom software is the only way to do that without building a deep integration to a commercial platform's API.

Build custom when your frameworks are industry-specific. NIST 800-171, FedRAMP, and CMMC have different evidence requirements, assessment procedures, and documentation formats than SOC 2. General-purpose compliance tools focus on the commercial frameworks. Defense and federal markets need platforms built for their specific audit processes.

RaftLabs has built security automation and SaaS platforms for fintech, healthcare, and enterprise IT clients. The pattern we see consistently: teams underestimate the integration maintenance burden. An AWS check that passes today may break silently next quarter when a provider updates their API schema. Budget for ongoing integration QA, not just the initial build.

If you are building SaaS applications for enterprise clients and compliance is a recurring requirement, the platform investment pays off quickly. The same applies to firms pursuing MVP development for a compliance-adjacent product where the core IP is the control mapping and integration layer.

The compliance software market rewards ownership. Once you own the platform, adding a new framework is an editorial task: write the control library, map it to evidence types. Adding a new integration is a development task. Neither requires renegotiating a vendor contract or waiting for a roadmap item.