> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Trust Center evidence pack > A procurement-hygiene sequence for the Trust Center request form — which binder generation to pre-build per framework, how often to refresh it, and how to verify generations by checksum before you hand evidence over. # Trust Center evidence pack Procurement review moves fastest when the evidence is ready before the questionnaire arrives. This page is the sequence for that: what the public Trust Center gives away versus what gates behind a request, which framework binder to pre-generate depending on the buyer, how fresh a generation needs to be, and how to prove — by checksum — that the file you handed over is the file you generated. The mechanics live in the tenant-facing compliance surfaces you already run: the [evidence binder](/compliance/evidence-binder) generator, [SIEM sinks](/compliance/siem-sinks), [audit export](/compliance/audit-export), and [immutable archival export](/compliance/archival-export). The public side — subprocessor register, data residency, SOC 2 control mappings, and the gated-artifact request form — reads from the [Trust Center](https://orbit.devotel.io/trust). This page describes Devotel Orbit's platform controls. It is **not legal advice.** Which framework a buyer requires, and what evidence satisfies it, depends on your contracts and regulators. Confirm the specifics with qualified counsel. ## Evidence vs promise — what the Trust Center requests The [Trust Center](https://orbit.devotel.io/trust) splits every procurement artifact into two classes: * **Open evidence** — published for anyone, no form. The subprocessor register, the data-residency disclosure, and the SOC 2 control-mapping table. Point your buyer at these first; most security questionnaires clear a third of their rows from the open sections alone. * **Gated evidence** — issued under NDA after an access review. The counter-signed DPA, answered security questionnaires (CAIQ, SIG-Lite), the penetration-test summary, and certifications where available. The **Request the trust pack** form at the bottom of the Trust Center is the intake for exactly these items: name, work email, optional company, and the trust desk replies to that email with the access link — typically within one business day. The email is used only for that reply; there is no marketing list behind it. You generate your own binders tenant-side, and the tenant-side surfaces read only what you configured. The gated set is a separate, issuer-reviewed channel: if a questionnaire asks for a counter-signed DPA or a pentest attestation, file the form — a binder cannot substitute for an artifact only Devotel can sign. ## Per-framework checklist — what to pre-build Run [evidence binder](/compliance/evidence-binder) generations against the four supported frameworks and keep the latest completed job of each on hand. When a questionnaire lands, you attach from the shelf rather than generate under deadline pressure. * **SOC 2** — the default for North-American SaaS procurement. The binder walks the AICPA Common Criteria **CC1.0–CC9.0** and each section pairs the platform policy narrative with evidence rows counted from your audit chain. * **ISO 27001** — the default for European and enterprise buyers, and for certification-driven asks. The binder covers the Annex-A categories plus the individually numbered clauses procurement teams ask about most. Platform-fixed rows (hosting region, encryption posture, hosting attestation) look identical across every workspace; workspace-derived rows (API key counts, contact-record aggregates) come from your tenant at generation time. * **GDPR** — for supervisory authorities, DPOs, and privacy teams. The binder maps the articles those reviews ask about: lawful basis (Art. 6), access and erasure (Art. 15/17), sub-processors (Art. 28), records of processing (Art. 30), security (Art. 32), breach notification (Art. 33), and DPIA posture (Art. 35). * **HIPAA** — for healthcare buyers. The binder reads back whatever you set under **Settings → Compliance → HIPAA**: HIPAA mode, BAA execution date, the Security Officer contact, your retention window, and PHI access events. Bring those settings current before you generate — the binder states what you configured, verbatim. One time-budget note on scope: choose PDF for a human reviewer, or ZIP when the questionnaire accepts per-control files or the buyer imports into a GRC tool. That decision takes seconds at generation time; what takes the one-business-day window is the gated set above — file it first when a questionnaire mixes both classes. Every binder is redacted by construction — aggregate counts and hashed references, never contact identifiers, message bodies, keys, or secrets — so a binder PDF is safe to forward. Sign the NDA only for the genuinely gated artifacts. ## Refresh cadence and the 24-hour signed link The binder's evidence counts cover **rolling windows** — 90 days or 12 months per control — so freshness decays on a schedule you can set in advance: * **SOC 2** — regenerate **quarterly**, aligned to your internal access-review cadence, and again on the day a live procurement review opens. * **ISO 27001** — **quarterly**. Platform-fixed rows change only on a platform change; the move-detection rule below tells you when one happened. * **GDPR** — **monthly** if you run an active DSAR queue, so the Art. 15/17 status counts and completion medians reflect current posture; otherwise **quarterly**. * **HIPAA** — regenerate **the same day** any value under **Settings → Compliance → HIPAA** changes (BAA execution, retention window, Security Officer); the binder reads those values back as-of generation. Completed jobs carry a **signed download link that expires after 24 hours**. If the link in your procurement email thread lapsed, open the job in **Settings → Compliance → Binder** for a fresh link, or regenerate — the history keeps the job record either way. When you hand a binder to a buyer, deliver the **file itself**, not the link: the recipient then has no expiry to race, and the SHA-256 you recorded at generation is still what they verify against. ## Procurement sequence — generate, hand, verify 1. **Generate.** Open **Settings → Compliance → Binder**, pick the framework, choose **PDF** for a human packet or **ZIP** for a GRC import, and select **Generate**. The dashboard shows the job move from *Pending* → *Generating* → *Completed*; repeated clicks re-show the in-flight job instead of queueing a duplicate. 2. **Record the checksum.first** Open the completed job and copy `download_sha256` (also returned by the status endpoint over the API). Store it where your procurement case file lives — a deal-room note, the questionnaire's notes field, a GRC ticket. Deterministic output is what makes this checksum meaningful: two generations over unchanged data are byte-identical. 3. **Download and hand the file.** Deliver the PDF or ZIP itself within the 24-hour link window; the recipient now holds the document independently of link expiry. 4. **Verify by checksum equality.** The recipient re-hashes the file (`sha256sum` on Linux/macOS, `Get-FileHash -Algorithm SHA256` on Windows) and compares it against the `download_sha256` you recorded. Equality proves the document they received is the document you generated — no content review loop needed. 5. **Detect scope drift between generations.** Regenerate on your cadence and compare the new checksum to the stored one. An equal checksum across the shelf means nothing changed — for ISO binders whose platform-fixed rows dominate, that means no relevant platform change; a changed checksum means a workspace-derived row moved, and a ZIP diff narrows it to the exact control file. 6. **Handle a tamper banner before anything ships.** If a generation completed with a **tamper-alert banner** (the audit-chain replay flagged an issue), hold the binder internally and follow the [binder runbook](/compliance/evidence-binder) before routing it to anyone external. The same checksum discipline applies to the other evidence surfaces: an [audit-export](/compliance/audit-export) bundle, a [SIEM sink](/compliance/siem-sinks) stream, or an [archival export](/compliance/archival-export) each carries its own integrity surface — keep the generated artifact and its hash together, and any recipient can verify either class of evidence the same way. ## Boundary — the binder reflects what you configured Pre-building only works if the source posture is complete. Two boundary rules to keep the shelf honest: * **The binder is a mirror, not an inventory.** It reflects what you configured and what your workspace produced. HIPAA mode left off renders as *HIPAA mode: off*. A BAA date never set renders as unset. If your shelf misleads, the fix is in the source settings, not the document. * **An empty register exports an empty binder.** The same boundary holds across the evidence family: a [SIEM sink](/compliance/siem-sinks) with no configured destinations streams nothing; an [archival-export](/compliance/archival-export) policy disabled by default archives nothing until you opt in; a privacy register with no entries yields empty GDPR Art. 30 rows. Configure the register first, then generate — a shelf of empty binders decays into expired links anyway. SOC 2 platform rows (subprocessor register, encryption posture, residency) inherit the platform's published posture; everything else is your tenant's own data, counted at generation time. That division is why a buyer can trust the file: the platform states its posture once, in the same words for every workspace, and your rows fill in the rest. ## Related * [Evidence binder](/compliance/evidence-binder) — the generator this page sequences; framework scope, formats, tamper flags, and worked examples * [Audit log export](/compliance/audit-export) — bounded, provable slices of the audit ledger with chain verification and daily Merkle roots * [Immutable archival export](/compliance/archival-export) — WORM-grade copies of retained records for books-and-records obligations * [SIEM sinks](/compliance/siem-sinks) — continuous audit delivery to Splunk, Datadog, S3, or an HTTPS drain * [HIPAA onboarding](/guides/hipaa-onboarding) — the order to bring HIPAA settings current before generating the HIPAA binder