Company · Security
Your plant’s P&ID model, and who can reach it.
What we do, what we don’t, and where we’re weaker than you’d hope.
Send us your questionnaire| Control | Where we stand |
|---|---|
| Tenant isolation | Enforced in PostgreSQL, not in application code |
| Access control | Forty permissions, checked per endpoint |
| Two-factor authentication | Every plan; an organisation can require it |
| Single sign-on | OpenID Connect, every plan, secret encrypted |
| Audit trail | Hash-chained and append-only |
| Encryption in transit | Yes — no version pinned, so none quoted |
| Encryption at rest | No, except two secret types. See below |
| Backups | Daily, 14 days, on the same host, unencrypted |
| AI provider | Yours — bring a key or host the model yourself |
| Certifications | None held |
Draft — not yet reviewed, and not a certificationEverything stated below is true of the software as it is built, and each claim was checked against the source before it was written. What is missing is the half no codebase can answer: we hold no security certification, have commissioned no penetration test, and publish no sub-processor list yet. Those are marked as still to be supplied at the foot of the page rather than filled in with plausible wording. Send us your questionnaire and we will answer it in writing.
One tenant cannot read another
Separation is enforced by the database, not by application code that could forget a WHERE clause.
- Every table holding your project data carries PostgreSQL row-level security, enabled and forced, with policies on all four operations. Forced means the table owner is subject to them too.
- Each policy tests your organisation against a session value the server sets from your token at the start of every request, on the same connection that runs the query. A query that arrives without one returns nothing rather than everything.
- A test connects as the unprivileged application role and fails the build if any table is left unprotected, if one is enabled without being forced, or if a policy set is incomplete. Thirteen platform tables — identity and cross-organisation records — sit outside the policy set on a written list, so a fourteenth cannot be added quietly.
Who can do what
Roles carry explicit permissions, and permissions are checked at the endpoint.
- Forty named permissions, grouped by what they act on, are attached to company, project and platform roles. Each protected endpoint declares the one permission it needs, and an authorisation handler checks it on the way in.
- The seven platform-administration permissions are mapped to no company role at all — not even Owner — so only a platform administrator holds them.
- Two-factor authentication uses a time-based one-time code and ten single-use recovery codes, which are stored only as hashes. It is available on every plan, at no extra tier, and an organisation can make it mandatory, after which sign-in is refused until each member has enrolled.
- Single sign-on through OpenID Connect is available on every plan. The client secret you give us is encrypted before it is stored and can never be read back out of the API — it is write-only.
- Passwords must be at least twelve characters with mixed case, a digit and a symbol, and are stored only as a bcrypt hash. Five failed sign-ins lock an account for fifteen minutes; both numbers are adjustable per organisation.
- Refresh tokens are single-use. Each one is stored as a hash, is exchanged for a new token, and if an already-used token is ever presented again the whole family is revoked immediately — so a stolen token buys one use and then locks the thief and the owner out together.
What happened, and proof it was not altered
The audit log is append-only and chained, so a deleted or edited entry shows.
- Each audit entry is hashed together with the hash of the one before it, over its time, actor, organisation and action. Removing or editing an entry breaks the chain from that point on, which a verification pass detects.
- The log table has policies for reading and inserting only. It has no update or delete policy, so under row-level security those commands are refused outright rather than merely discouraged.
- Logs are partitioned by month, with partitions created three months ahead, so retention and archival act on whole months rather than on row deletions the chain would notice.
- Actions are logged where the application is instrumented to log them — this is deliberate coverage of the operations that matter, not a database-wide capture of every write. You can read your own organisation’s log; running the chain verification is a platform-administrator action today, not a self-service one.
Encryption — including where we fall short
This is the section most security pages overstate. Here is the real position, including the part that will not suit every buyer.
- Traffic between your browser and the application is served over HTTPS, with certificates obtained and renewed automatically. We pin no minimum TLS version at the edge, so we do not quote one.
- The application reaches its database over TLS only. Unencrypted connections are refused by the server, the client verifies the certificate against the stack’s own authority, and the minimum protocol version is TLS 1.2.
- The database itself is not encrypted at rest. There is no transparent database encryption and no encrypted volume in the deployment we ship; the data directory is an ordinary disk volume. Where full-disk encryption is required, it is applied by whoever operates the host, and we will tell you what a given deployment does.
- Backups are not encrypted where they are written. They are written to the host that runs the database and are encrypted only if they are copied somewhere that encrypts them.
- Two kinds of secret are encrypted individually before they are stored, and only two: the client secret for your single sign-on connection, and any model-provider key you bring yourself. Neither can be read back through the API.
Your work, and getting it out
What can leave, in what format, and what has no route out today.
- Drawings export as DXF, SVG, PDF and PNG, single sheet or multi-sheet.
- Bills of quantities export as Excel and PDF.
- The version register and the tag register export as CSV or JSON, built to RFC 4180 and guarded against spreadsheet formula injection — so an export is safe to open as well as complete.
- Transmittal packages build and download as a zip with a cover sheet, and your own audit log exports as well.
- There is no single button that downloads an entire account in one archive, and closing an account is an archive we perform on request rather than a self-service erasure. If a full export or a hard deletion is a requirement for you, say so before you sign anything — we would rather scope it than surprise you.
Version history on a drawing: every saved and auto-saved version in order, each one restorable, with "Export register" beside them — the CSV or JSON the claim above names. This is the whole of what leaves: there is no single button that downloads an account.
Where your drawings go when AI is involved
Most of the product never touches a language model. Bills of quantities, simulations, hydraulics and the safety calculations are deterministic code.
- Language-model settings can be held per organisation — the provider, endpoint, model and key resolved for each request from your own profile. Per-organisation routing is switched on for you on request; until then requests use the platform’s provider chain.
- You can bring your own provider key, or point the product at a model you host yourself — any OpenAI-compatible endpoint, including one inside your own network, in which case prompts never leave it.
- A profile can be marked so that the platform must never fall back to its own model account — not on error, not on a retry. Set it and a failure is a failure, not a quiet redirection of your prompt.
- Keys you supply are encrypted before storage and cannot be read back through the API.
- What your model provider does with a prompt is governed by your contract with them, not by us. We do not make a claim about their training or retention on their behalf — see the list below.
Backups and recovery
What is backed up, how often, for how long — and what is not.
- The database is dumped in full on a schedule, compressed, with a default of once a day and fourteen days of retention. Old backups are pruned only after a new one has succeeded, so a failing job cannot delete the last good copy.
- The backup job connects to the database with full certificate verification, like every other client.
- Backups are written to the machine that runs the database. The stack we ship copies them nowhere else, does not encrypt them, and does not rehearse a restore on a schedule; the restore procedure is written down but is a manual operation. Files you uploaded — imported PDFs and DXFs — live outside the database dump.
Not yet answered
A security page that guessed at these would be worse than one that leaves them blank. Each is a real question, and each is waiting on a human answer rather than a line of code. Ask and we will tell you where we have got to.
Certifications — OWNER TO SUPPLYWhether ISO 27001, SOC 2 or Cyber Essentials is held, and the certificate and scope for each. None is claimed on this page because none is held today.
Penetration testing — OWNER TO SUPPLYWho tests the application, how often, and what a prospective customer may see of the report. No test report exists in the codebase.
Sub-processors — OWNER TO SUPPLYThe current list of third parties that process customer data — hosting, e-mail, payments, model providers — each with its purpose, its location and a last-reviewed date.
Model-provider terms — OWNER TO SUPPLYWhat each language-model provider we can route to commits to on retention and on training, quoted from the agreement with them. The product lets you avoid the question entirely by self-hosting or bringing your own key.
Data protection contact — OWNER TO SUPPLYThe controller identity, a named privacy contact or data protection officer, and the route for a data-subject request.
Retention and deletion commitments — OWNER TO SUPPLYHow long data is kept after an account closes, what a deletion request removes, and the timescale for it.
Availability commitment — OWNER TO SUPPLYAny uptime target, maintenance window or service credit. No figure is claimed here.
Incident notification — OWNER TO SUPPLYThe timescale and route for telling you about a security incident affecting your data.
Insurance — OWNER TO SUPPLYCyber and professional-indemnity cover, with limits.
Ask us the hard one
If something above rules us out for your organisation, we would rather know now than at contract stage. Send the questionnaire, or the single question that matters.