What a security review asks an email image service

We hold no SOC 2 Type 2 report and no ISO 27001 certificate. If your policy makes either one a gate, this page is the fastest no you will get all quarter, and you can stop reading at the end of this paragraph. If your policy allows a documented exception, everything below is the evidence a reviewer would ask for instead.

A martech security review wants the same bundle almost everywhere: the SOC 2 Type 2 report, a completed questionnaire, a penetration test, the sub-processor list, data residency, encryption, the data processing addendum, breach notification, retention and deletion. The procurement guides written for vendors list it in roughly that order, and say the review adds weeks to a deal when the vendor assembles it from scratch.

So here it is assembled. This page is the information security chapter of choosing a dynamic image and countdown timer vendor for an enterprise email programme, and it is written for your reviewer rather than your CRM lead.

What a review asks, and what we can send

Movable Ink’s own privacy, security and compliance page, read on 23 September 2026, lists a SOC 2 Type 2 audit for Studio and Da Vinci, ISO 27001, ISO 27701, ISO 42001 and annual third-party penetration testing, all of it behind a trust centre. That is the top of this category. We are not at the top of this category, and a page that implied otherwise would fall apart on the first call.

The three answers that are no

No SOC 2 report of any type. No ISO 27001 certificate. No penetration test report from an outside firm, because none has been commissioned. A Type 2 report covers a period rather than a date, which is why your reviewer asks for the audit window and the auditor’s name first, and a period of evidence is not something a one-person company produces by wanting to.

What we will not do is the thing the rest of this market does: answer “we follow SOC 2 principles”, or “we are SOC 2 aligned”, or hold up a sub-processor’s certificate as though it were ours. A sub-processor’s audit covers the sub-processor.

What we send instead

The security page is written to be argued with rather than admired. Every line on it is a claim your engineers can test against a live account in an afternoon, which is the only substitute a company this size can honestly offer for an audit opinion. Three of them carry the review.

Render URLs carry an HMAC-SHA256 signature over the path and the canonical query string, verified before anything renders, so a deadline, a merge value or a template id cannot be edited in a delivered URL. Signing keys are per workspace and rotatable: the new key signs at once, the old key keeps verifying so mail already in inboxes keeps working, and revoking the retired keys kills every outstanding URL in that workspace.

Tenant isolation is enforced in a repository layer that requires a workspace id, and the test for it is generated rather than written by hand. It walks every route on disk and calls each one signed out, as a member, and with a completely valid session belonging to a different tenant. The cross-tenant case has to answer 404 rather than 403, so the API never confirms that another tenant’s object exists.

The service that answers inbox requests holds no database credentials at all, by architectural contract. A template’s image layers can only point at an asset you uploaded, so nothing aims the render path at an internal address, and API keys are stored as a SHA-256 hash plus the non-secret prefix, so a leak of that table yields no working key.

The sub-processor list, which we can answer in full

Annex 2 of the data processing addendum names five: Cloudflare for the cache, key storage, object storage, backups, the sign-in bot check and account mail; one virtual private server running the API, the dashboard, the image service, the jobs, Postgres and Redis; Stripe for payments in dollars; Razorpay for payments in rupees; and Google, as the identity provider for Google sign-in. Each row says what that sub-processor sees. No advertising network, data broker, enrichment service or model training provider is on it.

We email your account owners at least 30 days before adding or replacing one. Object on reasonable data protection grounds inside those 30 days and we try to find a way round it; if we cannot, you may cancel the affected part of the subscription and we refund the unused remainder of a prepaid period.

Data residency, answered as far as it is published

The database and the cache run on one virtual private server, images are rendered on that same server, and published templates, uploaded images and database backups are objects in Cloudflare R2. The annex names the United States for Cloudflare, Stripe and Google, and India for Razorpay. It does not name a country for the server row, and it says so itself rather than leaving you to notice: where a row does not name a country, it has not been published and will be named on request. If your review needs a region commitment in writing, ask before you buy rather than in week three.

Transfers out of your region are covered by the standard contractual clauses, the United Kingdom addendum to them, or section 16 of the Digital Personal Data Protection Act 2023, whichever is appropriate, incorporated by reference with the DPA’s three annexes.

Encryption, stated only as far as the documents state it

Signatures are HMAC-SHA256. Passwords are hashed and salted, API keys are stored as hashes, evergreen first-open markers are a SHA-256 hash of the URL rather than anything readable, and the hourly Postgres dumps go to a dedicated bucket encrypted in transit, using a token that cannot read the rest of the account.

What the published documents do not state is a disk-level encryption-at-rest standard, so do not tick that box off this page. The restore drill is the other gap we write down rather than hide: it has run once, against a schema that predates the current tables, so a drill against the full schema is still outstanding.

What an image service sees that your sending platform does not

An image request arrives the way any web request does, carrying an IP address and a user agent, and in practice that address usually belongs to Apple’s or Google’s proxy rather than to a person. No row is kept for each request. Every open is counted into daily totals by workspace, template and client family, the family read from the user agent, which is then discarded. A row is written only for a request that fails or is not counted, holding the time, the template and its version, the kind of event, the client family and a short reason, and those rows are dropped after 30 days. No user agent string, country, recipient token or IP address is stored for any request, and the request logs replace every merge value in the image address. Until 23 September 2026 the privacy policy described a fuller row than this; the code never wrote one, and the policy now matches it.

An image URL can also carry values of its own, a first name, a coupon code, a points balance, a per-recipient deadline, but only where the URL was generated with them through the API, because the signature covers every parameter. Values that arrive that way are rendered into pixels and never written to a database. They do sit in the HTML of the email you already sent and in your platform’s send logs, which is a property of the email rather than of us, and it is why recipient tokens exist: upload the list, every row gets an opaque token, and the token is all that travels.

No cookies are set on your recipients. Nothing profiles them, enriches them, resells them, or trains a model on them.

Breach, retention and deletion

A confirmed personal data breach affecting your data is notified to your account owners by email within 72 hours of confirmation, with what happened and when, which categories and roughly how many records, the likely consequences, what has been contained and who to ask. Where something is not known yet, what is known goes out rather than waiting. Your regulator and your data subjects are yours to notify, not ours.

Per-request rows are dropped after 30 days. Sessions last 14 days, reset links 30 minutes, verification links 60. Backups are kept 30 days, so a deletion works its way out of the backups inside 30 days, and that is the longest tail anywhere in the product. Published template versions are the deliberate exception: they are kept while the account exists, because an email delivered eighteen months ago can still fetch one.

Once in any 12 months you can send a written security questionnaire to privacy@emailtimer.app and get it answered within 30 days, including the parts answered with “we do not do this”. We do not host site visits: one person and one server is not an on-site audit anybody should pretend to host.

What is still missing from our own documents

The contracting entity is not published. The addendum and the terms say “the operator of EmailTimer.App” where a registered name belongs, neither carries a registered address, and the terms have no governing law or venue section at all today. If your process needs a named counterparty and a jurisdiction before it can open a file, that is a blocker now rather than a surprise at signature.

Everything else here is checkable from the security page, the privacy policy and the data processing addendum, which are the three documents a reviewer should read instead of taking this summary on trust. The budget chapter is next: what dynamic images cost at enterprise volume, with the plan limits behind it on pricing. If the review is running beside a switch, moving off an incumbent without breaking mail already sent is the chapter on what a change of vendor does to mail already delivered.

Questions and answers

Is EmailTimer.App SOC 2 compliant?

No. There is no SOC 2 report of any type, and no ISO 27001 certificate. The security page says so, the privacy policy says so, and section 6 of the data processing addendum says so.

Can you sign our data processing agreement?

Using the service accepts the published addendum, which carries Article 28 terms, the sub-processor annex and the 72 hour breach timeline. If your process needs a signed copy, email privacy@emailtimer.app with the account name, the legal entity you contract as and a notices contact, and a countersigned PDF of that version comes back.

Does a recipient’s name have to appear in the image URL?

No. Upload a recipient list and every row gets an opaque token, so the address carries a token and the merge values are looked up on the server. That is the setup to choose when the review turns to personal data in query strings.

Who can see our data internally?

Access is limited to what is needed to run the service and support you, and today that is one person, the owner. Operator access to a workspace, including impersonation for support, is written to the audit log with the actor and the time, and you can read your own audit log in the dashboard.