Why we removed security claims we couldn't prove
In October 2026 we ran a security and privacy review of Organize and, as part of it, read our own website the way a sceptical buyer would: one sentence at a time, asking "could we prove this?" A fair number of sentences failed that test. We removed or rewrote them. This is what changed, and why we think a shorter, plainer security page is worth more than a longer, grander one.
What the review found
The code was in better shape than the copy. Studio isolation, role-based financial access, hashed passwords, signed sessions and the application activity log all did what they were supposed to do. The problem was the security page itself, which had been written in the register most software security pages are written in: the language of a large, certified, heavily audited company.
Read against the evidence, several of its claims fell into one of three groups.
| The claim said | The problem | What the page says now |
|---|---|---|
| Hosted on infrastructure with ISO 27001 and SOC 2 Type II certifications | True of our providers, but placed where a reader would take it as Organize's own posture | Our providers hold their own certifications; Organize does not currently claim any |
| Encryption keys managed through a dedicated key-management service and rotated on a schedule | Encryption at rest is a feature of the providers' platforms. Organize runs no key-management service | Stored data is encrypted at rest by the providers; Organize does not operate its own key management |
| Periodic penetration tests, remediated within defined timeframes | No independent test had been commissioned | We have not yet commissioned one, and will say so until we have |
| Backup integrity tested through restoration exercises; geographically separated backups | Backups and point-in-time recovery come from the database provider; no documented restore drill existed | Backups and point-in-time recovery are provided by the database provider |
| Multi-factor authentication required for customer accounts where enforceable | Organize does not offer customer MFA | Organize does not currently offer multi-factor authentication for customer accounts |
| Intrusion detection, DDoS mitigation at the network perimeter, firewalls and ACLs | Any such protection is the hosting provider's, not something Organize operates or monitors | Removed |
| Annual security training, background screening, a written incident-response plan, vendor assessments, a sub-processor register available on request | None of these existed as documented programmes for a team of our size | Removed, or replaced with what we actually do |
The privacy policy had the same pattern in a smaller way. It described analytics and device-level tracking we do not run, listed data fields we do not collect, and gave retention periods that nothing in the product enforced and that contradicted our own Terms. It also failed to mention something we do: when a studio signs up or a user signs in, the Organize team is notified. That is now stated plainly.
Why the language drifts
None of this was written to deceive. It is simply how security pages get written. You look at what established companies publish, you assume that is the expected shape, and you fill it in with the controls you intend to have. The sentences describe an aspiration, and over time the gap between aspiration and reality stops being visible from the inside.
The trouble is that the people reading it are often the least impressed by it. A studio's IT lead, or the finance person who has to sign a vendor form, has seen the template before. What they want to know is specific: who can see our rates, can another customer reach our records, can you read our data, and what happens when we leave. Grand language gets in the way of those answers.
The rule we now use
Security language should describe reality, not aspiration. Every sentence on our security and privacy pages has to point at something in the code, the configuration or a provider's published terms. If it cannot, it goes.
In practice that gave us a shorter page with four properties we like better than the old one:
- It attributes controls correctly. When encryption at rest or backups come from Vercel or Neon, it says so, rather than implying Organize built them.
- It answers the operator question. The old page implied privileged access was tightly logged and audited. The new one says what is true: the team that runs the service can technically read stored data, uses that access only to operate, secure and support the service, and the application's activity log does not cover it.
- It states absences as plainly as presences. No customer MFA, no certifications, no penetration test yet. Those are sentences a buyer can plan around; vague language is not.
- It is checkable. "Sessions expire after seven days" and "TLS 1.1 is refused" are claims you can test from your own laptop.
What we did not remove
It would be easy to read this as "Organize has no security". That is not the case, and the review confirmed the parts that matter most to a studio:
- every record belongs to one studio and every request is scoped to it on the server;
- invoices, challans, quotations, payments and rates are limited to financial roles, and that limit is enforced in the API and the PDFs, not just the screens;
- passwords are stored as bcrypt hashes; sessions are signed and kept in HTTP-only, secure cookies;
- connections use HTTPS with HSTS, and old TLS versions are refused;
- the application logs bookings, conflict overrides, challans, invoices, payments and sign-ins with the acting user and time.
Those sentences survived because each one points at something we can show. That is the whole standard.
What happens next
Some of the removed claims describe things worth doing: an independent penetration test, customer MFA, a documented restore drill, a formal subprocessor register. When any of them is done, it will go back on the page as a fact rather than a promise. Until then, the page stays short.
If you are evaluating Organize, the plain-language version of all this is on the Trust & data access page, and the formal version on the Security and Privacy pages. If you find a sentence on any of them that we could not prove, we would genuinely like to hear about it: admin@organizeapp.org.
Judge the product, not the brochure
Set up your studio in a free trial and check the separation and the role controls for yourself.
Start Free