> ## 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. # Execute the DPA and BAA, then manage per-call recording consent > Walk the three signed-agreement and consent consoles: accept the GDPR Article 28 DPA by typed e-sign, execute and annually renew the HIPAA BAA, and review, verify, or withdraw per-call recording consent with an audit trail that survives the withdrawal. # Execute the DPA and BAA, then manage per-call recording consent Three consoles under **Settings → Compliance** hold the legal records a GDPR or HIPAA program asks for: the Data Processing Agreement (DPA), the Business Associate Agreement (BAA), and the per-call recording-consent audit trail. All three are self-serve for the **owner** and **admin** roles, and every signed record is captured with the version, signer, and timestamp your auditor will ask for. These consoles put tenant-owned legal controls in your hands — accepting, executing, and withdrawing are actions you take on behalf of your own organization. This page is not legal advice; confirm your obligations with counsel. ## 1. DPA — accept the GDPR Article 28 agreement The DPA governs how Devotel processes personal data on your behalf under GDPR Article 28. Accepting it is self-serve and never gates outbound traffic. Open **Settings → Compliance → Data Processing Agreement** (`/settings/compliance/dpa`). 1. **Review the agreement.** The canonical template loads into the page, already populated with your organization details. Signer fields fill in live as you type them, so what you read is exactly what gets stored — no placeholder tokens, no surprises. If the document fails to load, the accept button stays disabled until it does: you cannot attest to terms you were never shown. 2. **Type your e-signature.** Enter your full legal name, job title, and signer email, then type your name a second time to confirm. The typed name plus the timestamped record form the signature (a click-wrap attestation under the E-SIGN Act, UETA, and eIDAS). 3. **Accept.** The page stamps your organization `accepted` and records the signer, the acceptance date, and the template version you signed — the version-and-date pair is what an Article 28 audit asks for. 4. **Download the signed PDF.** On the accepted pane, **Download signed PDF** returns a rendered copy of the exact document you accepted. Keep it in your audit binder; the agreement itself stays stored as your encrypted legal record. Download links expire after 24 hours, so generate a fresh link when you need the file again. When Devotel publishes a newer template version, the accepted pane shows a banner naming the current version. Your existing acceptance stays in effect — accepting the new version is a re-run of the steps above, never a block. For an API-driven flow, the console is backed by `GET /compliance/dpa` (state), `GET /compliance/dpa/template/:version` (the document), `POST /compliance/dpa/accept` (typed e-sign), and `GET /compliance/dpa/download` (signed-PDF link). > **Custom DPAs.** If your procurement process requires redlined Standard Contractual Clauses, sub-processor language, or a counter-signed copy, request a negotiated DPA from [privacy@devotel.io](mailto:privacy@devotel.io). Once counter-signed, the negotiated PDF is stored the same way. ## 2. BAA — execute and renew the HIPAA agreement The Business Associate Agreement governs every action Devotel takes with Protected Health Information (PHI) on your behalf. Unlike the DPA, this one is a gate: [HIPAA mode](/compliance/hipaa) cannot be enabled before the BAA is executed, and a PHI send is rejected while it is not. Open **Settings → Compliance → BAA** (`/settings/compliance/baa`). 1. **Bring PHI in scope if it isn't already.** If the page shows "Not required," your organization has attested no PHI is in scope. When that changes, click **Require HIPAA compliance** — this records that PHI is now in scope and opens the agreement for signature (owner or admin). 2. **Review and execute.** Read the populated agreement, then execute it with the same typed e-sign flow: full legal name, signer email, name typed again to confirm. **Signing is restricted to the organization owner** — it binds the organization. 3. **Confirm execution.** The page stamps `executed` with signer, execution date, template version, and the renewal deadline. The executed agreement is stored encrypted and anchored into your audit chain, so the signature trail survives. 4. **Download the signed PDF.** Same pattern as the DPA — **Download signed PDF** produces a rendered copy; links expire after 24 hours. 5. **Renew annually.** An executed BAA expires after a one-year term. Within 60 days of expiry the page raises a renewal banner; click **Re-execute** to sign the current template version. Expiration does not delete your record — it puts HIPAA mode back behind the gate until you re-execute. Two reversal controls exist, by design: * **No PHI in scope — decline** (owner or admin): attests the workspace does not handle PHI and lifts the send-time block without a signature. Available while PHI is marked in scope but the BAA is not yet executed; an executed BAA cannot be self-declined. * **Revert to Orbit default** (owner only): removes the active BAA and returns the organization to the default state (no BAA required). Disable HIPAA mode first. The signed PDF and its audit history are retained. The BAA console also hosts the **PHI audience designation** card — designate which lists or segments carry PHI so the pre-send gate can act on them. Designating audiences does not require an executed BAA; only the send does. Working through this for the first time? Follow the end-to-end sequence in [HIPAA onboarding](/guides/hipaa-onboarding), which covers what happens after execution: enabling HIPAA mode, restricting roles and scopes, retention, and the PHI access log. API equivalents: `GET /compliance/baa`, `POST /compliance/baa/require`, `POST /compliance/baa/execute`, `POST /compliance/baa/decline`, `POST /compliance/baa/revert`, and `GET /compliance/baa/download`. > **Custom BAAs.** Redlined indemnification, term length, or sub-processor language goes through [compliance@devotel.io](mailto:compliance@devotel.io); the counter-signed PDF is stored the same way once executed. ## 3. Recording consent — review, verify, and withdraw per call The recording-consent console is the per-call side of the program: every consent receipt captured for a call, against which you can check the recording gate and action a data subject's withdrawal under GDPR Article 7(3). Open **Settings → Compliance → Recording Consent** (`/settings/compliance/recording-consent`). ### Look up a call's consent trail Enter the call ID and **Look up**. The audit trail lists every receipt captured for that call — receipt ID, consent method, state, who captured it, and when. In two-party-consent jurisdictions both the recipient and the originator must have granted; capture methods include IVR announcement, IVR DTMF, IVR speech, pre-recorded disclosure, operator attestation, verbal attestation, and written consent. ### Capture consent for a call Click **Capture consent** to record dual-party consent: the call ID, the method, an optional jurisdiction note, and an explicit grant from each party. Any decline is rejected and nothing is stored — a partial consent never looks like a valid receipt downstream. ### Verify a receipt against the recording gate **Verify** checks one receipt against the gate: is it live, granted, un-revoked, and inside its window? Use it before a dispute ("was consent valid for this call?") rather than after. **Issue digest** goes further — it produces a signed integrity digest that binds the consent receipt to the recording artifact itself. Copy the digest JSON and export it alongside the recording; **Verify digest** re-checks the signature later, so a tampered receipt or mismatched recording is detectable in litigation discovery. ### Withdraw consent (GDPR Article 7(3)) When a data subject withdraws: * **Withdraw** on a single receipt revokes that receipt after a confirmation, or * **Withdraw consent for this call** revokes every active receipt on the call in one action — the right reach when the per-receipt ID isn't to hand. A withdrawal is irreversible within the console and blocks any further recording of that call. It is also audit-preserving by design: the receipt row is stamped `revoked_at`, not deleted, and the withdrawal itself is recorded with a reason — your trail shows exactly who withdrew what, when, and under which right. API equivalents: `GET /compliance/recording-consent?call_id=...` (audit trail), `POST /compliance/recording-consent` (capture), `POST /compliance/recording-consent/verify` (gate check), `POST /compliance/recording-consent/:callId/revoke` (Art. 7(3) withdrawal), and the `/integrity` + `/integrity/verify` pair for signed digests. ## 4. Where the artifacts live for an audit binder Assemble the binder before the auditor asks: | Record | Where | What to export | | -------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DPA acceptance | **Settings → Compliance → DPA** | Signed PDF download + recorded version/date on the accepted pane | | BAA execution | **Settings → Compliance → BAA** | Signed PDF download + execution date and renewal deadline | | Per-call consent | **Settings → Compliance → Recording Consent** | Audit trail per call ID + signed integrity digests exported with the recording | | Cross-framework pack | **Settings → Compliance → Binder** | The [evidence binder](/guides/compliance-evidence-binder) assembles HIPAA (and three other frameworks) into a signed pack — its BAA section reads the posture you set here | | Action trail | **Settings → Audit Log** | Every acceptance, execution, withdrawal, and binder generation lands in your [audit log](/guides/audit-log) | One habit to build: download the signed PDF the day you accept or execute, not quarter-end. The on-platform record is permanent, but the 24-hour download link is not — and a binder assembled from dated PDFs reads better than one assembled from screenshots. ## Roles and limits at a glance * **Owner and admin** can view all three consoles, accept the DPA, capture/verify/withdraw recording consent, and toggle PHI-in-scope on the BAA. * **Owner only** can execute or re-execute the BAA and revert it to the default — a signature binds the organization. * Withdrawing recording consent is confirmation-gated and irreversible; it never deletes the receipt, so the audit trail survives the withdrawal itself.