Do I still need a compliance platform?

No framework has ever required a compliance platform. The real question has always been where your compliance work happens best, and AI is changing that answer.

Agentic compliance can provide the knowledge, coordination and automation across the systems your company already uses. For some companies, that reduces the need for a dedicated compliance platform.

But platforms still offer valuable out-of-the-box functions, and your agent can operate within them. This isn’t an argument against platforms.

It’s a question of placement:

Where do humans and AI do their teamwork? Inside a dedicated compliance platform, or across the other tools your company already uses?

Platforms such as Vanta, Drata and others made compliance dramatically more accessible. They gave companies an out-of-the-box structure for something that was previously complicated, manual and difficult to navigate.

For many companies, that structure still creates significant value. The operational trade-offs matter as much as the strategic choice.

What’s changing is the alternative.

AI agents can increasingly provide the knowledge, coordination and automation that previously made a dedicated compliance application the default choice.

For some companies, a compliance platform will remain the right answer.

For others, an intelligent compliance layer that works across the software the company already uses will fit better.

And for many, the answer may be somewhere in between.

For the mechanics of how an agent actually collects evidence across those tools, read how to run your compliance program with AI: connectors, browser agents and a human in the loop.

Practical trade-offs to check

An automated test may check that a file is attached rather than what it demonstrates. A green status is useful, but it is not an auditor's assessment of the underlying record.

Integrations need re-authenticating and can disconnect. That can leave gaps in continuous-monitoring history even when the underlying control still operates. The auditor needs to investigate those signals, and resolving the gaps can create work for everyone.

Six questions before choosing an approach

• What are you trying to achieve: a first report, an ongoing program, or both?
• Who will run compliance day to day, and how many contributors need guardrails?
• How much do you already use AI across your systems?
• Does your compliance shape fit the platform's templates?
• Can you capture and maintain the company context an agent needs?
• Will your auditor work with your chosen approach?

Keep your auditor involved early. A readiness assessment can show whether the evidence meets audit expectations. For the full budget, see the all-in SOC 2 cost guide.

Why did compliance platforms become so successful?

To understand what’s changing, it’s worth understanding the problem compliance automation originally solved.

Before modern compliance platforms, preparing for something like SOC 2 could be painful.

Companies didn’t know where to start.

They didn’t know which controls they needed.

They didn’t know what evidence auditors expected.

Someone had to find the right settings across dozens of systems and take screenshots.

Policies often started from blank documents.

Risk registers lived in spreadsheets.

Evidence lived in folders.

Auditors sent requests through spreadsheets or email.

And the people trying to manage all of this often weren’t compliance experts.

Compliance platforms changed that.

Instead of starting with a blank page, companies got a blueprint.

Here are the controls.

Here are the policies.

Here are the tests.

Connect these systems.

Fix these failures.

Upload this evidence.

Complete these tasks.

Get these things green.

That made compliance significantly more accessible.

And that matters.

Constraint was part of the product

There was another, less obvious reason compliance platforms worked.

Compliance gets complicated very quickly.

A detailed risk assessment can become enormous.

Control libraries expand.

Evidence requests multiply.

Auditors see one piece of evidence and ask five follow-up questions.

Spreadsheets give people almost unlimited freedom to add another column, another tab, another field and another process.

None of this necessarily happens because GRC practitioners are doing bad work.

Often it’s the opposite.

Good practitioners understand how much nuance exists.

The problem is that too much nuance becomes difficult for everyone else in the business to engage with.

The compliance person becomes the black sheep asking everyone to participate in processes that make perfect sense from a GRC perspective but feel overwhelming to everyone else.

Compliance platforms imposed constraints.

A test is green or red.

A control has a defined set of evidence.

A policy follows a template.

A framework has a predefined structure.

There is a finite list of things to complete.

That constraint was valuable.

It didn’t necessarily create deeper risk management or better security.

It made compliance simpler, faster and more accessible to people who weren’t compliance experts.

And for the market compliance automation originally served, that was incredibly powerful.

Compliance platforms are opinionated by design

That simplicity comes with a trade-off.

Compliance platforms are necessarily opinionated.

Imagine taking thousands of SaaS companies and asking:

What does a reasonably typical compliance program look like?

You might arrive at 80 controls.

For one company, perhaps only 60 really matter.

Another might need 100.

A platform usually provides some flexibility to add, remove and customize things.

But the starting point is still an opinion.

It says:

This is roughly what compliance should look like for a company like yours.

That’s not a criticism. It’s the product.

The alternative historically was expensive.

You could bring in experienced practitioners, deeply understand the company, map its risks, understand its customers, architecture and operating model, and design the compliance program from the ground up.

Or you could start with the blueprint.

For a startup trying to get SOC 2 quickly, the blueprint often made far more sense.

But SaaS companies aren’t all the same

The problem is that “SaaS company” describes an enormous range of businesses.

They have different customers.

Different data.

Different architectures.

Different risks.

Different contractual commitments.

Different engineering practices.

Different access models.

Different infrastructure.

Different ways of deploying software.

Different approaches to devices.

Different levels of centralization.

Different security tooling.

Different customer expectations.

And increasingly, very different ways of working.

At Throughline, we refer to some of these operating differences as Compliance Shapes.

Take access control.

One company might have centralized identity, formal IT provisioning and tightly defined role-based access.

Another 25-person engineering company might have a much more distributed model where system owners manage access through existing operational workflows.

The compliance objective can be the same.

The appropriate implementation doesn’t necessarily need to be.

The same applies to change management.

A traditional organization might use tickets, approvals and segregated deployment responsibilities.

A modern engineering company might rely heavily on automated testing, branch protection, peer review, infrastructure as code and highly empowered developers.

Again, the objective can be the same.

The shape is different.

An opinionated platform necessarily starts somewhere in the middle and asks companies to adapt the template.

AI creates a new middle ground

This is where agentic AI changes the economics.

Historically, companies faced something resembling a choice:

Build a bespoke compliance program from the ground up.

That can fit the company extremely well, but requires expertise and significant effort.

Or:

Start with an out-of-the-box compliance platform.

That dramatically reduces the effort, but starts from a more generic model.

AI creates a third option.

Build from the ground up, but let the agent do the heavy lifting.

Start with the objective.

Understand the company.

Map its compliance metadata.

Understand its Compliance Shapes.

Identify the risks and commitments that actually matter.

Then let AI translate those inputs into controls, policies, processes, evidence requirements and ongoing activities.

Suddenly, bespoke doesn’t necessarily mean manual.

That’s an important change.

The platform is no longer the only place automation can happen

Consider employee onboarding and offboarding.

A compliance platform might monitor whether employees are appropriately onboarded and terminated.

But the actual process probably lives in the company’s HRIS.

That’s the source of truth for people.

So another architecture is possible.

Let the onboarding and offboarding process live in the HRIS.

Let identity controls live in the identity provider.

Let code controls live in GitHub.

Let infrastructure controls live in AWS.

Let device controls live in the device-management system.

Let risks live in Notion if that’s where the company wants them.

Let policies live in Google Workspace if that’s where employees already work.

Let security monitoring live in dedicated security tools.

Then give an AI agent enough context and access to understand how those things fit together.

This raises a fundamental architectural question:

Do you want compliance activities to operate where they naturally belong, with an agent connecting the dots?

Or:

Do you want another application sitting above those systems and pulling compliance into a centralized interface?

Neither answer is inherently right.

But until recently, the second option was much easier.

AI is making the first one practical.

What does compliance look like without a platform?

A platformless compliance stack doesn’t mean having no systems or structure.

It might look something like this:

The open-source Compliance Brain tool provides structured context about the company, its commitments, systems, risks, customers and operating model.

An AI compliance agent interprets that context and coordinates the program.

Google Drive, Notion, Confluence or another existing repository stores governed compliance records and policies.

The company’s HRIS manages people processes.

Its identity provider manages identity.

Its cloud environment implements infrastructure controls.

GitHub and CI/CD tooling implement software-development controls.

Dedicated security tooling provides security monitoring.

Slack, Teams or another interface lets humans interact with the compliance agent.

Existing task-management or calendar systems coordinate activities requiring human involvement.

And the independent auditor works with the company and its agent to obtain the information and evidence required for the audit.

There’s still an application layer.

It’s just distributed.

The agent becomes the thing that understands how the pieces connect.

Compliance information doesn’t necessarily need to live in a compliance application

This distinction becomes increasingly important.

Every business needs compliance information.

That doesn’t mean every business needs a dedicated compliance application.

Companies need policies.

Risks need to be understood.

Controls need to exist.

Evidence needs to be available.

Responsibilities need to be clear.

Activities need to happen.

Changes need to be tracked.

None of those things inherently require a particular software category.

Google Drive can store a policy.

Notion can maintain a risk register.

Rippling can manage an offboarding workflow.

GitHub can enforce a change-management control.

AWS can enforce an infrastructure control.

Slack can provide an interface to an agent.

The value traditionally provided by the compliance platform was partly its ability to connect and organize all of those things for humans.

An AI agent can increasingly provide another way of doing that.

What about automated compliance tests?

Automated tests were another major innovation in compliance automation.

Connect your systems and the platform can tell you whether particular settings pass or fail.

That’s convenient.

But it’s important to distinguish compliance monitoring from security monitoring.

They aren’t necessarily the same thing.

Compliance generally establishes a baseline of controls appropriate to a particular objective.

Security can go significantly deeper.

An infrastructure security product might assess hundreds or thousands of configurations, vulnerabilities and security indicators.

A compliance platform may intentionally reduce those to a smaller set of high-level tests that map neatly to a compliance framework.

Again, that’s not necessarily a weakness.

It’s part of making compliance manageable.

But if your objective is continuous security improvement, the deeper security tooling may be the more important thing to monitor continuously.

This leads to a useful principle:

Continuously monitor things where continuous monitoring creates security or operational value, not simply because a compliance dashboard can test them every day.

The evidence required for an audit will depend on the nature of the control and the period being examined.

Some controls require evidence of operation throughout a period.

Others may involve configurations that are inspected at particular points in time alongside other evidence about how the control operates.

The answer is not to reduce a Type II audit to a once-a-year screenshot exercise.

But it also isn’t necessarily valuable to recreate simplified versions of sophisticated security monitoring purely so a compliance dashboard stays green every day.

The appropriate monitoring should follow the underlying risk.

AI can also collect evidence differently

Evidence collection was one of the strongest original use cases for compliance automation.

Taking screenshots manually is annoying.

More importantly, someone who doesn’t understand what the auditor wants may not know where to find the right information.

An integration solved that problem.

AI agents introduce another approach.

An agent that understands the control and has appropriate system access can potentially navigate to the relevant information, understand what it’s looking at, collect the evidence and provide the surrounding context.

That can actually restore some nuance that integrations stripped away.

The objective isn’t to bring back painful manual screenshot collection.

It’s to remove the human pain while retaining the richness of the source system.

That’s a different type of automation.

Does that mean compliance platforms are becoming obsolete?

No.

That’s too simplistic.

Compliance platforms now do considerably more than collect screenshots and host policies.

Depending on the platform, they can provide capabilities around:

access reviews;

vendor management and discovery;

security questionnaires;

framework mapping;

task management;

evidence retention;

workflow;

reporting;

continuous monitoring;

audit collaboration;

and many other areas.

Companies may get significant operational value from those capabilities.

There is also enormous value in buying something that works out of the box.

Not every company wants to design its own compliance architecture.

Not every company is proficient at using AI agents.

Not every team wants to decide where its risk register should live or configure how an agent interacts with its HRIS.

Sometimes the desired experience is simply:

Tell me what to do. Give me the shortest reasonable path. Help me get there.

Compliance platforms are very good at that.

When would we recommend using a compliance platform?

At Throughline, we don’t think this is primarily a headcount question.

It’s an operating-model question.

If you want an out-of-the-box compliance approach, a platform can make a lot of sense.

If you don’t have significant compliance expertise and don’t want to invest time designing the program, the blueprint is valuable.

If you value the platform’s access reviews, vendor workflows, questionnaires, reporting or other functionality, those can easily justify the software.

If your team likes working in it and it makes compliance easier, that’s a good reason to keep using it.

And if you’re paying for a compliance platform today, everyone understands it, it works and you’re getting value from it, going agentic isn’t a reason to cancel it.

Let the agent work with the platform.

The question isn’t whether compliance platforms are bad.

The question is where you want the teamwork between your humans and your AI to happen.

When might you not need one?

The calculation starts to change when a company wants compliance to fit deeply into how it already operates.

Perhaps you don’t want employee lifecycle processes duplicated outside your HRIS.

You want engineering controls to remain inside engineering workflows.

You want policies where your employees already access company knowledge.

You want security monitoring performed by deeper security tooling.

You want evidence to come directly from source systems.

And you have enough proficiency with AI to let an agent coordinate those distributed activities.

In that situation, adding another application layer may provide less incremental value.

The more capable the agent becomes at connecting those systems, the less important it becomes that they all appear in one human interface.

Compliance platforms and agents can work together

This doesn’t have to be binary.

There are at least three emerging models.

Platform-led compliance

The compliance platform provides the structure, workflows, integrations and primary interface.

This is the model that has dominated modern startup compliance.

Agent + platform

The platform remains the system of record and provides useful out-of-the-box functionality.

An AI agent operates around or within it.

The agent might interpret company context, customize controls, remove irrelevant requirements, add missing ones, collect richer evidence, coordinate humans and work across systems that sit outside the platform.

For many companies, this could be an extremely effective model.

Agent-native compliance

Compliance activities remain distributed across the company’s existing systems.

The AI agent becomes the primary coordination and intelligence layer.

There may be no dedicated compliance application at all.

Throughline is comfortable with all three.

Our job as the auditor isn’t to sell you a particular operating model.

It’s to understand yours.

AI separates the agent from the application

This may be the deeper change.

Historically, the compliance application and the compliance workflow were tightly connected.

The software contained the controls.

The software contained the workflows.

The software told humans what to do.

The software showed humans what was happening.

The software was the interface.

AI allows those things to separate.

The agent can understand what needs to happen.

The underlying applications can remain the places where things actually happen.

A dedicated compliance application is one possible place for that teamwork to happen. Choose it on its merits rather than assuming it is needed.

That doesn’t mean the application has no value.

It means companies can finally evaluate that value independently.

Do we want its workflows?

Do we want its reporting?

Do we want its integrations?

Do we want its vendor management?

Do we want its evidence repository?

Do we want its audit interface?

Is that worth the subscription?

Those are much better questions than:

“Don’t I need a compliance platform to do SOC 2?”

Because you don’t.

A surprising question about startups

There is an interesting possibility in where this market goes next.

Compliance automation originally found particularly strong product-market fit among startups and smaller technology companies.

That makes sense.

They had limited compliance expertise.

They wanted SOC 2 quickly.

They had relatively standardized SaaS technology stacks.

They didn’t want to build compliance programs from scratch.

The blueprint was enormously valuable.

Over time, compliance platforms have expanded upmarket and added more sophisticated features to support larger organizations.

AI could create an interesting inversion.

Consider a 20-person AI-native startup.

It has relatively few employees.

Few systems.

A simple architecture.

Founders with broad company context.

Limited organizational bureaucracy.

High proficiency with AI.

And little legacy process.

That might actually be one of the easiest environments for an autonomous compliance agent to operate in.

The company that once benefited most from having compliance simplified into an application may become the company where an agent can most easily manage compliance without one.

Larger organizations have a different problem.

They have many people.

Many business units.

Many approval chains.

Complex permissions.

Established processes.

Multiple frameworks.

Legacy systems.

And substantial coordination requirements.

Dedicated workflow and governance applications can become more valuable as human coordination increases.

But even that isn’t a simple company-size equation.

Some sophisticated enterprises outgrow opinionated compliance platforms because their environment is too bespoke to fit neatly into the platform.

They adopt only parts of it.

Once the platform holds only part of the compliance program, some of the benefit of having one central compliance system disappears.

So we don’t think the future divides neatly into:

startups = no platform

and

enterprises = platform.

The more interesting variable is:

How much value does a dedicated compliance application add to the way this particular company wants to operate?

AI is simply changing the answer.

Don’t make your compliance program serve the application

This is probably the principle we care about most.

Software should serve the compliance program.

The compliance program shouldn’t exist to serve the software.

If your compliance platform creates value, use it.

If it makes your team more effective, use it.

If it gives you capabilities you don’t want to build elsewhere, use it.

If your AI agent works better with it, use both.

But if you’re maintaining duplicate processes because the platform expects them;

moving information out of the systems where it naturally belongs;

changing sensible operating practices to fit predefined controls;

or paying for a dedicated software category because you assume SOC 2 requires it;

then it’s worth reconsidering the architecture.

Start with what you’re trying to achieve.

Understand your risks.

Understand your commitments.

Understand your customers.

Understand how your company actually operates.

Then decide what technology best supports that.

Not the other way around.

So, do I still need a compliance platform?

A compliance platform isn’t a framework requirement, but you may still want one.

The question underneath the question is where you want humans and AI to do their teamwork.

If you want that teamwork to happen inside a purpose-built product, a compliance platform can be extremely valuable. Its out-of-the-box blueprint can make compliance simpler and give you useful workflows and automation.

If you’re already using one and getting value from it, AI isn’t a reason to throw it away. Your agent can operate within the platform, and agents and compliance platforms can work very well together.

But if you want compliance deeply embedded into your existing environment, you’re comfortable using AI, and you’d prefer your controls and processes to live in the systems where the work actually happens, you now have another viable option.

Build the compliance program around your company.

Let the agent connect the pieces.

And only add a dedicated compliance application if it adds enough value to justify being there.

That’s the change AI creates.

Compliance automation used to mean putting compliance into an application.

Increasingly, it can mean giving an agent enough context to operate compliance across the applications you already have.