Tenant isolation, controlled access, and honest launch claims.
Crossruled is currently appropriate for controlled pilots. Enterprise claims such as SOC 2, SAML SSO, SCIM, uptime SLA, and formal penetration testing remain roadmap items until independently completed.
Updated 30 September 2026
Isolation is tested on every push. The Firestore rules suite runs on every push to the production branch, and one of its tests is a signed-in user of another company being refused your data.
Security reviewed. An AI-assisted, read-only security audit of the code and rules ran on 29 September 2026, with five re-verification passes through 30 September. Its two high findings were closed before the 30 September release.
No certification is claimed. Crossruled holds no SOC 2 report and no ISO 27001 certificate. Both are roadmap items and this page says so until they are done.
Data is stored in the United States. Firestore multi-region nam5, served by Vercel.
Isolation
Every workspace is its own tenant under its own tenant id, and every document lives under that path. Firestore rules check the signed-in user's profile, its tenant and its role, on every read and write. A profile that is removed or set inactive loses access at once; a stale sign-in token grants nothing on its own. The rules suite that proves this runs against a Firestore emulator on every push to the production branch, and the same suite is run by hand before each release.
Security review
A read-only security audit of the code, rules and live headers ran on 29 September 2026, carried out as an AI-assisted review separate from the build (not a third-party penetration test or a certification), followed by five re-verification passes through 30 September. It found no critical issue and two high ones: a signup path that could let an invitee claim a tenant id before its rightful owner, and payroll averages reaching delivery and viewer roles through saved proposals. Both were closed before the 30 September release and re-tested with the exploit probes that found them. Every remaining item is either closed or recorded as accepted with its reason, and the records are available to your security team on request.
Who sees what
Benchmarks are finance's. People are HR's. Money is for cost roles only. Per-person monthly cost, role salary bands, proposal prices and the audit log are readable only by owner, admin, finance and HR, and the rule is enforced in the database, not only in the screen. A saved proposal carries no price at all in the part delivery and viewer can read; the money lives in a separate record those roles cannot open.
| Role | Reads | Changes |
|---|---|---|
| Owner | Everything: people, allocations, projects, proposals with prices, per-person monthly cost, role salary bands, the audit log. | Everything, including every account and role in the workspace. |
| Admin | The same as owner. | Everything except owner and admin accounts, which only an owner can change or grant. |
| Finance | The same as owner. | Role salary bands, per-person monthly cost, proposals and their prices, the default margin. |
| HR | The same as owner. | The people master: names, roles, departments, skills, capacity, status, and per-person monthly cost. |
| Delivery | People, allocations, load, projects and bill rates. Proposals without any money figure. No monthly cost, no salary band, no audit log. | Projects and allocations. |
| Viewer | The same as delivery. | Nothing. |
Bill rates are visible to every role. An allocation's bill rate is revenue, and delivery needs it to staff work. Crossruled never derives a bill rate from a salary. But if your firm sets bill rates as a fixed multiple of salary, a colleague who knows the multiple can work back from a bill rate to a person's cost. If that matters to you, set bill rates from the client contract, not from payroll.
Audit log
Every change to people, roles, projects, allocations, proposals and costs writes an entry: the signed-in user's email, the action, the collection and record, the time, and for most records the values before and after. Per-person cost values are never written into it. Entries are written by the app in the browser as each change saves, so a modified client could skip its own entry; the entry itself cannot be edited or deleted by anyone in the workspace, and only owner, admin, finance and HR can read it. A server-written audit trail is a roadmap item.
Access and trial
Access is by a one-use code bound to the email it was issued for; nobody else can use it, and no client can read or list codes. A new workspace runs a 14-day trial enforced in the rules; after it ends the workspace shows an evaluation-ended screen. If nobody has asked us to keep or delete it, we email the owner and delete it 90 days after the evaluation ended, with at least 14 days' notice. Passwords are set only by their owner through a reset email; no admin, and no one at Crossruled, sets another person's password.
Where the data lives
Workspace data is stored in Google Cloud Firestore, multi-region nam5, in the United States, and the app is served by Vercel. There is no India or EU region today. What that means for the DPDP Act and the GDPR is set out on the privacy page and in the DPA.
Demo data only during early access. Do not upload real employee data. Use demo data only until we tell you the hosting plan is ready for it. Vercel's data-processing terms apply to its Pro and Enterprise plans, not to the hosting plan we use during early access. We also keep backup copies of the database, made to test that restores work, on the operator's encrypted computer in India, and delete each one within 30 days.
Exit
Export your data, any day. Settings has a one-click JSON export of people, roles, projects, allocations and proposals (per-person cost included for owner, admin, finance and HR; the audit log is not included) and the reports download as CSV, so a pilot never becomes lock-in. To close a workspace, export first and write to us; we delete within 30 days of your request.
Incidents and contact
Report a suspected exposure, a blocked sign-in or an outage to codingrajan@gmail.com. Suspected cross-tenant exposure is severity 1 and is handled first: we contain access, work out which tenant, collection and users are affected, and tell the workspace owner what we found and what we changed. The steps are on the incident page.
Status
No third-party status monitoring yet. Build and dependency health is exposed at the endpoints below.