Your data stays in the European Union
Processed in Frankfurt and elsewhere in the EU, never transferred out, and secured the way we ask our customers to be. Everything on this page can be pointed at: a provider on our sub-processor list, a setting in the product. What we cannot show, we do not claim.
SupabaseGermany
VercelEU
Amazon Web ServicesFrankfurtCloudflareEU edge
SentryEU
MollieEU
GitHub and Namecheap, in the United States, are suppliers, not sub-processors: they hold source code and a domain, never customer data.
Frankfurt
Delivering security and privacy you can check
The eight questions a reviewer asks first, with our answers. Each one points at something you can open.
Uptime
The application, the database and the scanners run on managed infrastructure with redundancy and automatic recovery, so a failure in one part does not take the rest down.
Encryption
Encrypted in transit on every connection and at rest at every provider. Every credential you hand us is stored encrypted and used only for the read it was given for.
Data centers
Germany for the database and sign-in, Frankfurt for the scanners and mail, the EU for the application.
Compliance frameworks
No certificate yet. We are preparing for ISO 27001 the way we ask customers to: the controls run in Sudory itself and the readings are public on our profile.
See our profileData hosting
Customer data is processed in the European Union only and never transferred out.
Defense in depth
Several independent layers between a request and your data: protection at the network edge, sign-in with a second factor, fine-grained permissions with separation of duties, and strict isolation of every customer's data.
Shift left
Every change is tested and reviewed before release, a warning in the build stops it, and dependencies and secrets are watched continuously.
Continuous scanning
We scan sudory.com with our own scanners every day, DNS, mail, headers and accessibility, and show the readings on our vendor profile.
See our profile
Designed with your security needs in mind
Where your data lives, how little of it we keep, who can reach it, and how you can prove all of that to your own auditor.
Data minimization
We ask for the least a vendor allows, and keep the fact rather than the person.
Fly.io · Read-only org token
GitHub · Granular read scopes
- AWS · Read-only role you create
Read-only wherever it exists
Granular read scopes, read-only tokens and read-only roles. Where a vendor offers only broader access, the connector page says so before you connect.
Facts, not people
A reading keeps the fact, not the names in it. Personal data is removed before anything is stored.
Anonymous error reports
Error reports carry no personal data. They tell us what broke, never who was there.
Data access and erasure
No passwords to leak, a role for every person, and a way to be forgotten that keeps the record intact.
- Email codefirst factor
- Passkeysecond factor once trusted
- Authenticator appsecond factor, with recovery codes
- Single sign-on, SAMLthe only way in for your domain
| Role | Read evidence | Change things | Billing and roles |
|---|---|---|---|
| Owner | yes | yes | yes |
| Manager | yes | yes | no |
| Viewer | yes | no | no |
Two-factor, enforceable
An Owner can require a second factor for everyone in the organisation, and any member can end all of their sessions at once.
Roles you compose
Owner, Manager and Viewer are presets. Compose your own from fine-grained permissions, and add separation-of-duties rules that the product enforces.
The auditor seat
An invited auditor is a Viewer: every finding, control and piece of evidence, and no way to change any of it.
Erasure that keeps the record
A person who asks to be forgotten is removed; the events they caused stay, attributed to no one. Leavers lose access the moment they are removed.
Accountability and compliance
The evidence log is the record your auditor reads, this site carries the protections a reviewer checks, and every change passes the same gates before release.
What an event looks like, as an example
- 09:14:02readingaws · bucket "exports" · public access blocked
- 09:14:02readinggoogle workspace · 2-step verification · 41 of 41 members
- 09:15:40changepolicy "backups.daily" · threshold set to 24 hours · by an owner
- 09:21:11readinggithub · branch protection on main · required reviews 1
What this site enforces in every browser
- Encrypted connections only
- Browsers are told to never reach sudory.com over an unencrypted connection, and keep that rule for a year.
- Only our own code runs
- A content security policy allows scripts, styles and connections from the sources we name and nothing else.
- Cannot be framed
- No other site can embed sudory.com, which closes the door on clickjacking.
- No referrer leaks
- Addresses of pages you visit here are not passed on to other sites.
- No device access
- Camera, microphone and location are switched off for the whole site.
Append-only
Every reading and every change is an event with its timestamp. Nothing is pruned or edited after the fact.
Zero-error policy
A warning in the build stops the release. An error in production is fixed or explicitly accepted the day it appears. Every change is tested and reviewed first, and no developer has access to production data.
Sudory on Sudory
We run our own controls in the product and scan our own domain daily. The readings are on our vendor profile.
Additional resources
Ten sub-processors that handle customer data, three suppliers that never do, and the documents a reviewer asks for.
- Amazon Web ServicesEU
BrowserCat
Browserless
ResendUS
UmamiEU
Suppliers, no customer data
What we do not claim yet
No certificate yet. Sudory holds no ISO 27001 certificate or SOC 2 report today. We are preparing for certification the way we ask our customers to: the controls run in Sudory itself, the evidence collects every day, and the readings are on our profile for anyone to read. Nothing on this page is legal advice.