Encryption in the live database
Account and profile details (names, email addresses, phone numbers and other profile fields), sign-in secrets, company billing contacts and space invitations are encrypted field by field in the live database. Account details use a key per person; company billing contacts and space invitations use a key per record. The database refuses to store these protected fields in readable form.
Read the transcript
A member saves a phone number. Illustrative example. A packet labelled Value moves from a page record toward the encryption area.
A fresh key encrypts the value. AES-256-GCM. The record is shown as Sealed value.
The person's key wraps that key. Wrapping means encrypting a key.
The app cannot export the master key. A separate key for each value. The master key wraps the person's key, and the sealed value is stored in the live database.
A fresh AES-256-GCM key encrypts each value. That value key is encrypted with the person's key, which is encrypted with a master key. “Wrapping” means encrypting one key with another. The app cannot export the master key. Each encrypted value is bound to its person, record and field.
The app and key service run on the same server. Record identifiers, relationships and encrypted-value sizes remain readable.
Messages, posts, guest details, mailing contacts, billing details copied onto issued invoices, our records of sent emails and some other operational records are not yet encrypted this way. Uploaded files, including avatar images and provider invoice PDFs, are not protected by this field-encryption layer.
| Data | Live protection | New backups |
|---|---|---|
| Account and profile details: names, email addresses and phone numbers, plus sign-in secrets | Encrypted with per-person keys | Per-person protection inside an encrypted database backup |
| Company billing contacts and space invitations | Encrypted with per-record keys | Per-record protection inside an encrypted database backup |
| Password verifiers | bcrypt hashes inside encrypted records | Protected records inside an encrypted database backup |
| Messages, posts, guest details, mailing contacts and event invitations | Not covered by field encryption | Included in the encrypted database backup |
| Issued-invoice billing copies, sent-email records and some other operational records | Not covered by field encryption | Included in the encrypted database backup |
| Uploaded files, including images and provider PDFs | Not covered by field encryption | Encrypted as part of the file backup |
| Card numbers and security codes | Sent directly to Stripe online, or handled by the card-terminal provider | Not held by Kommonz |
What is protected, and where
Account and profile details: names, email addresses and phone numbers, plus sign-in secrets
- Live protection
- Encrypted with per-person keys
- New backups
- Per-person protection inside an encrypted database backup
Company billing contacts and space invitations
- Live protection
- Encrypted with per-record keys
- New backups
- Per-record protection inside an encrypted database backup
Password verifiers
- Live protection
- bcrypt hashes inside encrypted records
- New backups
- Protected records inside an encrypted database backup
Messages, posts, guest details, mailing contacts and event invitations
- Live protection
- Not covered by field encryption
- New backups
- Included in the encrypted database backup
Issued-invoice billing copies, sent-email records and some other operational records
- Live protection
- Not covered by field encryption
- New backups
- Included in the encrypted database backup
Uploaded files, including images and provider PDFs
- Live protection
- Not covered by field encryption
- New backups
- Encrypted as part of the file backup
Card numbers and security codes
- Live protection
- Sent directly to Stripe online, or handled by the card-terminal provider
- New backups
- Not held by Kommonz
This describes new backups. Copies retained from before and during our September 2026 migration may have different protection and are kept until they are retired.
Connections and sign-in
Browsers and the Kommonz apps connect over HTTPS using TLS 1.2 or 1.3. Plain HTTP requests are redirected to HTTPS, and browsers are told to use HTTPS only.
The iOS and Android apps refuse unencrypted connections to our servers. On the device, sign-in tokens are kept in the iOS Keychain or Android Keystore-backed encrypted storage.
Passwords are stored only as bcrypt hashes, never in readable form. Those hashes are themselves kept inside encrypted records. Sign-in finds an account using a keyed fingerprint of the email address.
Who can open a detail
When someone views a protected detail, the app first checks their space, role and field access, and only then asks the key service to open the value. Scheduled jobs, such as billing runs, also open protected details without a person viewing them. A database copy or database login on its own shows only sealed values for these fields.
Read the transcript
A page asks for a detail. Illustrative example. The request reaches the permission check.
The app checks permission: space, role and field.
The permitted field is opened. The key service opens a value for the permitted page request.
Database access alone shows sealed values for these protected fields. The separate database-only route ends at Sealed value.
A page asks for a protected detail. The app checks whether the viewer may see that field in that space. Only then does it ask the key service to open the value. A database login alone does not provide access to the key service.
This protection does not exclude trusted administrators who operate the servers, deployments and sign-in system. We do not claim that Kommonz itself is locked out.
The app's server-side cache holds unlocked values for at most a minute. Every request to the key service is recorded, without the data itself.
Backups, retention and deletion
Every day we back up the database, uploaded files and service configuration. The backup is encrypted on our server before it is copied to storage in the EU. Protected personal details inside new database backups also keep their field encryption. The storage provider does not hold the backup key.
In the live database, selected personal fields are encrypted individually. A new database backup encrypts the whole export, including other records. The completed encrypted copy is sent to storage in the EU. Each week a backup is restored into an isolated environment and checked.
- Backup schedule
- Every day.
- Copies kept on our server and off-site
- 7 daily, 4 weekly and 6 monthly copies.
- Restore check
- Every week, in an isolated environment.
The key service is backed up daily, and the material needed to recover it is held in several independent places.
A scheduled job deletes records past their retention period every day. The retention periods are listed in our privacy policy.
When someone asks us to delete their account, in the app or through our account deletion page, we record the request straight away and complete it within 30 days. This includes removal requests to our service providers where they hold the person's data. Scheduled backup copies expire on the daily, weekly and monthly schedule; the last monthly copy is gone within six months. Copies made before and during our September 2026 system migration are kept outside that schedule until they are retired.
Deleting protected details
Our account deletion process includes destroying the person's key. After caches expire, details protected by that key can no longer be opened in the live database or in backups protected by that key. This is an operator-run step within the 30-day deletion process. It does not erase copies or files that were not protected by that key.
Current limits and planned work
- Live database files.
- The server disk and live database files are not encrypted as a whole. The field protection described above applies to selected personal details.
- Details outside field encryption.
- Messages, posts, guest details, mailing contacts, issued-invoice billing copies, sent-email records, some other operational records and uploaded files are not yet protected by that layer.
- Planned work.
- We plan to move Kommonz to a dedicated server with full-disk encryption.
Certifications
Kommonz does not currently hold a SOC 2 report or an ISO/IEC 27001 certificate. Our hosting provider's data centres are ISO/IEC 27001:2022 certified, and Stripe is a PCI DSS Level 1 service provider.
Where your data is stored
The Kommonz database, uploaded files and application servers are hosted in Germany by Hetzner Online GmbH, whose data centres are certified to ISO/IEC 27001:2022.
Traffic to our websites and apps passes through Cloudflare. Our database is not reachable from the internet; it accepts connections only from the Kommonz server itself.
Encrypted backup copies are stored in Cloudflare R2 storage restricted to the EU.
The service providers that process data for Kommonz, and what each receives, are listed in our privacy policy.
Accounts and access
Spaces give each person a role: member, staff, admin or owner. The role decides what that person can see and change. People can sign in with a password, Google or Apple. Repeated failed sign-ins are rate-limited.
Sign-in sessions use access tokens that expire after 15 minutes and refresh tokens that are replaced each time they are used. If a replaced refresh token is used again, the session's refresh tokens are revoked and its access tokens lapse within 15 minutes. A session ends after 90 days at most, and the person then signs in again.
Apps that a person connects through our MCP connector sign in through an OAuth consent screen and act only within that person's role and the permissions the person approves.
Administrative logins to our servers use SSH keys or our private network's sign-in. Password logins over SSH are disabled.
Keeping each space's data separate
Each space's records, such as memberships, bookings, invoices and events, are tied to that space.
Row-level security policies in the database limit what a signed-in person can read or change through the Kommonz data API to the spaces they belong to and the role they hold there. The Kommonz API checks the person's space and role before it acts on other requests.
Public pages, such as a space's storefront, event pages and room availability, are served by a fixed, documented set of database functions that reveal only what those pages need. An automated check on the live system flags any change to that set.
Payments
Online card payments in Kommonz are processed by Stripe, a PCI DSS Level 1 service provider.
On the web, people pay on Stripe-hosted pages. In the iOS and Android apps, Stripe's own payment form collects the card details. Card numbers and security codes go directly to Stripe and never reach Kommonz servers.
Member payments go into the space's own Stripe account. At card terminals, Kommonz sends the amount, currency, invoice number and chosen reader. The terminal provider handles the card.
Monitoring and releases
Monitoring
Requests to the Kommonz API and web app are logged with a request ID. We keep logs for 93 days. Errors are reported to Sentry's EU region. Personal fields are removed before an error report leaves our servers.
Alert rules notify us when a service or public address goes down, when a scheduled job or backup is late or fails, when a backup cannot be restored, when disk or database capacity runs short, and when a certificate is close to expiry. Stopped services are restarted automatically within a minute.
Door unlock attempts are recorded, and the records are kept for 90 days. Product analytics in the web app use PostHog's EU region and start only after the visitor agrees. Session recordings mask all text and form inputs.
Independent uptime checks run every minute from four locations; view service status.
Changes to Kommonz
Every code change to the Kommonz web app, API, website and mobile apps goes through a pull request into a protected main branch. Release version bumps are committed by our release bot. Changes normally reach production as numbered releases that an automated pipeline deploys, and each pipeline run is logged.
Each new web release is checked as soon as it starts. If it does not answer, the previous version is restored automatically. Development and testing use separate signing keys.
AI features
Three Kommonz features use OpenAI's API.
Email campaign drafts
The campaign drafting assistant in Mailing runs only when a staff member asks it to. OpenAI receives the request, the draft, the space's name, address, sender name, sign-off and campaign styling, its published events and perks, and the previous campaign. It does not receive the member list or the campaign's recipients.
Payment explanations
Short explanations of items in the payment reconciliation queue are produced for spaces that connect a workspace-management system such as OfficeRnD. OpenAI receives the invoice and payment involved and that customer's other open invoices: customer and payer names, invoice numbers, amounts, statuses, dates, the receiving account name and payment references. We send no email addresses.
Support assistant
Our support assistant uses OpenAI to answer a staff member's questions from the space data that staff member allows it to access. It is a separate service. It can read or change a space's Kommonz data only within the permissions a staff member of that space explicitly grants it, limited to that staff member's role.
Email reply drafts
Our API also includes an email reply-drafting tool for a mailbox a space has connected. When a staff member asks it for a draft, Anthropic receives the incoming email (sender name and address, subject and text), the space's name, the reference documents the space uploaded and the mailbox's sender name and address. This data may be processed in the United States and other countries.
Provider terms and storage
OpenAI's data processing addendum is part of our agreement with OpenAI. Because Kommonz is based in the EU, our contract is with OpenAI Ireland Ltd. OpenAI Ireland passes data to its US affiliate under standard contractual clauses, and to its sub-processors under standard contractual clauses or an adequacy decision, so the data may be processed in the United States.
OpenAI does not use data sent through its API to train models unless the customer opts in. We have not opted in. Kommonz asks OpenAI not to store these requests as saved responses.
OpenAI may keep abuse monitoring logs for up to 30 days, unless the law requires longer retention.
The campaign drafting assistant and the reconciliation explanations each use their own restricted key in a Kommonz-only OpenAI project. The support assistant uses a separate key under the same OpenAI agreement, in a project shared with our other products.
Report a security problem
If you think you have found a security problem in Kommonz, email security@kommonz.com. Please read our vulnerability disclosure policy first. It explains what you may test, how we respond and how we protect good-faith research. We do not run a paid bug bounty. Our contact details are also published in security.txt.
Incidents
We investigate every alert and every security report. If a personal data breach affects personal data that a space controls, we tell the space's owners without undue delay, so the space can meet its own notification duties under the GDPR. We share what we know, what we have done, and what the space may need to do, and we keep the space updated until the incident is closed. Where we are the controller, we notify the Estonian Data Protection Inspectorate and the affected people as the GDPR requires.
Contact
Security reports and security questions: security@kommonz.com.
Privacy requests: justin@kommonz.com, as described in our privacy policy.
Coworking spaces use Kommonz to run memberships, bookings, events, billing and door access. Kommonz is built and operated by LaserFocused OÜ, an Estonian company in Tallinn. Each space normally controls the member records it manages in Kommonz, and we process those records on the space's instructions, as described in our privacy policy.
LaserFocused OÜ, Telliskivi tn 49, 10611 Tallinn, Estonia. Registry code 17118792.