Data processing addendum

1. Parties and scope

This addendum is between the operator of EmailTimer.App ("we", "the processor"), and the account holder named in the EmailTimer.App account ("you", "the controller"). It forms part of the terms of service and applies whenever we process personal data on your behalf under the GDPR, the UK GDPR, the Digital Personal Data Protection Act 2023, or the CCPA.

Where this addendum and the terms of service disagree about personal data, this addendum wins.

2. Roles

You are the controller for the personal data of your subscribers. We are the processor. For your own account data we are the controller, and the privacy policy covers that instead.

Under the CCPA we are a service provider. We do not sell or share personal information, and we do not retain, use or disclose it for any purpose other than performing the service.

3. Subject matter, nature, purpose and duration

Subject matter. Rendering countdown timers and personalized images for the emails you send, counting how often they are fetched, and storing the recipient lists you upload.

Nature of the processing. Receiving merge values in a signed image URL and rendering them into pixels; receiving and logging image fetch requests; storing, caching and deleting uploaded recipient rows; producing aggregate counts; taking backups.

Purpose. Providing the service, billing for it, and supporting you. Nothing else.

Duration. For as long as you have an account, plus the retention periods in section 6 of the privacy policy. The maximum tail after a deletion request is 30 days, which is the backup retention window.

Categories of data subjects and personal data. Annex 1.

4. Your instructions

We process personal data only on your instructions. Your instructions are the templates you publish, the recipient lists you upload, the URLs you send, the settings in your workspace, and this addendum together with the terms of service. Additional instructions can be sent in writing to privacy@emailtimer.app; if one of them needs work we cannot do within the subscription, we will say so and quote for it rather than ignore it.

If we believe an instruction breaks data protection law, we will tell you and may pause that processing. If a law requires us to process the data in some other way, we will tell you before we do it unless the law forbids telling you.

5. Confidentiality

Everyone with access to your data is bound to keep it confidential. Access is limited to what a person needs to run the service and support you, and it survives the end of their involvement. Today that is one person, the owner, and any change to that will be listed in annex 2 before it happens.

Operator access to a workspace, including impersonation for support, is recorded in the audit log with the actor and the time, and you can read your own audit log in the dashboard.

6. Security measures

The measures we take are listed in full, in checkable detail, on the security page, and annex 3 summarises them. In outline: HMAC-SHA256 signatures on every render URL with per-workspace rotatable keys; tenant isolation enforced in a repository layer and tested against every route with another tenant's valid credentials; hashed passwords and hashed API keys; Cloudflare Turnstile and layered rate limits on authentication; opaque recipient tokens so no name has to travel in a URL; no arbitrary outbound fetches from the render path; uploads identified by their bytes and capped by size and dimension; hourly encrypted-in-transit backups to a dedicated bucket with 30 day retention; a dependency audit that fails the build on high and critical advisories.

We do not hold SOC 2 or ISO 27001. The security page says so too.

We will not weaken these measures during your subscription. If we change them, they change to something at least as protective.

7. Sub-processors

You authorise the sub-processors in annex 2. Each one is bound by terms at least as protective as this addendum, and we stay responsible to you for what they do.

We will email your account owners at least 30 days before we add or replace a sub-processor. If you object on reasonable data protection grounds within those 30 days, tell us at privacy@emailtimer.app and we will try to find a way round it. If we cannot, you may cancel the affected part of the subscription without penalty and we refund the unused remainder of a prepaid period.

8. Data subject requests

If one of your subscribers contacts us, we will not answer for you. We will tell them to contact you, and tell you it happened.

We will help you answer them: finding what we hold for a token or an address, exporting it, correcting it, or deleting it. Most of it you can do yourself in the dashboard. Ask at privacy@emailtimer.app and we reply within one business day.

9. Assistance with impact assessments

If you are carrying out a data protection impact assessment or consulting a regulator about processing that involves us, we will give you the information we hold about how the service works: the data flows in section 4 of the privacy policy, the retention table, the sub-processor list, and the security measures. Ask at privacy@emailtimer.app. For a small number of questions a year this is free.

10. Personal data breach

If we confirm a personal data breach affecting your data, we notify you by email to your account owners within 72 hours of confirming it, and sooner if we can.

The notice will say what happened and when, which categories of data and roughly how many records and data subjects are involved, what the likely consequences are, what we have done to contain it, what we are doing next, and who to ask for more. Where we do not know all of that yet, we send what we have and follow up rather than wait.

We do not notify your regulator or your data subjects for you. That decision is yours to make, and we will give you what you need to make it.

11. Deletion or return on termination

When your account closes, or when you ask earlier, we delete the personal data we hold for you: the recipient rows, the cached copies of them, the uploaded files and the published template documents, within 30 days of the request. Per-request rows age out with their daily partitions within 30 days. Database backups are kept for 30 days, so a deletion works its way out of the backups within 30 days of the deletion.

Before deletion, you can export your usage data as a CSV from the analytics screen, and we will hand over a copy of the recipient rows on request in the same window.

We keep only what the law requires us to keep, which is billing records, and we keep those isolated from the rest.

12. Audit rights

You can satisfy yourself that we are doing what this addendum says in two ways. The security page is written to be checked rather than admired. And once in any 12 months you may send a written security questionnaire to privacy@emailtimer.app, which we answer within 30 days, including the parts we have to answer with "we do not do this".

We do not host site visits today. We are one person and one server, and an on-site audit is not something we can host honestly. If your procurement process requires one, say so before you buy rather than after.

13. International transfers

Personal data may be processed outside the country you are in, because the sub-processors in annex 2 operate across borders. Where a transfer needs a legal mechanism, the mechanism is the one appropriate to our place of establishment: the European Commission's standard contractual clauses for transfers out of the EEA, the UK addendum to those clauses for transfers out of the United Kingdom, and, where the entity is Indian, transfers permitted under section 16 of the DPDP Act 2023. The clauses are incorporated into this addendum by reference, with annex 1 as their description of processing, annex 2 as the list of sub-processors, and annex 3 as the technical and organisational measures.

14. Order of precedence

Where the standard contractual clauses and this addendum disagree, the clauses win. Where this addendum and the terms of service disagree about personal data, this addendum wins.

15. How to execute this

Using the service accepts this addendum. If your process needs a signed copy, email privacy@emailtimer.app with the account name, the legal entity you are contracting as, and a contact for notices, and you get a countersigned PDF of this version back.

Annex 1: what is processed, and about whom

Categories of data subjects

• Your email subscribers and customers, being the recipients of emails containing our image URLs.
• Your own people: the users you invite to your workspaces.

Categories of personal data, for recipients

• Merge values included in an image URL when it is signed: typically a first name, a coupon code, a balance, a per-recipient deadline. Whatever is signed into the URL, we render.
• Email addresses and any other columns in a recipient CSV you upload.
• An opaque per-recipient token we generate.
• Technical data from image requests. Each request is counted into daily totals by workspace, template and email client family; the family is parsed from the user agent string, which is then discarded. A request that fails, or is answered without being counted, is also recorded for 30 days with its time, template and version, kind of event, client family and a short reason. No user agent string, country, recipient token or IP address is stored for any request, though the request necessarily carries an address, and it is often the address of Apple's or Google's proxy rather than the person's.
• A hash of the image URL plus a timestamp, for timers that count from a recipient's first open.

Categories of personal data, for your users

Name, email address, hashed password, role, session records and audit log entries.

Special category data

None is asked for, and the service is not designed for it. If you put it into a merge value or a CSV column, you are the only one who knows, so do not.

Frequency

Continuous, for as long as emails carrying your image URLs are being opened.

Annex 2: sub-processors

Where a row does not name a country, we have not published one yet and will name it on request.

No advertising network, data broker, enrichment service or model training provider processes any of it.

Annex 3: technical and organisational measures

The current, detailed version of this annex is the security page, which is kept in step with the code. Summarised, under Article 32:

• Pseudonymisation. Opaque recipient tokens, so a render URL need carry no name or address. Evergreen first-open markers stored as a hash of the URL.
• Confidentiality. Per-workspace HMAC keys, rotatable, with retired keys revocable. Tenant isolation in a repository layer, tested against every route with another tenant's valid credentials and required to answer 404. Hashed passwords, hashed API keys. Secrets held as environment variables in the deployment platform, not in the repository. The image service has no database credentials at all.
• Integrity. Signed URLs verified before rendering. Published template versions are immutable, so a delivered email keeps rendering the version it was sent with. Append-only audit log.
• Availability. Hourly database dumps to a dedicated bucket with 30 day retention, restored by a script rather than from memory. A fallback chain that returns a valid image on any failure.
• Resilience of the render path. Rate limits per IP, per account and per API key.
• Testing and evaluation. Several thousand unit and integration tests plus an end-to-end suite that drives a real browser against real services, a generated tenant isolation suite, and a dependency audit that fails the build on high and critical advisories.

Change log