Legal
Security
Last updated: October 23, 2026
The English version of this document is authoritative.
What the system does today, stated so each line can be checked rather than taken on trust. Where something does not exist yet, this page says so.
Certifications
Promvia does not have a SOC 2 report or an ISO 27001 certification. If your procurement requires one, tell us before you buy rather than after. What we can give you is this page, the Data Processing Agreement and written answers to your security questionnaire.
Where it runs
The application's server code runs on Vercel in Frankfurt (region fra1), and the database is Neon Postgres in Frankfurt (AWS eu-central-1). Pages and static files are delivered by Vercel's global edge network, from the location nearest the visitor. Vercel and Neon are United States companies. Every sub-processor is listed in the Data Processing Agreement with the country it is established in, where it processes data and the transfer basis.
Encryption
In transit and at rest:
- Every connection to promvia.app is HTTPS. The .app domain is on browsers' HSTS preload list as a whole, so browsers never connect to it over plain HTTP, and the site also sends its own Strict-Transport-Security header (two years, subdomains included, preload).
- The application connects to the database over TLS.
- The database, its point-in-time history and the other providers' storage are encrypted at rest by the providers, as they state in their own security documentation. We do not hold the keys for that layer.
- Our own nightly copy of the database is encrypted with AES-256 before it is uploaded.
Whose data a request can reach
Every read and write is scoped to the account making it, and inside a team to the sites that member may open. The check is in the data layer, not only in the interface, so a request that names another account's site is refused the same way the dashboard would refuse it, and tests cover it. A read-only team seat cannot make changes, and cannot give a connected app more than read access.
Passwords, sessions and sign-in
How an account is protected:
- Passwords are stored only as salted scrypt hashes, never in a recoverable form, and a new password is checked against the Have I Been Pwned breach corpus without sending the password itself.
- The session cookie is HttpOnly, Secure and SameSite=Lax. Sessions expire after 30 days, and we store only a hash of each session token.
- Changing your password ends every other session and disconnects every connected app; a password reset also revokes every API key, switches off every webhook endpoint and pauses every scheduled client report until you turn yours back on.
- Promvia accounts do not offer two-factor authentication yet. If you sign in with Google, your Google account's own two-step verification protects that sign-in.
Our own access
The internal admin area is open only to an explicit allowlist of email addresses set in the deployment's configuration. It is denied by default when the list is empty, and an address on it counts only after that account has proved it owns the mailbox. Customer accounts cannot reach it. The infrastructure accounts — hosting, database and code — are held by named people with their own credentials, and the list of people with production access is available on request.
Backups and recovery
Two layers, because the first one depends on the database provider:
- Neon's point-in-time recovery covers the last 6 hours, in the same Frankfurt region.
- A nightly copy of the database is encrypted with AES-256, checked to decrypt into a valid archive, and kept for 30 days as a GitHub artifact, then deleted. GitHub is listed as a sub-processor for this reason.
- Restoring a copy was rehearsed against the production database on 3 September 2026: every table matched row for row.
Connected apps and API keys
AI assistants such as Claude or ChatGPT connect through OAuth with PKCE. You choose what an app may do on a consent screen: read access, and each kind of change as its own box that starts unticked.
- Access tokens expire after one hour. Refresh tokens last 30 days and are replaced by a new one each time they are used.
- We never store access tokens; refresh tokens and single-use sign-in codes are stored only as SHA-256 hashes.
- You can see and revoke every app under Settings → Integrations → Connected apps. Revoking deletes its refresh tokens at once, and its access token is refused on its next request.
- An API key can only read through the connector, is stored as a keyed hash, and is revoked under Settings → Integrations → API keys.
Web and network protections
What the application refuses by default:
- A Content Security Policy is enforced on the signed-in app; on the public pages it runs in report-only mode: they are prerendered, and the framework's inline bootstrap scripts would need a per-request nonce to pass an enforcing policy.
- Pages cannot be framed by another site (X-Frame-Options: DENY), responses are not MIME-sniffed, and the referrer sent to other sites is the origin only.
- Public endpoints are rate limited.
- Fetches we make on your behalf, such as auditing a page, refuse private and link-local addresses, so an audited URL cannot reach internal systems.
- Error reports go to Sentry's EU region without IP addresses, cookies or request headers, and with email addresses masked.
If something goes wrong
If a personal data breach affects your data, we notify you without undue delay and in any event within 72 hours, with what we know at the time, and follow up as we learn more. That commitment is clause 7 of the Data Processing Agreement.
Reporting a vulnerability
If you find a security problem, email the address below with what you found and how to reproduce it. Please do not access or change other people's data, degrade the service, or publish the details before we have had a reasonable chance to fix it. We confirm every report we receive and tell you what we are doing about it. There is no paid bug bounty.
Security contact
Vulnerability reports and security questions: security@promvia.app.