Stonen
Security, access and continuity
Who sees what, and what happens if something goes wrong
This page describes the controls that exist today and what each one means for your company's operation. It also states what does not exist yet — because a list of controls without the gaps is for selling, not for deciding.
No security certification has been obtained, and no external audit has been carried out. What follows is the verified behaviour of the system.
One company never sees another
Every read and every write in Stonen is scoped to the organisation making the request. A record belonging to another company is not filtered out of the screen: it is refused by the API, with its own error.
For your business this means your customer book, your inventory, your prices and your conversations do not show up for another company using the same product — not through a typo, not through a link shared by mistake.
This isolation applies to every role, including the account owner. There is no role that sees everything.
Each person sees what their role allows
Access is decided by 35 permissions, combined into four roles. The rule that cuts across all of them is the one the product owner fixed: broad reading, restricted commercial action.
The full table — each permission against each role — is generated from the same code the API runs on every request, not written by hand. If the table is wrong, the code is wrong with it.
| Role | What they do | What that prevents |
|---|---|---|
| RoleOwner | What they dosees the whole operation, administers the team and the settings | What that preventsthe company depending on an outsider to change its own account |
| RoleManager | What they dodistributes work, follows up and intervenes; acts outside their own book by exception, with a reason | What that preventsa manager being blocked — and a manager touching someone else's book without a trace |
| RoleSalesperson | What they doworks their own book; does not act on anyone else's | What that preventsone salesperson's book being reached by another |
| RoleTechnology | What they dohandles integrations and data quality. Holds 7 of the 35 permissions: sees physical inventory, but not the customer book, prices, opportunities or customers | What that preventswhoever runs the technical side seeing the commercial operation |
Some actions require a declared reason to be accepted, and the refusal comes from the server, not the screen. Hiding a button is not access control.
What was done stays recorded
Commercial decisions are stored as events, not as a field the next change overwrites. The original recommendation, the person's decision, the approach, the customer's reply and the outcome stay linked to one another.
For your business this answers questions like *"why was this material offered to this customer?"*, *"who changed the owner of this opportunity?"* and *"what did the customer reply, and when?"* — months later, without depending on anyone's memory.
This is a history of what happened to the commercial operation. It is not a security audit log in the formal sense: Stonen keeps no record of its own of sign-in attempts, because authentication is handled by a separate identity system.
Passwords are not kept here
Stonen stores no passwords. A separate identity system authenticates, and the product only receives confirmation of who the person is and what they are entitled to.
In practice: cutting someone's access does not require touching Stonen, and a problem in Stonen does not expose anyone's credentials.
This is also a dependency: with the identity system unavailable, nobody signs in. The product was built to refuse to start without it rather than open an alternative door.
Backup and recovery
There are four layers of copies, on different schedules, because each protects against a different failure: application error, loss of the machine, loss of the provider account, and total loss.
Restoration has been rehearsed, not merely documented: in a dated test the database was answering again in about 15 seconds.
| Layer | Protects against | Does not protect against |
|---|---|---|
| LayerDaily copy on the server itself | Protects againstapplication error, accidental deletion | Does not protect againstloss of the server |
| LayerDaily encrypted copy elsewhere | Protects againstloss of the server | Does not protect againstloss of the provider account |
| LayerTwice-daily encrypted copy outside the provider | Protects againstloss of the server and the account | Does not protect againstdays when the origin machine is never switched on |
| LayerWeekly copy of the whole machine | Protects againsttotal loss | Does not protect againstup to 7 days of lag |
What does not exist yet: point-in-time recovery. The realistic worst case is the window between two copies — about 24 hours. Closing that is an open cost decision, and it is recorded as one.
What does not exist yet
This list is here because deciding with it is different from deciding without it.
- There is no monitor outside the machine. A watchdog notices "the application went down" and raises an alert. It does not notice "the whole server died", because it lives on the server.
- There is no contracted service level (SLA). Availability measurement began in September 2026; without history there is no basis for promising a number in a contract, and promising without a basis would be worse than not promising.
- There is no security certification or external audit.
- Point-in-time recovery does not exist — see the previous section.
- A single company in production. Isolation between organisations is tested, but behaviour under several simultaneous companies has not been measured at real scale.
Each of these has an owner and an identified cost in the product's internal tracking. None is forgotten; some are waiting on an investment decision.
Page last updated September 22, 2026.