Where your data is
The database holding everything you upload is in Ireland (Dublin, `eu-west-1`). The application runs on serverless functions pinned to Dublin. Traffic is encrypted in transit with TLS; the database and its backups are encrypted at rest. The database is backed up daily.
Five of our seven subprocessors may involve transfers outside the EEA — the hosting provider’s parent company, Google (for sign-in and, only if you connect your own Gmail, for sending from it) and Microsoft (for sign-in and, only if you connect your own Outlook, for sending from it) — and those transfers rely on the European Commission’s Standard Contractual Clauses and the EU–US Data Privacy Framework. Our email provider, Amazon Web Services EMEA SARL, processes mail data in Germany (Frankfurt) and the data stays in the EU; its parent company is US-based, and the AWS data processing addendum with Standard Contractual Clauses applies. Our error-diagnostics provider, Functional Software, Inc. (Sentry), uses its EU data region (Frankfurt), receives only events scrubbed of personal data, and is a US company, so the same Standard Contractual Clauses and Data Privacy Framework apply. Each one, what it receives and where it sits is listed at Subprocessors.
Separation between customers
Every row of your data carries your company’s identifier, and the database refuses to return a row belonging to anyone else. That rule lives in row-level security policies inside the database, not in the application code that queries it.
The distinction is the whole point. Application-level checks are the ones that get forgotten in a new query or bypassed by a bug; a database policy applies to every query that will ever be written, including one written by mistake. The rule we hold ourselves to is that a permission check in a request handler is not an access control — if it matters, it is enforced next to the data.
Who can reach your data
Signing in is by one-time email link, or by Google / Microsoft sign-in. There is no password to be reused, guessed, leaked in someone else’s breach, or left in a browser on a shared machine.
Each user can add a second factor, an authenticator app, in Settings. Once it is on, the database itself refuses that account’s data to a session that has not completed it, so the emailed link alone is no longer enough.
The elevated database credential — the one that can read across companies — exists only for the scheduled sender, for signed inbound webhooks, and for the moment an account or an invitation is created. It is never present in anything sent to a browser, and no request made by a signed-in user runs with it.
Colleagues are added by invitation, and only the account owner can issue one. That restriction is enforced in the database rather than in the invite screen, for the same reason as above.
Constraints on sending
The most damaging thing this product could do is send email it should not have sent. Every constraint on sending is therefore applied inside the database, at the instant a message is claimed for delivery, so that no code path can skip one and two overlapping runs cannot send the same message twice:
- the master sending switch, off until you turn it on;
- a verified sending domain, either your own or the one QFUtool provides;
- your send window and weekdays, so nothing arrives at 2am on a Sunday;
- your daily cap;
- your plan’s monthly allowance;
- the requirement that a human has opened and saved the message copy before it can go out;
- the suppression list — anyone who unsubscribed, bounced or marked a message as spam, checked again at the moment of sending and not only when the message was queued.
Unsubscribing needs no account and no sign-in: every message carries a link with an unguessable per-quote token, and the page it opens works for the recipient, who is not a user of this product and can never have a session.
Accuracy of what we read from your file
A quoted amount misread by a factor of a thousand would mean chasing a customer about the wrong figure, in your name. So a value that cannot be read with confidence is never guessed at: ranges, ambiguous thousands separators and unreadable cells are set aside for a person to look at rather than pushed into the queue. Columns are identified by the values in them, not by what the heading says. The confirmation screen states the outcome in words — who will be emailed, about what amount, signed by whom — before anything is saved.
What is deliberately absent
No analytics provider, no advertising or retargeting pixel, no session recording, no heat maps, no fingerprinting, no cross-site tracking. None of it is missing by configuration; none of it is in the product.
No artificial intelligence provider receives your data, and nothing you upload is used to train a model — ours or anyone else’s.
Typefaces are downloaded when the site is built and served from our own domain, so no visitor’s browser contacts a font provider and no IP address is disclosed to one.
Our control framework
We use the SOC 2 Trust Services Criteria as the framework our security controls are organised against, and we maintain a written mapping of each control to the criterion it addresses, updated as the product changes.
To be unambiguous about what that does and does not mean: we have not completed a SOC 2 audit and we hold neither a Type I nor a Type II report. We do not describe ourselves as SOC 2 certified or SOC 2 compliant, because we are not. If your procurement process requires the report itself, tell us — it changes what we would need to do, and we would rather say so than let the question go unanswered.
For processing under the GDPR, the binding commitments are in our Data Processing Agreement, which takes effect when you confirm at signup and needs no signature.
What we are still building
Published here because a security page that lists only strengths is not much use to someone assessing us:
- Two-factor authentication required for a whole team. Each user can turn it on; an account owner cannot yet make it compulsory for everyone.
- A self-service account log. Sign-ins, settings changes and membership changes are not yet presented back to you in a form you can review.
Reporting a security problem
If you believe you have found a vulnerability, write to office@sns-austria.com with enough detail to reproduce it. We will acknowledge within two working days and keep you informed until it is resolved.
Please do not test against other customers’ data, degrade the service for anyone else, or disclose the issue publicly before it is fixed. We will not pursue anyone who reports in good faith within those limits.