​

Compliance evidence binder

​

Generate a binder from the dashboard

1. Open Settings → Compliance → Binder.
2. Choose the framework and the output format — a rendered PDF for humans, or a ZIP of per-control files for importing into a GRC tool.
3. Select Generate. Generation runs in the background; the page shows the job move from Pending → Generating → Completed.
4. When it completes, use the Download link on the job row. The link is valid for 24 hours; if it lapses until expiry, generate again or open the job to see a fresh link.

​

Generate from the API

curl -X POST https://api.orbit.devotel.com/api/v1/compliance/binder/generate \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{"orgId": "org_...", "framework": "soc2", "format": "pdf"}'

{
  "data": { "jobId": "binder_...", "status": "pending", "dedup": false }
}

curl https://api.orbit.devotel.com/api/v1/compliance/binder/binder_... \
  -H "X-API-Key: dv_live_sk_..."

​

SOC 2 — Trust Services Criteria coverage

​

ISO 27001 — Annex-A control mapping

​

GDPR — article-by-article evidence

​

HIPAA — safeguards and BAA posture

​

Reading the pack

1. Static narrative per control — the platform’s policy for that control, stated once. This text is identical across workspaces on purpose: it describes platform behaviour, and a change in platform behaviour (not a regeneration against unchanged data) is the only thing that edits it.
2. Tenant evidence rows per control — aggregate counts and posture that differ per workspace: audit-log volume, team role distribution, DSAR and erasure status counts, active API key counts, breach incidents, configured retention. A control with nothing applicable today shows “No tenant-specific evidence recorded for this control” rather than an empty table.
3. Integrity summary in the header — how many audit-chain rows were replayed and verified while the pack was being built. A chain break does not block generation; it flips the binder into the tamper-alert banner so the reader knows upfront.

​

Operational runbook

​

Worked example — SOC 2 vendor questionnaire

1. Settings → Compliance → Binder, choose SOC 2, format PDF, select Generate.
2. Wait for Completed and download the pack.
3. Read the integrity summary in the header first. If the banner is present, resolve it (runbook above) before continuing.
4. Map the questionnaire categories to binder sections one-to-one: “Governance” → CC1.0, “People” → CC2.0/CC6.0, “Change management” → CC8.0, and so on down CC1.0–CC9.0.
5. Attach the PDF. Where a question demands a number — “when was your last access review?” — the answer is the evidence row, quoted verbatim (Last access review: 2026-07-31T…).
6. Save the download_sha256 from the job into the questionnaire’s notes field. The buyer can re-hash the attachment and confirm the document they received is the one you generated.

​

Worked example — GDPR authority response pack

1. Bring the source surfaces current: the DSAR queue statuses, the privacy register entries, and the breach incident register.
2. Generate GDPR as a ZIP — the authority’s case-management intake usually parses per-article files better than a single PDF.
3. The Art. 30 chapter answers “what you process”; the Art. 15 and Art. 17 chapters answer “how you handle requests” with completion medians against the statutory 30 days; the Art. 33 chapter answers “how you would know and notify” with the 12-month breach count and the 72-hour SLA.
4. Quote the Art. 33 count with its window (“notifiable breaches in the trailing 12 months”) — the binder reports rolling counts, not all-time totals.
5. Attach the ZIP and keep the SHA-256 with your case file. If the authority returns for a follow-up, regenerate after the window moves and diff the two ZIPs (runbook above) to enumerate exactly what changed.

​

Limits

• Signed URL expires after 24 hours. The download link in the job row stops working after a day; open the job for a fresh link or regenerate — the history keeps the job record either way.
• Owner or admin role required. Generation (and reading job status) is gated to workspace owners and admins, including via API keys; Devotel super-admins may also generate against a workspace, for example on a support request.
• Every action is audit-logged. Queueing writes a compliance.binder_generated entry to your audit log with framework, format, and requesting role; completion writes a second entry. Failed generations land in the history with the error message.
• Windows are rolling. Evidence counts cover trailing windows (90 days or 12 months, per control), not all-time totals; two binders generated weeks apart legitimately differ.
• Redaction cannot be lifted. The binder never contains PII or secrets; if an auditor needs per-subject data behind an aggregate, route them to the underlying surface (DSAR, audit log) rather than the binder.

​

Auditing and access control

• Generation requires the workspace owner or admin role; API keys follow the same role gate.
• Every generation writes a compliance.binder_generated entry to your audit log with the framework, format, and requesting role; completion writes a second entry.
• Failed generations land in the history with an error message instead of silently disappearing.

​

Related

• TCPA Evidence Pack — manually assemble a TCPA defence handout from consent, suppression, audit, and quiet-hours exports
• DSAR — the queue GDPR Art. 15 and Art. 17 rows count from
• Privacy register (ROPA + DPIA) — source of Art. 30 categories and Art. 35 posture
• HIPAA controls and HIPAA onboarding — the configuration the HIPAA pack reads back
• Compliance plugin marketplace — browse evidence packs and activation bundles in one place
• Legal