Security · Effective {{EFFECTIVE_DATE}}

Security and breach notification

What we do to protect data, honestly described, and how to report a problem.

1 · Measures

• Passwords hashed with Argon2id; the plain password is never stored.
• Provider keys and OAuth tokens encrypted at rest; the key is held outside the database.
• HTTPS everywhere, with HSTS and a restrictive set of security headers.
• Sessions in HttpOnly, SameSite cookies; you can see and end your sessions; optional two-factor authentication.
• Every query that reads your data is scoped to your organisation; a foreign project answers "not found". Automated checks fail the build if a query loses its filter.
• Rate limiting on sign-in and administrative endpoints; an audit log of changes, of administrators opening an account and of "view as" sessions, kept for 12 months.
• Email bodies, which can contain one-time links, are emptied from our mail queue 7 days after sending; card identifiers used for referral checks are kept only as keyed hashes.
• Backups on a rotating window and before risky operations; restores are tested on a copy.

2 · What this is not

This is a small operation on a single server. It has no formal security certification (no SOC 2, no ISO 27001) and no independent penetration test. Judge it as what it is.

3 · Report a vulnerability

Write to {{CONTACT_EMAIL}} with what you found and how to reproduce it. Please do not access other people's data, do not degrade the service, and give us reasonable time to fix before you publish. We will not take legal action against good-faith research that follows these rules.

4 · If something goes wrong

If a personal data breach affects data we process for you, we tell you without undue delay and within 48 hours of becoming aware of it (see the Data Processing Agreement), so that you can meet your own 72-hour duty to the supervisory authority. Where we are the controller we notify the Bulgarian Commission for Personal Data Protection within 72 hours where required, and affected people without undue delay where the risk to them is high. We keep an internal register of every incident, whether or not it has to be reported, and we check the rules of the US states where affected people live.

5 · Staff access to customer accounts

Staff do not browse customer accounts. When support needs to see what you see, an administrator opens a "view as" session that is read-only, expires after 30 minutes, needs a stated reason, is written to the audit log, and is visible to you under Account › My log › Support access. Staff cannot read your Google tokens or the data imported from Google, your payment card details, your stored provider keys or your password hash. Administrators use individual accounts. When an administrator opens your account in the admin panel, the view is written to the audit log (who, when, from which network) and kept for 12 months; routine views are not emailed to you, and you can ask us for them.

{{COMPANY_LEGAL_NAME}} · {{COMPANY_ADDRESS}} · {{COMPANY_VAT}} · {{CONTACT_EMAIL}}
Effective {{EFFECTIVE_DATE}} · Terms · Acceptable use · Privacy · Data Processing · Refunds · Sub-processors · Cookies · Copyright · Accessibility