These belong to the tenant-mail request (see
../communication/ses-production-access/phase-b.md). They are outlines, to be written properly when that phase starts, so the work is not forgotten and the first request is not weakened by promising controls that do not exist.
1. Tenant sending-vetting policy (internal)
Purpose: decide who may send campaigns and what is checked first, so one careless tenant cannot damage the shared sending reputation.
Sections to write:
- Scope: which features count as "sending" (newsletters, automations that email, forms replies, mailbox mail on the shared lane, API sends).
- New-workspace state: workspaces start unable to send campaigns; sending is unlocked by review.
- What we check: identity of the account holder; the sending domain and its authentication; the postal address; the signup form and consent wording; the source of the list (how it was collected, when); a sample of the first campaign (content, links, unsubscribe, sender identity).
- Decisions: approve, approve with a low cap and warm-up, ask for more information, decline. A reason and a reviewer are recorded.
- Warm-up and caps: daily and per-campaign limits for the first N sends, raised on a clean record (low bounce and complaint, real engagement).
- Red flags: purchased-list signs (a large list with no signup source, no engagement history, role addresses or old addresses), free-mail "From" addresses, link shorteners, URL reputation hits, high-risk categories (finance, health claims, adult, gambling, crypto, "work from home").
- Ongoing monitoring: the reputation thresholds already in the platform (warn 2.5% bounce / 0.05% complaint, pause 5% / 0.1%), abuse reports, sampling.
- Escalation and suspension: who can suspend a workspace, how fast, what is communicated, how an appeal works.
- Records: what is kept about each review, and for how long.
Prerequisites in the product: a per-workspace sending-approval flag enforced in comms, a staff review queue, a consent attestation on import, content and URL screening. None exists today.
2. Data processing addendum (for business customers)
Purpose: tenants are the controllers of their subscribers' and contacts' personal data and Vlozi processes it on their behalf. Business customers (and EU/UK ones) expect this in writing.
Sections to write:
- Parties and roles: customer as controller, Vlozi as processor; sub-processors authorised by reference to the published list.
- Subject matter, duration, nature and purpose: hosting, sending and delivering email, storing contacts, providing analytics on engagement.
- Types of data and data subjects: subscribers, contacts, form submitters, chat visitors, mailbox correspondents; names, email addresses, message content, engagement data.
- Customer instructions: processing only on documented instructions; the product's features are the instructions.
- Confidentiality of personnel.
- Security measures: reference the Security page and describe what is real today.
- Sub-processors: the published list, notice period, objection right.
- Assistance: with data-subject requests, security incidents, impact assessments.
- Breach notification: without undue delay, and the contact for it.
- International transfers: the mechanism relied on (standard contractual clauses where needed).
- Return and deletion: at the end of the service, a copy of the customer's data on request, and deletion on the schedule in
data-retention-schedule.md; this requires that schedule to be true. - Audits: information on request, and a reasonable audit process.
Prerequisite: the retention schedule must be implemented first. The addendum promises deletion and assistance with erasure that the code cannot do for every service today.