Skip to content

Subject rights — ZevSend

How NDPA-granted user rights are fulfilled against ZevSend data. Most rights flow through ZevID centrally (account-level rights are exercised on accounts.zevop.com); this page covers what ZevSend does specifically.

Entry point for formal requests: dpo@zevop.com. The DPO office triages and forwards relevant items to ZevSend engineering.

Two subject types

ZevSend handles two distinct subject types: customers (developer-customers using the platform — ZevSend is the controller) and recipients (the message recipients customer applications dispatch to — the customer is the controller, ZevSend is the processor). Recipient subject-rights requests are routed to the controlling customer, not handled by ZevSend directly. Everything below is for customer subject-rights requests.

Right of access (NDPA §34)

  • Self-service today: the customer dashboard surfaces every team / domain / display-name / sender-id / API key / template / message-log / suppression / webhook / invoice the customer is associated with.
  • Formal request: the DPO office can ask engineering to produce a complete export. Until a self-service export is built, this is a manual query on the production DB, scoped to the requesting account's rows.
  • Clock: 30 days per NDPC GAID.

Right of rectification (NDPA §35)

  • Self-service: most customer-editable fields (team name, domain brand fields before admin approval, template content, webhook URLs, payment method on file at ZevPay) are editable directly in the dashboard.
  • Not self-service: post-approval domain brand identity (locked at admin approval — change goes through support → admin re-review), post-payment invoice line items, audit-log rows. These are corrected via admin action with the change captured in the audit log itself.

Right of erasure (NDPA §36)

  • What we erase on request: team metadata, custom-edited fields, domain rows (de-registered from SES on deletion), display-name applications, sender-id applications, API keys (revoked + hash retained for audit), webhook subscriptions, message-log rows (the customer-controller's call — recipient-side rights flow to the customer, not us).
  • What we retain with legal basis: invoices, subscriptions, payment-method tokens, admin audit logs, ZPIP token + delivery audit — financial-record-adjacent + security-forensic. Retention period aligns with CBN 7-year obligations when formalised.
  • What we retain under legitimate interest (anti-spam): per-team suppression-list rows. A hard-bounce or complaint signal we received from the carrier is regulatory operational metadata that must continue to be honoured; it's not customer-controlled data. The customer can manually remove a specific row from their suppression list, but bulk deletion of the suppression set is refused.
  • Cross-product cascade: ZevSend writes a de-enrollment to ZevID.
  • Clock: 30 days.

Right to restriction (NDPA §37)

  • Implementation today: admin can suspend a team which freezes all writes against its resources while retaining the rows. Used for abuse holds, regulatory enquiries, and unresolved billing disputes.

Right to data portability (NDPA §38)

  • Not self-service yet. On request, engineering produces a CSV / JSON dump of the customer's tables (teams, domains, display names, sender-ids, templates, messages metadata, suppressions, webhooks, invoices). The dashboard's data-export feature is on the roadmap.
  • ZPIP consent: a customer revokes any cross-product consent (e.g. a downstream product's right to send mail on their behalf) from the Connected Apps screen at accounts.zevop.com. ZevID propagates the revocation; ZevSend no longer accepts ZPIP calls under the revoked scope from the moment the revocation lands.
  • Marketing comms to the customer themselves: not currently sent to ZevSend customers (see processing.md). When marketing is introduced, a separate consent record will live in ZevID and the unsubscribe path will route through there.
  • Marketing comms from customer applications: ZevSend is the processor, not the controller, for those messages. Recipient unsubscribe requests are routed to the controlling customer through the message's List-Unsubscribe headers and the customer's own opt-out flow. ZevSend additionally maintains the per-team suppression list as a backstop — once a recipient lands on it (via carrier complaint or manual flag), sends to that recipient from that team are blocked even if the customer's own opt-out flow has a gap.

Children

ZevSend is a developer-tools product and our terms require account holders to be 18+. We don't knowingly process children's data. If a children's-data report reaches the DPO, the account is suspended pending investigation. End-user recipients of customer applications may include children (depends on the customer's product); the customer is the controller and responsible for that determination.

Process

  1. DPO office receives the request (verifies the requester via ZevID).
  2. DPO triages: is this access, rectification, erasure, restriction, portability, or objection? Is this a customer subject right (handled here) or a recipient subject right (routed to the controlling customer)?
  3. DPO forwards the actionable items to ZevSend engineering with the relevant account / team identifiers.
  4. Engineering executes (admin actions + DB updates), captures the change in admin_actions, and confirms back to the DPO.
  5. DPO responds to the data subject within the NDPA clock.