Quick answer: When a data-protection officer, a supervisory authority, or a buyer's privacy team opens a GDPR review, they ask for the same four artefacts: the DSAR response ledger, the processing-records catalog, consent receipts, and the breach register. On Devotel Orbit each one is a maintained surface — the DSAR queue, the Data Processing Agreement and sub-processor catalog, consent management, and the breach incident register — and the GDPR option in the one-click evidence binder rolls all four into a single, checksummed pack you can hand over as-is. This checklist is the buyer-side companion to the binder walkthrough, which covers generation mechanics; here the focus is the GDPR evidence list itself.
The division of responsibility runs through every item: Devotel Orbit is the conduit; the artefacts below document tenant-owned controls — your request queue, your consent posture, your breach timeline. The platform assembles the evidence; the posture it records is yours.
1) What a DPO or auditor actually requests
GDPR audits converge on four artefacts. Get these ready and the rest of the review is staging.
- The DSAR response ledger. Article 15 (access) and Article 17 (erasure) both want the same evidence: a queue of data-subject requests with statuses and completion times. An auditor does not want exported raw requests — they want the ledger that proves each request was logged, processed, and closed inside the statutory clock (30 days under GDPR).
- The processing-records catalog. Article 30 requires records of processing activities, and Article 28 requires your processor relationships under contract. The auditor wants the catalog that names what you process, which data-subject categories are in scope, and which sub-processors touch personal data.
- Consent receipts. Article 6 wants a lawful basis per processing purpose; Article 7 adds that you must be able to demonstrate it. The artefact is the consent register — who opted in or out, on which channel, when, with proof.
- The breach register. Article 33 wants your breach history and your notification posture: notifiable events, their status, and whether the 72-hour notification SLA was met.
A fifth implicit item rides under all four: retention posture — how long message content, recordings, and personal data are kept. It enters the binder through the Art. 30 and Art. 32 rows, so keep your configured window current before generating.
2) How to produce each artefact on Orbit
Each artefact has one canonical source surface. The GDPR binder reads them; the links below are the underlying reference a reviewer can follow when an aggregate needs a drill-down.
- DSAR response ledger — the DSAR queue. Every operator-filed and self-service request lands in one queue with a jurisdiction-aware SLA tracker. The binder's Art. 15 and Art. 17 rows report totals by status and the median completion time against the 30-day limit. If you intake requests through the public portal, the DSAR self-service portal walkthrough shows how identity-proofed intake keeps the ledger defensible.
- Processing-records catalog — the Data Processing Agreement surface. It is a self-serve click-wrap: preview the template, accept with a typed e-signature, and the executed copy plus the published sub-processor list become your Art. 28 evidence. The binder's Art. 28 row cites the sub-processor catalog; Art. 30's categories come from the privacy register the binder maps.
- Consent receipts — consent management. The consent API records per-channel opt-in/opt-out with timestamps and provenance. The binder's Art. 6 row aggregates which lawful bases appear across your records — never individual grants, because the pack ships to parties who must not receive your contacts' identifiers.
- Breach register — the breach incident register. Open, track, and close personal-data-breach incidents with a 72-hour notification attestation. The binder's Art. 33 row counts notifiable events over the trailing 12 months and states the notification SLA.
- Retention posture — your configured content window (365 days default where unset). It flows into the Art. 30 and Art. 32 rows, so set it deliberately before an audit cycle.
For the single-file version of all of the above, generate the GDPR pack in the evidence binder — it maps these surfaces onto the GDPR article structure in one deterministic export.
3) What a GDPR binder contains
The GDPR option renders the article-by-article matrix a supervisory authority or a DPO asks about. As the binder docs enumerate, a GDPR pack opens their checklist:
- Art. 6 — lawful bases supported across your consent records (from the consent surface).
- Art. 15 — DSAR totals by status, median completion against 30 days (from the DSAR queue).
- Art. 17 — erasure requests by status, including the 7-day cooling-off window.
- Art. 28 — published sub-processor list and the 30-day change-notice period (from the DPA surface).
- Art. 30 — data-subject and personal-data categories, plus the default 365-day message retention.
- Art. 32 — encryption posture, pseudonymisation of audit subjects, DR exercise cadence.
- Art. 33 — notifiable breaches over 12 months and the 72-hour SLA (from the breach register).
- Art. 35 — DPO contact and DPIA template posture.
Every row is aggregate counts and hashed references — no phone numbers, email addresses, customer names, message bodies, or keys. The header carries the integrity summary: consent-ledger export plus breach counts plus retention policy, with the number of audit-chain rows replayed. Two generations over the same data are byte-identical, and every completed pack carries a SHA-256 checksum the recipient can verify.
4) Why the binder carries a tamper-evidence banner
While assembling the pack, generation replays the platform's audit-chain integrity check. If that check flags anything, the binder opens with a tamper-alert banner at the top — ahead of the first evidence row, deliberately, so a reader sees the caveat before any claim.
To an auditor, the banner means: the counts in this file are as recorded, but the audit-log replay found rows worth investigating. To you, the right reading is procedural, not fatal: the banner flags a possible audit-log anomaly, not a failed binder. Investigate your audit history before handing the file external; a flag that resolves to a known infrastructure event is a defensible answer, and a clean banner on a quarterly cadence is itself evidence of a monitored chain. The binder walkthrough covers the checksum and determinism mechanics behind this in full.
5) End-to-end — binder to download in five steps
- Open Settings → Compliance → Binder and choose GDPR from the framework picker.
- Pick the format: PDF for a human reviewer, or ZIP (per-article files) for an authority's case-management intake or a GRC import.
- Select Generate. The job runs in the background — Pending → Generating → Completed; a duplicate click on an in-flight framework shows the same job, 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, open the job for a fresh link or regenerate; the file behind it is checksum-identical until your underlying data changes.
- Read the header before forwarding: clean integrity summary → send; tamper banner → investigate first, then send with the caveat discussed.
Only workspace owners and admins can generate, and every generation writes an audit-log entry with the framework, format, and requesting role — the binder is itself part of your evidence trail.
Frequently asked questions
Which artefacts should I have ready before a GDPR audit?
Four: the DSAR response ledger, the processing-records catalog (DPA + sub-processor list), consent receipts, and the breach register — plus your configured retention window. The GDPR binder aggregates all of them into one pack.
How long does the binder download link stay valid?
24 hours. The signed URL expires by design so a link pasted into an old thread does not stay live. Open the completed job for a fresh link, or regenerate — the checksum on the job row tells you whether the underlying data changed in the meantime.
What does a tamper-alert banner inside the binder mean?
The generation replayed the audit-chain integrity check and it flagged something. Treat the binder as "investigate before forwarding," not as failed. Resolve the flagged rows in your audit history, then regenerate.
Can I script binder generation ahead of an audit?
Yes. The generate endpoint is a plain API call; queue the GDPR framework on a pre-audit schedule and archive the signed URL and checksum from the completed job.
The takeaway
GDPR audits are won on artefacts, not adjectives. The four a DPO requests — DSAR ledger, processing-records catalog, consent receipts, breach register — are maintained surfaces in Devotel Orbit, and the GDPR binder assembles them into a deterministic, checksummed pack with a tamper-evidence header an auditor can trust. Generate it before the ask lands, keep the checksum with your case file, and the audit becomes a download instead of a scramble.
The same checklist discipline applies to the healthcare lane — see the HIPAA CPaaS buyer's checklist for the BAA-scoped version, and the PCI DSS buyer's checklist for payment-scope evaluation.