1
How we think about it
A pretty interface is worth nothing if the numbers behind it are exposed. Security here is not a page you write once — it is a set of controls reviewed on a schedule, tested by people who did not build them, and designed on the assumption that any single layer will eventually fail.
The programme is mapped to recognised frameworks rather than invented in-house: the NIST Cybersecurity Framework 2.0 for structure, the OWASP Application Security Verification Standard for how the app itself is built, and the CIS Critical Security Controls for the operational baseline.
2
Encryption
In transit. TLS 1.3 everywhere, with TLS 1.2 as the floor. HSTS with preload, so a browser will not fall back to plaintext.
At rest. AES-256 on databases, object storage and backups. Keys are held in a managed key service, rotated on a schedule, and never in application code.
Secrets. Credentials live in a secrets manager with per-service scoping and audited access. No secret is committed to a repository.
Passwords. Hashed with a memory-hard algorithm and a per-user salt. Nobody here can read your password, including us.
3
Access control
Access follows least privilege and is reviewed quarterly. Engineers do not hold standing production access; they request it, it is time-boxed, and every session is logged.
Multi-factor authentication. Required on every internal account and every administrative console.
Workspace isolation. Every query is scoped to a workspace at the data layer, not just in the interface.
Audit trail. Administrative actions, exports and permission changes are recorded with actor, time and source address.
Offboarding. Access is revoked the same day a person leaves, and verified against the list the following week.
4
How the app is built
Security work happens before release, not after an incident. Every change is peer reviewed. Dependencies are scanned continuously and patched on a severity clock — critical issues inside twenty-four hours, high inside seven days.
The application is written against the OWASP Top 10: parameterised queries throughout, output encoding on every render, strict content security policy, and anti-automation on authentication endpoints backed by Cloudflare Turnstile.
5
Testing and assurance
Independent penetration testing. Annual, by a third-party firm, with findings tracked to closure and a summary letter available to customers under NDA.
Continuous scanning. Static analysis on every commit, dependency and container scanning daily, external attack-surface monitoring.
Subprocessor assurance. Our hosting, payment and edge providers maintain SOC 2 Type II and ISO/IEC 27001 certification, reviewed by us annually.
Our own audit. A SOC 2 Type II readiness programme is underway. We will publish the report when it is issued and not before — we will not claim a certification we do not hold.
6
What Cloudflare actually does here
Cloudflare sits in front of the application as the first filter, so hostile traffic is dropped at the edge before it reaches anything that holds your data. It is a layer, not the whole answer.
WAF. Managed rulesets for the OWASP Top 10 plus rules we write ourselves, blocking injection and traversal attempts at the edge.
DDoS mitigation. Always-on absorption at network and application layer, no manual switch to flip during an attack.
Bot management and Turnstile. Credential stuffing and scripted signups are stopped before they touch the login endpoint. Turnstile does it without the tracking cookies a CAPTCHA usually drags along.
Rate limiting. Per-endpoint ceilings on authentication, export and messaging routes.
TLS termination and HSTS. Modern ciphers enforced at the edge, with plaintext fallback refused.
7
Monitoring, logging and analytics
You cannot respond to what you cannot see. Telemetry is split deliberately: security signals are kept and watched, product analytics are kept deliberately thin.
Security event logging. Authentication attempts, permission changes, exports and administrative actions, each with actor, timestamp and source address, retained twelve months.
Alerting. Automated alerts on failed-login spikes, impossible-travel sign-ins, privilege changes and unusual export volume, routed to an on-call engineer.
Infrastructure monitoring. Uptime, latency, error rate and resource saturation, with paging thresholds set below the point a customer would notice.
Application error tracking. Stack traces with personal data scrubbed before they leave the app.
Product analytics. First-party and aggregate only — which screens get used, which flows stall. No third-party advertising SDKs, no cross-site tracking, no session recording of your books.
Edge analytics. Cloudflare traffic and threat analytics, which show blocked attacks and request patterns without profiling individuals.
What we do not run: advertising pixels, data brokers, or any analytics vendor that would take your workspace content off our infrastructure.
8
Is Google an added layer?
Fair question, and the honest answer is yes for one specific thing and no for everything else.
Signing in with Google means Google performs the authentication, not us. You get their account protections — two-step verification, passkeys, hardware security keys, suspicious sign-in detection, and their own phishing defences — and we never hold a password that could be stolen from us. Their infrastructure is certified to ISO/IEC 27001, 27017, 27018 and SOC 2 Type II. That is a genuine additional layer at the front door.
It is not, however, protection for the data inside your workspace. Once you are signed in, everything after that point is our responsibility: encryption, isolation between workspaces, access control, backups and monitoring all sit with us. Google secures the door. We secure the building.
If you use email and password instead, enable two-factor authentication where offered and use a password manager. The front-door layer is only as strong as the account behind it.
9
If something goes wrong
We keep a written incident response plan with named owners, defined severity levels and a rehearsed escalation path. It is exercised at least once a year.
If a breach affects your data we will tell you without undue delay. Where the GDPR applies we notify the relevant supervisory authority within seventy-two hours of becoming aware, as Article 33 requires. In the United States we follow the breach-notification statute of every affected state — all fifty have one — and California's specific content and timing rules where its residents are involved.
You will get facts, not spin: what happened, what data was involved, what we have done, and what you should do. Even when the news is bad.
10
Resilience and continuity
Backups. Encrypted, automated, taken continuously with point-in-time recovery.
Restore testing. Restores are actually performed on a schedule, because an untested backup is a rumour.
Redundancy. Multi-zone deployment with automated failover.
Targets. Recovery point objective of one hour, recovery time objective of four hours.
11
Payments and messaging
Card data never touches our infrastructure. Checkout runs on Stripe, a PCI DSS Level 1 service provider, and we receive only a token and the status of the charge. That keeps our own PCI scope to the narrowest possible form.
WhatsApp messages are protected in transit by the platform's own encryption between the sender and Meta's infrastructure. Content that lands in your workspace is then stored under our encryption at rest. Business messaging is not end-to-end encrypted in the consumer sense, and we would rather say so plainly than let you assume otherwise.
12
Reporting a vulnerability
If you have found something, tell us at [email protected]. We acknowledge inside one business day, keep you updated while we work, and credit you publicly if you want it.
Good-faith research is welcome and we will not pursue legal action against researchers who act responsibly: no data exfiltration beyond what proves the issue, no service degradation, no access to another customer's workspace, and a reasonable window to fix before disclosure.