Trust

Who holds what

Your organisation is the controller of the data you put into Bizuncto. We are the processor: we hold it, keep it separate, and act on your instructions. We do not sell it, we do not use it to train anything, and we do not pool it with other customers' data to produce benchmarks or analytics.

That last point is a design decision rather than a policy we could quietly reverse. Everything a buyer authors — ratings, incident history, quotes received — is scoped to the relationship it belongs to. There is no cross-customer view to switch on.

Keeping organisations apart

Every query the application makes is confined to the organisation making it, by a filter applied in one place rather than written out by each developer. A second check refuses any write that would attach a row to another organisation's parent record. The separation is structural: it holds because it cannot be forgotten, not because everybody remembered.

What another organisation can see

When you send work to a supplier, they see that request and nothing else. Not your other requests, not the same supplier's work for anybody else, and not the fields you have marked as internal.

Within their organisation, only the people they have named for that kind of work can see it — they maintain that list themselves, and you never edit their staff list any more than they edit yours. A request also becomes visible to them only once your workflow says it is their turn.

Notifications are the one thing that reaches them outside that. An email about a change names the person who made it and carries their work address, so a supplier can reply to somebody rather than to nobody — which means that address reaches them, as theirs reaches you.

Suppliers are never charged, and a supplier can take part in several customers' workflows with one login without any of those customers seeing the others.

Signing in

Sign-in is handled by Microsoft Entra External ID. Bizuncto stores no passwords, no password reset tokens and no lockout state — there is no password of ours to lose. By default you sign in with a one-time passcode sent to your email address.

That is a single factor: possession of your mailbox. We would rather say so here than have you find out from a questionnaire. Passwordless suits the small suppliers who take part in your workflows and have no IT department to call, and it is bought at a price — a one-time passcode cannot also serve as a second factor, and the alternatives that would let us add one all begin by introducing the passwords we deliberately do not hold.

If your own organisation requires more, the answer is to bring your own: sign-in can be configured, per organisation, to federate your people to your Entra ID, Okta, Ping or Google Workspace — so your multi-factor policy applies to them and we never see a credential at all. Ask us.

Who inside your organisation can do what

Administrative permissions are granted to named people, for a named area of work, and nothing is implied by anything else — being allowed to change a workflow does not make somebody able to change who has access to it. Publishing a change to a live workflow is a separate permission again, and by default the person who drafted a change cannot be the one who publishes it.

That last rule can be stood down by an organisation that cannot staff it — a company with a single administrator would otherwise be unable to publish anything at all. Doing so is itself recorded, permanently, with the name of the administrator who did it, the date, and their reason. It is never something an organisation has to buy: it is in every plan at every price, and what follows shows whether it is on.

Every one of those checks is enforced by the application itself rather than by the page that offers the button.

Keeping and deleting

Your data is yours. If you leave, you can take an export of everything your organisation holds, and have it deleted. Deletion means deletion — not a flag that hides it.

Nothing expires while you are a customer. We do not delete your work after a period, archive it out of reach, or make you buy its history back. A request raised five years ago reads the same as one raised this morning, which is the point of keeping it.

Both are self-service, and neither needs us. An administrator of your organisation does them from Your data: one button produces a zip of everything you own, and another asks for the organisation to be destroyed. We are not in the middle, so there is nobody to persuade and no ticket to chase.

Deletion waits 30 days before anything happens. That is long enough to undo a request made in anger or by mistake, and short enough to be a real answer to "when will it be gone". Until then Your data shows that it was asked for, by whom, and when it will run, with a button to call it off — so any of your administrators can stop it, not only the one who started it.

When it runs it destroys everything your organisation owns: every area and its design, every request, every attached file, your people, and your own audit record with them. The audit log refuses deletion everywhere else in the product, and this is the one place it has to go — it carries names in what it says, so keeping it would mean keeping exactly what you asked us to remove.

Two things are deliberately kept. Where a request involved another organisation, their side of that exchange remains theirs, so the record does not disappear from underneath them; your identifiable content in it is removed. And a person's name stays on what they did, because a record that cannot say who approved something is not a record — where somebody asks to be erased, their personal details are overwritten and the trail they left stays readable.

That second one is worth being exact about, because "overwritten" is a word people have been let down by. Erasing somebody removes their email address, their name, their job title and the link to their sign-in account — the last of those being the only thing that could have led back to them. What is left is a meaningless identifier and some timestamps, holding a sequence of actions that can no longer be attributed to a person by us or by anybody else. It is not a pseudonym with the key kept somewhere: a key we still held would still be your personal data, and would still be your right to ask about.

What your own organisation must keep is a separate question from what we keep, and it stays yours. Nothing here shortens a retention period your auditor, your customer or the law imposes on you — if a record has to exist for seven years, deleting your organisation is not the way to find that out. Take the export first; it is the whole of what you own, in files you can read without us.

How long backups are kept is the honest qualifier on the paragraph above, because a deleted record is gone from the application immediately and out of the backups some time later. The period has been decided — fourteen days, which puts a deletion request 30 days from leaving the application and 44 from leaving the backups — but there is no deployment yet, so that is a decision rather than a setting anybody has read. It will be stated here as a fact when it is one.

Two things that will not change when it is. Records are never removed from a backup — nobody can do that — so a deleted record leaves when the copy holding it expires. And backups are restored to recover from failure, never to answer a question about one organisation's data; a restore that brought deleted records back would be followed by deleting them again.

Where it runs

Bizuncto is not yet in service. The infrastructure below exists and has been checked, and no customer is on it, so nothing of yours is held anywhere yet.

Bizuncto runs on Microsoft Azure in the United Kingdom — UK South, with backups replicated to a second UK region so that losing one does not lose the backups. If that ever could not be done inside the UK it will not be done at all: where keeping your data in the country and recovering faster from a regional failure conflict, the country wins. Backups are kept for fourteen days, and the database is encrypted at rest. Connections are refused below TLS 1.2, and the database has no password login of any kind — the application reaches it as a managed identity that nobody can copy out.

Sub-processors

Every company that will be able to reach your data is listed here. That is one company, in three of its services.

• Microsoft Azure — hosting and database. In use.
• Microsoft Entra External ID — sign-in. In use.
• Microsoft 365 — outbound email for notifications. Not yet in use.

Telling us about a problem

If you think you have found a security problem, please tell us at security@bizuncto.com before telling anybody else, and we will work with you on it.