Security

Our security model is that we never have your data.

There is no OrgTool cloud, no tenant, no backup of your org on our side. The most sensitive dataset in your company — who reports to whom, who earns what, who is on a list — stays on the machine of the person planning with it. This page is short because the architecture is.

WHAT WE CANNOT DO: read your org, reset a lost encryption password, recover a deleted .orgpack, or hand your data to anyone — including under subpoena. We do not have it.
Local execution
A single self-contained HTML file (~3.5 MB). All computation runs in-process, in your browser. Verify with your own network monitor — the request log is empty for the default, offline path.
Your files, your storage
.orgpack is a documented ZIP of JSON, plus IndexedDB for in-progress state. Put it in your DMS, your encrypted drive, your litigation-hold folder.
Encryption at rest, by default
Every project encrypts its .orgpack unless you turn it off: AES-256-GCM with a File Encryption Key wrapped per member via AES-KW, derived from your passphrase with PBKDF2-SHA256 at 100,000 iterations. We never see the passphrase or the file — which also means we cannot recover either.
Optional field scoping
A separate admin passphrase can encrypt a second copy of cost/demographics/notes so editors and viewers never see it — real only when that second passphrase exists and stays separate from the share passphrase. No admin passphrase, no scoping: we say so plainly rather than implying a guarantee that isn’t there.
Deterministic audit trail
Every restructuring export carries a SHA-256 of its inputs, and re-exporting the same report reproduces a byte-identical archive. Integrity is verifiable by anyone, forever, without us.
Countersigned packs
On Enterprise, we sign that input hash so a third party can confirm the pack came from a licensed installation at a stated time. Detached, so the archive stays byte-identical. Verifiable against the key below, offline, without an account.
AI features are opt-in
Role analysis calls a model only when you click, only with fields you approve, using your own Anthropic API key. Off by default; revocable any time.
The two exceptions that make a network call, always by your own action: signing in with a magic link, and running AI analysis with your own key. Neither is required.

What "cryptographic" means here, precisely.

A member's key material unlocks the primary payload of an encrypted .orgpack — that's the shared-passphrase model, and every admin, editor, and viewer with the passphrase can open the file. The optional cost/demographics/notes sidecar is a separate encrypted payload, wrapped under a second, distinct admin passphrase that editors and viewers are never given. That second secret is what makes field scoping a real cryptographic boundary rather than a UI-layer filter someone could bypass by reading the file directly.

Subtree scoping — handing a manager a copy limited to their part of the org — is not cryptographic. The member's key still unlocks the whole org tree; the app filters what it displays after decrypting everything. Treat it as a UI convenience, not data minimization: someone who later obtains broader key material for the same file can see the whole org.

What we don't claim.

  • No end-to-end encryption of everything. Only the primary payload and (when configured) the sidecar are encrypted; the plaintext file header (member emails, roles) is tamper-evident, not itself secret.
  • No FEK rotation on revoke, today. Removing a member doesn't re-key the file — re-encrypt with a new passphrase to actually cut off a former member's access.
  • No SOC 2, FIPS validation, or other compliance certification. None exists for this product at this stage, and we won't claim one that isn't real.
  • No on-premise deployment or SSO/SAML integration. Not available today.

Verification key.

One Ed25519 key signs both our licences and the countersignature on an audit pack. Its public half is below and is compiled into the verifier that ships inside the app, so a licence cannot be forged even by someone holding the whole bundle. Publishing it here is what lets a regulator, an auditor or opposing counsel check a countersigned pack without an account with us.

The private half has never been in the repository or on a build machine.

Ed25519 public key — hex
9fb7d73c8a796f459670077ffffe73f37646d99341e3799a748b737c4d17e004
SHA-256 fingerprint
4098 582c 5873 da6f 9e6d e5ac fba0 be5b 13ea 46ac 375d 4eec c469 5324 f180 2c5d

Check the fingerprint against this page over HTTPS before trusting a key you were sent by any other route.

Verifying a countersigned pack

An audit pack ships with a sibling .sig.json. Two ways to check it, and neither requires our cooperation beyond this page.

Offline

Ed25519-verify the file’s signature over the UTF-8 JSON of its payload, byte for byte as written, using the key above. Then confirm the inputHash in that payload matches the one inside the pack’s report.json.

Online

POST the payload and signature to api.orgtool.io/api/audit/verify. No authentication.

WHAT A COUNTERSIGNATURE PROVES: that this exact input hash was submitted by this licence at this time. It does NOT attest that the analysis is correct, that the roster was accurate, or that the decision was lawful. Those remain the customer’s.

If we ever rotate this key, both the old and new keys stay listed here with their validity dates — a pack signed under a retired key must remain verifiable for as long as anyone might need to rely on it.

Full technical detail lives in our internal engineering record "ADR-26-04, orgpack access scoping" — ask your OrgTool contact for a copy. Questions your CISO will ask anyway: security@orgtool.io.
FAQ

Frequently asked questions

Answers restate claims verified file-by-file against the current build — see claims/ in the site repo. Last verified July 2026.

Where is my org data stored?
In your browser's IndexedDB and in .orgpack files — a documented ZIP of JSON — saved to a folder you choose. There is no OrgTool cloud copy: our worker handles sign-in and licensing only, never org content.
What encryption protects an .orgpack?
AES-256-GCM by default, with a File Encryption Key wrapped per member via AES-KW, derived from your passphrase with PBKDF2-SHA256 at 100,000 iterations. We never see the passphrase or the file.
Can OrgTool recover a lost passphrase or a deleted file?
No. That is the honest cost of the architecture: we cannot read your org, reset a passphrase, recover a deleted .orgpack, or hand your data to anyone — including under subpoena — because we do not have it.
What network calls does the app ever make?
Two, always by your own action and never silently: signing in with a magic link, and AI analysis with your own Anthropic API key. Licence checks are a signed key verified locally, offline. Verify with your own network monitor — the request log for the default path is empty.
Is field-level access control cryptographic?
Only when you configure a separate admin passphrase — cost, demographics, and notes then live in a second encrypted payload that editors and viewers cannot open. Subtree scoping, by contrast, is a display-level convenience, not cryptography. We say so plainly rather than implying a guarantee that isn't there.
Are you SOC 2 or ISO 27001 certified?
No — and we won't claim a certification that doesn't exist. What we offer instead is an architecture with no vendor-side data to certify: local execution, published verification keys, and deterministic outputs you can check yourself. Questions your CISO will ask anyway: security@orgtool.io.
Do the AI features change any of this?
AI analysis is opt-in per run, sends only the fields you approve, and uses your own Anthropic API key — off by default, revocable at any time. Nothing about the default, offline path changes.
In one paragraph

OrgTool's security model is that we never have your data: the app is a single self-contained file that computes everything locally, org data lives in your browser and in .orgpack files you keep, and the only network calls — sign-in and opt-in AI analysis with your own key — happen by your own action. Files encrypt at rest with AES-256-GCM (PBKDF2-SHA256, 100,000 iterations), a separate admin passphrase can cryptographically scope cost and demographic fields, restructuring exports are deterministic and SHA-256-stamped, and our Ed25519 verification key is public so an audit pack can be verified offline, forever, without us. No SOC 2 is claimed and no on-prem or SSO exists today — this page says exactly what is and isn't true.

Copy-paste friendly — for the email to whoever decides.