The modern compliance stack: controls, evidence, and executable workflows

What does compliance automation actually mean?

“Compliance automation” sounds like one product category. It is not.

One team uses the phrase to mean collecting cloud-configuration evidence for a SOC 2 audit. Another means assigning control owners and tracking remediation. A third means sending a structured incident report to an employee, checking the answers, and retaining exactly which version of the procedure was followed.

Those are related problems, but they are not the same problem.

The simplest useful answer is this:

Compliance automation can monitor whether a control appears healthy, organise the evidence behind a programme, or execute a specific compliance task. Strong systems are clear about which job they perform.

That distinction prevents an expensive category mistake. A beautiful control dashboard does not automatically give a customer a compliant intake workflow. A well-designed form does not automatically monitor AWS, manage an audit, or maintain a risk register.

Before comparing platforms, ask a more basic question: what are you trying to make repeatable?

• the state of your compliance programme;
• the collection of audit evidence;
• the work assigned to control owners;
• the completion of a specific legal or operational process; or
• the record produced when that process is completed?

The answer tells you which part of the stack matters most.

What are the layers of a modern compliance stack?

A practical compliance stack has at least four layers. They may live in one product, several products, or a mixture of software and human review.

1. Requirements and controls

This layer organises frameworks, legal requirements, policies, risks, controls, owners, and mappings. It answers questions such as:

• Which requirements apply?
• Which control addresses each requirement?
• Who owns the control?
• Can one control satisfy several frameworks?
• Which gaps need remediation?

This is the natural territory of GRC and compliance-operations platforms.

2. Monitoring and evidence

This layer checks systems and gathers proof. It may connect to cloud infrastructure, identity providers, HR systems, device-management tools, ticketing systems, or document repositories.

The output is usually evidence about a control: a configuration, test result, policy, access review, screenshot, log, approval, or other artefact.

3. Workflow execution

This is where a person or system performs a specific compliance task. A supplier is assessed. A conflict is declared. A breach is triaged. A withdrawal request is recorded. A reviewer answers follow-up questions because an earlier answer triggered them.

The workflow needs fields, conditions, calculations, warnings, required attestations, and a clear completion state. It should retain the interpretation and version used.

4. Records and delivery

Completion must produce something durable. That may be an audit record, a webhook event, a delivered notification, a signed artefact, or a structured record retained for later review.

This layer answers:

• What exactly did the person submit?
• Which rules and version checked it?
• What decisions were produced?
• When did completion occur?
• Where was the result delivered?

The layers connect, but they should not be blurred. Evidence that a policy exists is different from a record showing that a person followed the policy in a particular case.

Where do Vanta, Drata, and Secureframe fit?

Their current public product material is remarkably consistent about the centre of gravity.

Vanta describes automated evidence collection, framework and control mapping, continuous control monitoring, remediation, audit preparation, and trust-centre visibility. Drata emphasises controls and evidence, automated tests, continuous monitoring, auditor collaboration, internal risk, and vendor risk. Secureframe highlights continuous monitoring, failing-test alerts, automated evidence collection, integrations, vulnerability information, and personnel onboarding.

Those are substantial jobs. If your immediate question is “Are our security controls passing, and can we prove it to an auditor?”, one of these platforms is a natural place to look.

Hyperproof describes a related compliance-operations model: centralising requirements, controls, risks, evidence, tasks, reporting, and audit collaboration. Its language is broader than audit preparation alone, but the organising unit remains the compliance programme and its controls.

The comparison is easier to understand in a table:

Vanta, Drata, Secureframe, and Hyperproof publicly place most emphasis on the first two rows, with tasks and collaboration around them. That does not mean they contain no workflows. It means buyers should examine the exact workflow they need rather than assuming the word “automation” settles the question.

Where does ProseID fit?

ProseID is designed around the third and fourth layers: workflow execution and the resulting record.

A publisher turns an interpretation into a schema. The schema defines the questions, field types, branches, computed values, errors, warnings, and completion conditions. A released version is immutable. It can run as a hosted form or inside another product through the JavaScript SDK. Each completion is checked by the server and associated with the exact form, schema, publisher, and version used.

That makes the basic unit of ProseID different.

• In a control platform, the unit is often a control, test, framework requirement, risk, or evidence item.
• In ProseID, the unit is a published interpretation that can be executed repeatedly.

Consider a supplier due-diligence process. A control platform can show that supplier reviews are required, assign an owner, collect the policy, and record evidence that reviews occurred. ProseID can provide the actual intake: which supplier facts are required, which answers reveal enhanced questions, what blocks completion, and what version-bound record is created for this supplier.

Or consider a personal-data breach. A programme-level tool can map incident-response controls to GDPR requirements. A ProseID schema can collect the awareness time, risk assessment, rationale, affected data, notification status, and delay reason for one incident.

This is not a claim that one layer is more important. The programme needs both the rule and the event. ProseID is deliberately specific about the event.

Do you need one platform or a stack?

Usually, a stack.

If you are pursuing SOC 2 or ISO 27001 and your evidence lives across cloud, identity, HR, and engineering systems, a compliance-automation platform can remove a great deal of collection and monitoring work. Rebuilding that integration estate simply to avoid another product is rarely an attractive use of time.

If you also have repeatable compliance processes that involve customers, suppliers, employees, case workers, or operational teams, you may still need an execution layer.

A sensible combination can look like this:

1. The GRC or compliance platform records the requirement, control, owner, risk, and audit evidence.
2. ProseID publishes the operational interpretation as a versioned workflow.
3. A person completes the hosted or embedded form.
4. ProseID validates the submission and creates the case-level record.
5. A webhook or later integration attaches the completion evidence to the relevant control or case system.

Not every organisation needs all five steps. A small team may start with one urgent workflow. A security-led company may begin with continuous control monitoring. A regulated operator may already have a large GRC platform but still be running important case processes through spreadsheets and email.

The right architecture follows the work, not the category labels.

How should you evaluate the options?

Start with a real process and ask each vendor to show it from beginning to end.

What enters the system?

Is the input a cloud configuration, a document, a task update, a completed questionnaire, an API event, or a person’s answers? Products that accept different inputs solve different problems.

What is being versioned?

Can you see the exact control, policy, form, logic, or interpretation that applied at the time? “We updated the template” is not enough when an earlier case must remain understandable.

What makes completion valid?

Does the platform merely record that a task was marked complete, or does it validate the underlying facts and conditions? Both can be appropriate. The distinction should be explicit.

What does the final record contain?

Ask to inspect the output. Does it contain raw answers, decisions, rule outcomes, timestamps, provenance, version, delivery status, and an audit trail? Or is the output primarily a dashboard status and evidence attachment?

Who needs to use it?

Compliance specialists may be comfortable in a GRC platform. Customers and suppliers should not need a GRC licence or training to complete a focused process. The interface should match the participant.

What is the honest boundary?

No platform removes the need to interpret law, define controls, investigate facts, or exercise professional judgment. Good automation makes those decisions visible, repeatable, and reviewable. It does not hide them behind a green badge.

If your main problem is framework readiness, control monitoring, and audit evidence, begin with the platforms built around those jobs. If your main problem is turning an interpretation into a reusable workflow and retaining a validated record every time it runs, that is the question ProseID is built to answer.

Continue with the focused comparison of ProseID and Vanta, or examine the underlying distinction between evidence collection and executable workflows.