What we do, and what we don't have.
Written for the person in your organisation whose job is to find the gap. The absences are listed first, because you would find them anyway and a page that hides them is not worth reading.
What we do not have
No certification, no availability promise, and one person operating the whole thing. If any of these is disqualifying for you, it is better established now than after a pilot.
- 01We hold no SOC 2, no ISO 27001, and no equivalent third-party certification.
- 02We have not commissioned an independent penetration test.
- 03We commit to no availability target. We do not measure it, so we will not quote a figure for it.
- 04We commit to no recovery point or recovery time target, and give no warranty as to the outcome of any restore.
- 05Sign-in is single-factor. Where you use Google Workspace, your own sign-in policy applies on top of ours.
- 06SiteSync is operated by one person. There is no segregation of duties, and that is a key-person concentration you should price in.
- 07Deleting a record removes it from the application. Backups and the archived audit trail retain it for their retention period, so we do not claim erasure is immediate or total.
What we can prove instead
A certification attests that a process existed on the day it was audited. For the control you actually care about — that another company cannot read your project — we can demonstrate it directly, and repeatedly.
- 01An automated test suite that verifies company isolation, run on every change.
- 02A standalone probe that empirically confirms one company’s credentials cannot read another company’s data.
- 03The result of either, on request, before you sign anything.
The measures themselves
Technical and organisational measures in force today. The same list forms a schedule to the agreement, so what you read here is what you would be signing.
- 01Row-level security on all application tables; privileged database routines are individually access-gated.
- 02Company isolation in two independent layers, failing closed — a request that cannot prove which company it belongs to is refused, not defaulted.
- 03Role- and designation-based access control enforced at the database layer, not by a filter in the app.
- 04An append-only, SHA-256 hash-chained audit log. Altering a past entry breaks the chain and the break is detectable.
- 05No passwords stored or transmitted — Google sign-in or an SMS one-time code only.
- 06One-hour access tokens, held in memory and never written to browser storage.
- 07Hosted on Supabase, which encrypts data at rest; TLS in transit, platform-enforced.
- 08Private storage buckets served only through short-lived signed URLs.
- 09Per-IP rate limiting on sign-in, with unknown, pending and disabled accounts collapsed into one identical response.
- 10Exports are neutralised against spreadsheet formula injection, and the export itself is audit-logged.
- 11Daily backups via our hosting provider, with point-in-time recovery.
- 12All changes version-controlled and deployed through an automated pipeline; database schema changes versioned and applied separately.
Where your data sits
Project data is held in a managed Postgres database and private object storage. Error reports are sent to a monitoring service and carry only an account identifier, role and company — never site photographs, never project contents. We hold no identity documents: no Aadhaar, no PAN, no passport, no ID proof.
Still the fastest way to find out: show us a project.
Half an hour, your own drawings, and an honest answer about whether it fits.