Quick answer: The evidence binder is a tenant-generated evidence pack that maps the compliance data your Orbit workspace already produces — audit logs, access reviews, consent records, retention settings, breach counts — onto a public framework's control matrix: SOC 2, ISO 27001, GDPR, or HIPAA. You pick the framework and format under Settings → Compliance → Binder, generation runs in the background, and the result is a signed download link that expires after 24 hours, with a SHA-256 checksum on every completed pack. It answers the spreadsheet-and-email dance that procurement questionnaires usually trigger — and it answers it with aggregate, hashed evidence your buyer can read directly.
The full reference is the Compliance evidence binder docs page; this post walks the workflow end to end so you know what to hand over when a buyer's procurement team comes knocking.
What the binder actually contains
A binder is not a folder of raw logs. It renders the framework's control matrix, section by section, from two kinds of material:
- Static narrative per control. The policy Devotel Orbit follows for that control, stated once — the same text on every generation until the policy itself changes. This is context for the reviewer, not the evidence.
- Tenant evidence rows per control. The substance: aggregate counts and posture pulled from your workspace — audit-log volume, team role distribution, breach-incident counts, consent and retention configuration. These are the answers a buyer otherwise waits two weeks for.
Sitting under both is the integrity summary: how many audit-chain rows were checked while the pack was assembled and whether the chain verified. That chain matters in section four; the short version is that Orbit's audit log is tamper-evident, and the binder states its verification result up front.
The redaction is by construction, not by policy. Evidence rows contain aggregate counts and hashed references only — never phone numbers, email addresses, customer names, message bodies, API keys, or webhook secrets. Nobody on your team reviews the file before forwarding, because there is nothing in it to redact. A binder is safe to hand to a procurement team as-is.
Access mirrors that safety: only the workspace owner or admin role can generate a binder, every generation writes an audit-log entry with the framework, format, and requesting role, and completion writes a second entry. The pack itself is part of your evidence trail.
The triggers: when someone asks for one
Binders exist because three recurring conversations keep landing on the same artifact.
A procurement questionnaire with SOC 2 baked in. The most common ask. A security review lands as a 300-line spreadsheet asking about audit-log retention, access reviews, incident counts, and data-retention configuration. The answers already exist in your Orbit workspace — the SOC 2 framework option maps them onto the Trust Services Criteria in the order the questionnaire expects, so the response becomes a PDF and a cover note instead of a week of staff time.
Also waitable for the smaller version: some procurement teams just ask for "evidence of your platform's controls" in a free-text field. That ask gets the same pack.
A GDPR-flavored legal request. A regulator or a customer's privacy team asks for your processing posture, breach history, and retention configuration. The GDPR framework walks exactly that surface — consent records, DSAR history, breach counts, retention posture — mapped to the GDPR control structure instead of a security framework's. The walk is the same; the matrix differs.
Your own audit cadence. The third trigger is nobody asking at all. A quarterly generation, even with no audit pending, builds two things: a habit and a comparable archive. Section four is the argument for running the binder on a schedule rather than on demand.
Walking a SOC 2 request end to end
SOC 2 is the most common procurement ask, so here is the full path from the dashboard:
- Open Settings → Compliance → Binder and pick SOC 2 from the framework picker — SOC 2 for the procurement ask, ISO 27001 for Annex-A certification evidence, GDPR for the privacy file, HIPAA for PHI access posture and BAA questions.
- Choose the format: a rendered PDF for humans, or a ZIP of per-control files for importing procurement evidence into a GRC tool. Most questionnaires want the PDF; the ZIP exists for the popular GRC importers.
- Select Generate. The job runs in the background — the page shows it move Pending → Generating → Completed. If a generation for the same framework is already in flight, the dashboard shows that job again instead of queueing a duplicate, so repeated clicks are safe.
- When the job completes, use the Download link on the job row. The link is a signed URL valid for 24 hours. If it lapses, generate again or open the job for a fresh link — the file behind it is the same by checksum until your underlying data changes.
The same walk is scriptable for teams that treat evidence as infrastructure:
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/binder/generate \
-H "X-API-Key: dv_live_sk_..." \
-H "Content-Type: application/json" \
-d '{"orgId": "org_...", "framework": "soc2", "format": "pdf"}'The response is 202 with a job id; GET /api/v1/compliance/binder/:jobId returns status, the signed download_url, download_sha256 for file verification, download_size_bytes, and the tamper-flag status. GET /api/v1/compliance/binder/frameworks returns the framework catalogue — names, scope text, control counts — if you want to wire the chooser into your own tooling.
The GDPR variant changes one step. Same generate call, "framework": "gdpr". The pack it produces answers a different reader — a data-protection officer, not a security reviewer — and maps your DSAR history, breach counts, and retention configuration onto the GDPR structure. If your legal team is assembling a response to a privacy inquiry, this is the walk they take.
Generation mechanics and integrity pitfalls
Three mechanics are worth understanding before you rely on the binder in a real audit.
Deterministic evaluation. A generation is a function of your data at one point in time: each control's evidence query reads aggregate counts from your workspace, the narrative text is static, and the sections render in a fixed order. Two generations over the same data come out byte-identical. That property is not decorative — it is what makes a re-generation months later checkable.
The checksum. Every completed pack carries a SHA-256 checksum, exposed in the dashboard and on the API response as download_sha256. The recipient can verify the file they received is the file you generated — and you can verify the file in your archive matches the one you handed over. For audit-comparables this is the whole game: a procurement team that received Q1's binder can diff it line-for-line against Q2's, because the format is deterministic and the checksum proves both. A mismatch between the file and its claimed checksum means the file moved; a matching checksum means it didn't.
The tamper banner, and what it is not. While building the pack, the generation reruns the platform's audit-chain integrity check. If that check flags anything, the binder opens with a tamper-alert banner at the top — a signal to investigate before sending the file anywhere external. The pitfall to avoid is semantic: the banner flags a possible audit-log anomaly, not "your binder failed." Treat it as a prompt to check your audit history, not a reason to discard the generation. A flag that resolves to a known infra event is a better outcome than handing the file over blind.
One practical note on the signed-link life cycle: the 24-hour expiry is there so a link pasted into an old email thread does not stay live. If a procurement contact comes back weeks later with "the link expired," the right move is re-generating — the new pack's checksum tells you whether the underlying data changed in the meantime.
Why byte-identical generations matter
Procurement and audit work on a compare-to-previous cadence. A security reviewer does not just ask "show me your posture" — they ask "show me what changed since the last binder we received." The binder answers that mechanically:
- Same data in, same file out. Byte-identical output means any deviation between two generations is a real change in the underlying workspace data, not formatting drift or a generator update that scrambled the document.
- Checksum-verifiable transfer. The SHA-256 value on each completed pack lets both sides of the handoff prove they are looking at the same bytes — useful when a buyer forwards the file internally through three departments.
- Archive-friendly cadence. Generating quarterly (or on each procurement cycle) builds a chain of comparable artifacts, and the audit-log entry for each generation stamps when it was made and by whom.
This is the same property good lockfiles and signed builds rely on: determinism turns "we might have changed something" into "here is the diff, and here is the hash."
What it isn't
Precision on this boundary matters more than any feature in this post:
- The binder is not a SOC 2 attestation from Devotel. A SOC 2 attestation is issued by an external auditor after examining your controls. The binder is tenant-generated evidence of what your Orbit workspace recorded — assembled for your auditor, not a substitute for one.
- The format is not proof. A PDF or ZIP structurally mapped to a framework does not make the underlying posture correct. It makes the posture readable and portable. Correctness stays with your controls, your counsel, and the auditor on the other side.
- Orbit does not grade your posture. Orbit assembles the evidence you produced; it never determines which obligations apply, and it never hands you a passing grade. The quarter's posture is yours — the binder is the envelope it ships in.
Frequently asked questions
Which framework should I send for a procurement ask?
SOC 2 for security questionnaires, ISO 27001 when Annex-A control evidence is requested, GDPR for privacy/legal inquiries, HIPAA for PHI-access posture. If the request mentions a framework, match it; if it is free-text, SOC 2 is usually the right default.
Can I automate generation for a scheduled cadence?
Yes — the generate endpoint is a plain API call, and the framework catalogue endpoint lists what the chooser would render. Queue a generation with POST /api/v1/compliance/binder/generate, poll the job, archive the signed URL and checksum.
Is the binder safe to forward to a buyer's procurement team?
Yes — evidence rows are aggregate counts and hashed references only, so the file contains no phone numbers, email addresses, customer names, message bodies, or keys. Nothing in the file requires redaction before forwarding.
What does the tamper banner mean?
The generation reran the audit-chain integrity check and it flagged something. Treat a tamper-flagged binder as a signal to investigate your audit history before sending the file external — not as "the binder failed."
The takeaway
Procurement and legal requests stop being a spreadsheet choreography the moment the answers live in your workspace and a deterministic exporter can map them to the framework being asked about. The binder's job is narrow — aggregate, hashed, checksummed, tenant-owned, and honest about not being an attestation — and narrow is exactly what an evidence file should be. Reference: Compliance evidence binder docs.