Security

What protects your data, where it lives, and — stated plainly — what we have not built yet.

Last updated: 5 September 2026

What we do to protect your data, where that data lives, what we honestly do not yet have in place, and how to reach us if you find a problem.

Contents

§1 In Short

Keupera is run by one person. That shapes what we can honestly claim, and we would rather you assess us on an accurate description than on a page of badges.

What is true: your data lives in the European Union. Each organisation is isolated at the database layer, not merely in application code. Credentials for the systems you connect are encrypted with a dedicated key and never reach your browser. API keys are stored only as hashes. The analytics and queue infrastructure is not exposed to the internet.

What is not yet true: we hold no ISO 27001 or SOC 2 certification, we have not commissioned an independent penetration test, and we do not run a 24/7 on-call rotation. § 5 lists the gaps in full.

This page is Annex II to our Data Processing Agreement at /legal/dpa and is incorporated into it.

§2 Where Your Data Is

Primary database, authentication and file storage: European Union — AWS eu-west-1, Ireland.

Analytics store, site crawler and MCP server: Germany, on dedicated servers at Hetzner Online GmbH.

Product analytics: European Union, PostHog EU Cloud region.

Application hosting and content delivery: operated by our hosting provider; request metadata and application logs are processed there.

Providers established outside the European Economic Area are listed at /legal/subprocessors, together with the transfer mechanism applied to each. We rely on the Standard Contractual Clauses, not on the EU–US Data Privacy Framework alone.

§3 Technical and Organisational Measures

Encryption

  • TLS on every public endpoint, for all data in transit
  • Encryption at rest at the infrastructure layer for the database, file storage and analytics store
  • AES-256-GCM with a dedicated key, held only in the server environment, for the credentials of connected accounts: Google OAuth tokens, content-management credentials and mail server passwords
  • Authenticated encryption, so tampering with a stored credential is detected rather than silently decrypted
  • API keys stored only as SHA-256 hashes, with a prefix and last four characters retained so you can recognise them; account passwords stored only as salted hashes by our authentication provider

Tenant isolation and access control

  • Row-level security in the database isolates each organisation's records at the data layer, independently of application logic
  • A four-tier role model — owner, administrator, member, client — restricts each person to the websites and actions assigned to them
  • The columns holding connected-account credentials carry no client-side grant at all: they are readable only by server-side code, so a browser request cannot retrieve them even in principle
  • Tables holding operational and abuse-prevention data are unreachable from the browser entirely
  • Internal services authenticate to one another with dedicated shared secrets

Network

  • The analytics database and job queue are not exposed to the public internet
  • Host firewalling restricts inbound traffic to the ports required
  • TLS certificates issued and renewed automatically

Data minimisation

  • Visitor IP addresses are hashed before entering the analytics store; the raw address is not persisted there
  • Secrets are excluded from application logs
  • Automated retention jobs enforce the periods published in our Privacy Policy, including a hard two-year ceiling on analytics data

Resilience

  • Managed, replicated database infrastructure with provider-operated backups and point-in-time restore
  • Job queues with automatic retry and recovery of stalled work
  • Restored data is re-processed to remove records that were deleted in the interim

Governance

  • A named point of contact for security and for data protection
  • A documented sub-processor list with a 30-day change-notification commitment
  • A record of processing under Art. 30(2) GDPR
  • Written confidentiality undertakings from any contractor engaged

§4 Incidents

4.1 Notification to customers. Where a personal data breach affects data we process on your behalf, we notify you without undue delay and in any event within 48 hours of becoming aware of it. We will not delay in order to complete our investigation; you get the facts as we have them, and updates as they emerge.

4.2 Notification to the supervisory authority. Where we act as controller and a breach is likely to result in a risk to the rights and freedoms of natural persons, we notify the Berlin supervisory authority within 72 hours, as Art. 33 GDPR requires.

4.3 Notification to individuals. Where a breach is likely to result in a high risk, we inform the affected individuals without undue delay.

4.4 What a notification contains. The nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point.

4.5 Records. We document every breach, including the facts, its effects and the remedial action taken, and make that documentation available to a supervisory authority on request.

§5 What We Do Not Yet Have

We publish this list deliberately. A security page that omits its gaps is a marketing page.

  • No ISO 27001, SOC 2 or comparable certification. We do not hold one and we do not imply that we do. If a certification is a precondition for your procurement, tell us before you contract rather than afterwards.
  • No independent penetration test. We have not commissioned a third-party test of the application.
  • No formal incident-response exercise programme. We have a documented procedure and a notification commitment, but we have not run a tested tabletop exercise.
  • No tested backup-restoration programme. Our database platform provides point-in-time restore; we have not run a scheduled restoration drill.
  • No 24/7 monitoring or on-call rotation. We respond during European business hours, and faster than that for security reports, but we do not promise round-the-clock coverage.
  • No formal vulnerability management programme. We update dependencies and act on advisories, but we do not operate a scanned-and-triaged pipeline with defined remediation windows.

We are working through this list, and we update this page as each item is addressed rather than in advance of it.

§6 Your Part

6.1 Credentials. Use a strong, unique password, or sign in with Google. Do not share logins between people; invite them as Members instead.

6.2 Roles. Assign the least privilege that lets someone do their job. The client role exists precisely so that an external party can see reports without seeing everything else.

6.3 API keys. Treat them as passwords. Never place one in client-side code, a mobile application or a public repository. Rotate immediately if a key may have been exposed.

6.4 Webhook addresses. An inbound workflow webhook address is a capability — anyone holding it can trigger your workflow. Do not publish it, and regenerate it if it may have leaked.

6.5 Connected applications. Our authorisation server supports dynamic client registration, so applications we have not reviewed can request access to your account and are shown to you as unverified. Grant access only to applications you trust, and review the list periodically.

6.6 Departures. Remove Members when they leave, and revoke the API keys they used.

6.7 Your own backups. We maintain backups for our own operational resilience. That is not a backup service for you. Export anything you cannot afford to lose.

§7 Reporting a Vulnerability

7.1 Where. Write to security@keupera.com. Include enough detail to reproduce the issue, the affected endpoint or component, and how we can reach you.

7.2 What we do. We acknowledge your report, investigate, keep you informed of progress, and tell you when it is fixed.

7.3 Safe harbour. We will not pursue legal action against researchers who act in good faith, who avoid privacy violations and disruption of the service, who access no more data than is necessary to demonstrate the issue, who do not exfiltrate or retain data belonging to others, and who give us a reasonable opportunity to respond before disclosing publicly.

7.4 Out of scope. Volumetric denial-of-service testing, social engineering of our people or our providers, physical attacks, and testing against systems operated by our sub-processors rather than by us.

7.5 Credit. We are happy to credit reporters publicly where they wish it. We do not currently operate a paid bug bounty.

7.6 A machine-readable contact is published at /.well-known/security.txt.