Fitting Autopliance into the tools you already use

Nobody adopts a compliance product in isolation. You already have a GRC platform, or a ticket tracker your auditor lives in, or a folder your evidence goes into every quarter. This page is the short path from “I have an Autopliance report” to “it is in the system my audit actually runs on”.

Whose evidence is this? Read this first

Everything below moves a file into a system your auditors use. Before it lands there, be clear about what it asserts.

On a hosted plan, the traffic on your fleet is generated by EdSSA, not by your systems — minting credentials yourself needs an SDK or a binary, and those are not distributed yet. The chain is real, the anchors are real, and the verification is real. But the report is evidence about the EdSSA component in your architecture, which is exactly the slot a subprocessor’s evidence belongs in — and it is not evidence that your own estate is attested.

That distinction matters most in a GRC platform, because the tool will happily let you attach it to a control about your systems. Every report states its origin on its face, in all five formats, so a reviewer opening the PDF sees it whether or not they read this page.

On a self-hosted or enterprise deployment you run the boundary, so the attested events are your own traffic and none of this applies. The report says that on its face too.

Getting your own systems into the chain on a hosted plan is the next thing being built. If it is what you need, say so at support@edssa.io.

There are no built connectors, and this page will not pretend otherwise. Autopliance has no Vanta app, no ServiceNow plugin, no ServiceNow-certified anything. What it has is five output formats and a signed evidence archive, and every workflow below is a file moving from one place to another — usually in under five minutes. If a real connector would save you a recurring hour, say so at support@edssa.io: the queue is built from what people ask for, and nothing here is hard to automate once someone needs it.

What you have to work with

The OSCAL output is a NIST OSCAL 1.1.2 assessment-results document. Each mapped control becomes an observation and a finding, and coverage maps onto the finding’s target status — satisfied where the platform provides the control, not-satisfied where it is yours to operate and outside our technical scope. UUIDs are derived from the regime tag and control reference rather than generated, so the same report renders byte-identically: a diff between two months shows what actually changed, not a wall of new identifiers.

Compliance automation platforms

Vanta, Drata, Secureframe, Sprinto, Thoropass and similar.

These platforms are built around control owners attaching evidence, and most of that evidence is screenshots. A dated, framework-mapped PDF is a straight upgrade on a screenshot, and it is the fastest thing to try first.

1. Generate the report for the framework the platform is driving — SOC 2, ISO 27001, whichever.
2. Download the PDF.
3. Attach it to the control(s) it covers as evidence, the same way you would attach anything else.
4. Note the report date in the evidence description. These platforms expire evidence on a schedule; a report regenerated monthly slots into that cadence without argument.

If your platform ingests OSCAL, use that instead of the PDF and you get control-level structure rather than one attachment. Support for it varies and changes — check your platform’s own documentation rather than ours, because we are not in a position to promise what a third party accepts this quarter.

What this replaces: the recurring task where someone screenshots a dashboard to prove a control is operating. What Autopliance attaches instead was computed by walking a cryptographic chain, and the auditor can check it.

Which control to attach it to. On a hosted plan, file it where vendor and subprocessor evidence goes — third-party risk, vendor due diligence, the sub-processor register. Attaching it to a control that asserts something about your own infrastructure would misstate it, and the report’s own marking will contradict you when a reviewer opens it.

Enterprise GRC / IRM

ServiceNow IRM, RSA Archer, MetricStream, LogicGate, OneTrust.

The unit here is usually a control test with an evidence record and a retention rule.

1. Attach the PDF to the control test record, and the JSON beside it if the platform stores structured attributes — the JSON carries the anchor count, the period and the verdict as fields rather than prose.
2. Put the evidence archive in your document repository and reference it from the record. That is the artefact that survives an auditor asking “how do you know?”, because they can verify it without us.
3. If the platform imports OSCAL, that path gives you per-control findings without hand-mapping.

Worth knowing before someone asks in a review: an Autopliance report is evidence, not an attestation. It does not replace your auditor’s opinion, and where a framework requires one, this is what you hand them to form it.

Ticketing and documentation

Jira, Confluence, Linear, Notion, SharePoint, Google Drive.

The lowest-friction integration there is, and often the one that sticks.

• Jira / Linear — attach the PDF to the compliance ticket for the period. If you run a recurring audit-evidence ticket, the report is the thing that closes it.
• Confluence / Notion — paste the Markdown. It renders as a proper document with its tables intact, so the evidence page is the report rather than a link to one.
• SharePoint / Google Drive — this is where most auditors actually receive files. Drop the PDF and the evidence archive in the audit folder together: the PDF is what they read, the archive is what they check if they want to.

Cloud-native audit tooling

AWS Audit Manager, Microsoft Purview Compliance Manager, Google Cloud Assured Workloads.

These collect evidence automatically from their own cloud and accept manual evidence for everything else — which is exactly where an attestation boundary that is not their cloud belongs.

1. Upload the PDF as manual evidence against the relevant control.
2. Where the tool takes a URL or an external reference, point it at the evidence archive in your document store rather than at us — evidence that depends on our uptime is weaker evidence.

This is the natural home for Autopliance in a multi-cloud estate: your cloud provider’s tool attests to its own services, and Autopliance attests to the boundary between them, which no single provider’s tool sees.

Data pipelines, SIEM and dashboards

Splunk, Elastic, Datadog, Grafana, BigQuery, Snowflake.

Use the JSON. It is a stable, versioned document with the figures as fields, so it fits a scheduled job rather than a person:

# Generate monthly, keep the series, and let your own tooling do the rest.
curl -sS -H "Cookie: $EDSSA_SESSION" \
  "https://app.edssa.io/reports/<id>/download/json" -o "evidence-$(date +%Y-%m).json"

Anchor counts, the period and the chain verdict make a perfectly good time series: a month where the count drops is a month where something stopped attesting, and that is worth an alert well before it is worth an audit finding.

The OSCAL download is /reports/<id>/download/oscal.json — note the full extension. /download/oscal 404s, because the download path names the stored file, not the format.

CI/CD

GitHub Actions, GitLab CI, Jenkins.

Two patterns people actually use:

• Publish evidence as a release artefact. Attach the report and the evidence archive to the release, so the compliance record for a version ships with the version.
• Fail the build on a broken chain. The JSON carries the verdict; a job that parses it and exits non-zero on anything but an intact chain turns “we would have noticed eventually” into “we noticed in eleven minutes”.

The auditor themselves

Worth stating separately, because it is the case the whole product is shaped around.

Send them two files: the report PDF for the framework in question, and the signed evidence archive. The archive’s own README.md gives them the commands to check the signature and walk the chain, using openssl and a shell. They need no account with us, no software of ours, and no cooperation from you.

That last property is the one worth protecting in every workflow above: prefer putting the archive somewhere the auditor controls over linking to somewhere we control.

What is not here

Real API-level integrations — a Vanta app, a ServiceNow plugin, a Splunk TA — do not exist. That is not a roadmap tease; it is the current state, and the honest reason is that nobody has yet needed one enough to ask. The formats above exist precisely so the absence is inconvenient rather than blocking.

If a manual step here is one you would otherwise do twelve times a year, tell us. That is how this list gets shorter.