Security

Version 1.0 · Last updated TBD — launch date

TidyKB is built and run by one person. We don't have a security team or a SOC 2 report, so this page explains plainly what we do to protect your data, and what we don't do.

Contents

1. Where your data lives
2. Encryption
3. Access
4. How we build and run the product
5. Backups and deletion
6. Product-specific measures
7. What we don't have (yet)
8. Reporting a vulnerability

1. Where your data lives

The application and database run on servers rented from Hetzner in Germany (EU), in ISO 27001-certified data centres. DNS is run by our domain registrar; TLS certificates come from Let's Encrypt and are terminated on our own server, so the site does not sit behind a third-party proxy. We use Cloudflare only for the bot check (Turnstile) on our free tools. Other services that receive data are listed on the Subprocessors page.

2. Encryption

• All traffic uses HTTPS (TLS 1.2 or newer), with HSTS.
• Database backups are written with owner-only permissions on the server. We rely on our hosting provider's physical and storage security rather than adding full-disk encryption on top of it (see section 7).
• API keys, access tokens and other credentials for systems you connect are encrypted inside the database (libsodium sealed boxes) with a key that is stored separately from the database — the web application holds only the public half, so it can encrypt a credential but cannot read one back. They are decrypted only in memory, by the background worker, when a job needs them; they are shown back only as their last four characters, and never written to logs or error reports.

3. Access

• Only the founder can access production systems, using SSH keys and two-factor authentication on every admin account (hosting, DNS, source code, email, payments).
• Automated deployments use a separate key with limited rights.
• We look at your data only when needed to support you, fix a problem you reported, or investigate abuse or a security issue.
• Sign-in uses email and password or Google. Passwords are stored only as salted, slow hashes (never in plain text), and we never see them.

4. How we build and run the product

• Every database query is scoped to your organisation, and automated tests check that one customer can't see another's data.
• Dependencies are updated regularly. We do not yet run automated vulnerability scanning of them (see section 7).
• Staging and production are separate; staging never contains production personal data.
• Error reports are kept on our own server for 30 days and server logs for 14 days. Error reports are scrubbed of request bodies, cookies, query strings and authorisation headers before they are stored.
• Uptime is monitored automatically and alerts go to the founder.
• We follow a written incident procedure. If a breach affects your personal data, we will notify you within 48 hours of becoming aware of it (see the DPA).

5. Backups and deletion

• The database is dumped nightly and the dumps are kept for 14 days, beside our hosting provider's own automatic server backups. Restores are tested with a scripted drill that replays the newest dump into a scratch database.
• When you delete data or close your account, it is deleted from the live system within 30 days and from backups as they expire.

6. Product-specific measures

Your Freshdesk API keys

• Freshdesk's API uses a key tied to an agent, not a scoped OAuth token, so the key can do anything that agent can do. Create a dedicated agent with a custom role limited to Solutions (knowledge base) and connect that agent's key. Our connect guide walks you through it. (Custom roles need a Freshdesk plan that supports them; on other plans, use the lowest role that can edit Solutions.)
• The key you connect with is view-only and stays that way. Changing anything in your help center needs a second key, with Solutions edit rights, which you add on purpose; adding it does not switch writing on by itself — a separate confirmation does, and both actions are recorded in the activity log with who did them. Removing the edit key returns the connection to read-only at once.
• Both keys are sealed before they are stored, with a public key that is all the web application holds: it can seal a key, it cannot open one. Only the worker that calls Freshdesk holds the private half, and it opens a key in memory for the length of one job. A key is shown back only as its last four characters, and is never written to a log, an error report or your account export.
• Disconnecting deletes both keys in the same operation, immediately. You can also revoke a key at any time in Freshdesk by resetting the agent's API key or deactivating the agent.

What we call, and what we can't

• TidyKB only calls knowledge-base (Solutions) endpoints. Every request is matched against a fixed list before it is sent and refused inside TidyKB if it is not on it; a test fails the build if a client method could reach anything else. The list is published in full on our security page.
• There is no endpoint for tickets, conversations, contacts, companies, or any agent other than the one whose key you gave us — and no delete endpoint of any kind, so TidyKB cannot delete an article, a folder or a translation.
• A scan is read-only, and so is a find-and-replace preview: it only ever reads.

Changes to your knowledge base

• Nothing is written until you confirm a specific, previewed change. Before each article is written it is read again and compared byte for byte with the version you approved; anything that changed in the meantime is recorded as a conflict and never overwritten.
• What your help center held before the change, and what it held straight after, are both stored. That is what undo restores, and undo never forces an article that somebody edited after our write.
• A batch stops after three unexpected failures in a row, with everything already written still holding its snapshot.
• Freshdesk has no proven way to stage a draft beside a published article, so TidyKB does not offer one: a change is written live, and a job that asks for a draft is refused before a single request. New translations are created as drafts, and a translation that is already published on your portal is skipped rather than replaced with a machine draft.
• We keep a switch that stops every write to every customer's help center, undo included, without a request being sent.

How long we keep it

After you disconnect, the copy of your articles, your scan results and your undo snapshots are kept for 30 days so that an accidental disconnect cannot destroy an undo you still expect, then deleted automatically; "Delete my data" in the product deletes them at once. Snapshots and the change record undo needs are deleted 90 days after the last change to that record. A daily job enforces both windows.

The free audit crawler

The public audit only reads public pages, identifies itself as TidyKB-Audit (+https://tidykb.net/bot), respects robots.txt, makes at most one request per second per help center and stops after 400 articles. It uses no API key at all. Report links are long random URLs and are excluded from search engines.

7. What we don't have (yet)

• No SOC 2 or ISO 27001 certification of our own (our hosting provider is certified).
• No off-site backup copy yet: the nightly dumps sit on the same server, with the same provider, as the database they came from.
• No full-disk encryption of our own on top of the hosting provider's storage.
• No automated dependency or vulnerability scanning in our build pipeline; updates are reviewed by hand.
• No 24/7 on-call team: alerts reach one person, so outside business hours in Central/Eastern Europe responses can be slower.
• No bug bounty with payouts, but we are grateful for reports (see below) and will credit you if you like.

If your organisation needs a security questionnaire answered, email support@tidykb.net.

8. Reporting a vulnerability

Email security@tidykb.net with details and steps to reproduce. Please give us reasonable time to fix the issue before disclosing it, don't access or change other people's data, and don't run tests that degrade the service (no load or denial-of-service testing). We won't take legal action against good-faith research that follows these rules. We aim to acknowledge reports within 3 business days. A machine-readable contact is at /.well-known/security.txt.