Legal and security

Security

Written for the person on your side who has to check, which means it includes the part most pages like this leave out: a list of what we do not have.

In one paragraph

The short version

Every organisation using Consonas gets a database of its own, in a region it chose when it was created, that no other customer's request can address. Signing in supports two factor codes, passkeys and single sign on. What each person can see is decided by a role you define, by who owns the record, and by a separate grant for the sensitive ones. Everything anyone changes is written to an audit trail nobody can edit, including us, and no one here can open your organisation without a stated reason, a second approver and a line in that trail.

We do not hold SOC 2 or ISO 27001, there is no published penetration test, and two of the protections described below are built but not yet switched on in production. Those are named further down this page rather than omitted from it.

The decision that matters

Separation by architecture, not by a condition on a query

Almost every system of this kind keeps every customer's records in one shared database, with a column naming which customer each row belongs to, and relies on every query carrying a condition that filters by it. It is a reasonable way to build software. It is how most of the industry works. It has exactly one failure mode and the failure mode is severe.

The failure is that a query written without the condition returns one customer's records to another, and nothing about that request looks unusual while it happens. There is no alarm, because from the database's point of view a perfectly valid question was asked and answered. It is usually found weeks later, by a customer.

Consonas does not have a shared row space to filter. Your organisation is a separate database, addressed by your organisation's identity, and a request carrying somebody else's identity reaches someone else's database. A query written wrongly returns the wrong answer to you, which is a bug, rather than somebody else's information to a stranger, which is an incident. The longer argument, with the costs of the choice set out beside the benefits, is in why every customer gets their own database.

One database per organisation: Your organisation's records live in a Durable Object with its own SQLite database, addressed by your organisation's identity. Another customer's request does not reach it because there is no shared table for it to reach. This is the single most consequential decision in the product and it is the one you cannot change later.
No shared row space: There is no table anywhere containing relationships belonging to more than one customer. The control plane holds accounts, organisations, memberships and billing, and it holds no customer records at all. If it were read in full it would tell someone which organisations exist and who belongs to them, and nothing about the people those organisations work with.
Region, chosen once: The European Union or the United States, selected when the organisation is created and pinned from then on. UK organisations should choose the European Union: it is the closest region available and carries the data protection posture UK law expects. There is no setting to move it afterwards, including for us.
Schema per organisation: Each organisation carries its own journal of applied migrations and upgrades when it is next used, rather than in a single overnight window across every customer at once. A migration that fails affects one organisation and can be corrected before anybody else meets it.
Files held separately: Attachments are in object storage keyed by organisation, not inside the database, so reading a record does not carry a forty megabyte scan with it and a file cannot be reached without an authorised request for the record it belongs to.
Sessions outside both: Sessions are held in a key value store with an expiry, separate from the control plane and from your organisation's database. A session is a reference instead of a bearer of your data.

Two designs, five questions

The same five questions, asked of both designs

These are the questions worth asking any supplier holding your customer records, and the answers are a property of how the thing was built rather than of how carefully it is operated.

The question	The common answer	Ours
How is one customer separated from another?	Every query carries a condition naming the customer. Correct until one query does not.	There is nothing to separate. Each organisation has a database of its own and no request can address two.
What happens if a query is written wrongly?	It can return another customer's records, and nothing in the request looks unusual while it does.	It returns the wrong answer to you. The blast radius of a coding mistake is one organisation, which is the one that made the request.
Who can read the database directly?	Usually a small number of engineers, often with standing access to everything.	There is no console onto a customer database. Support access goes through the product, needs a reason and a second approver, and is written into that customer's own audit trail.
What does an upgrade touch?	Every customer at once, in one window, and a failure is everyone's failure.	One organisation, when it is next used. A failure is one organisation and is corrected before the next one meets it.
Where is the data held?	A region chosen by the supplier, sometimes changeable without notice.	A region chosen by you when the organisation is created, and fixed from then on, including for us.

Getting in

Identity, and proving it

Passwords: Stored as PBKDF2 with SHA256 and 600,000 iterations, with a random sixteen byte salt for each password rather than one shared salt, never reversible and never logged. We cannot tell you your password because we do not have it. A password reset is a token sent to the verified address, single use, with a short expiry.
Two factor sign in: Time based codes from any authenticator application, on every plan including Free. Charging for the thing that stops an account being taken over means the accounts most likely to be taken over are the ones without it.
Passkeys: Sign in with the device, using the platform authenticator. Phishing resistant, because the credential is bound to the origin and cannot be replayed against a page pretending to be us.
Recovery codes: Issued once, single use, so losing a phone is an inconvenience instead of the end of access to the business. Used codes are marked used rather than deleted, which is what makes the audit trail able to say which one was spent.
Single sign on: SAML on Enterprise, so your identity provider is the source of truth for who works there and removing someone there removes them here. Assertions are verified against the certificate you configure, and the claims are read from the signed and canonicalised bytes rather than from the surrounding document.
Break glass: An organisation that has enabled single sign on keeps a documented way back in for the case where the identity provider itself is unavailable, because otherwise an outage at your provider is an outage at your CRM.

Inside the organisation

Permission is about records, not about screens

Roles are defined per organisation in your own words rather than chosen from a fixed list. A role can be scoped to everything, to a team, or to what a person owns, and most small organisations need the middle one and are offered only the ends.

Records carry an owner, and records can be marked sensitive. Sensitivity needs a grant that is held separately from the role, so giving someone the ability to do their job does not quietly give them access to everything, and removing that grant does not require dismantling their role.

Search respects all of it. A search that returns a record you are not allowed to open is a permission leak wearing a helpful face, and a sensitive record excluded from your results is genuinely absent rather than shown as a locked row that confirms it exists.

How permissions work

Support access needs a reason and a second person

No one here has standing access to a customer organisation. Opening one is an action inside the product that requires a stated reason and approval by a second operator, and it writes an entry into that customer's own audit trail, which the customer can read without asking us.

The second approver is the part that matters. A control one person can complete alone is a control that will eventually be completed alone, at two in the morning, by somebody meaning well and in a hurry. Requiring two people is inconvenient precisely when inconvenience is the point.

The trail is append only. There is no route, no screen and no support process that rewrites an entry or removes one, including for us, and that is the only property that makes it worth having. An audit trail that the administrator can tidy up is a diary.

Erasing a person is the one exception, and it is a redaction rather than an edit. The entries about that person keep who acted, what they did and when. The values those entries carried are blanked and marked as redacted on erasure, because the alternative is a trail that quietly holds on to the name, the address and the note somebody was entitled to have removed, which would defeat the erasure it exists to evidence.

Where

A region you choose once, and cannot be moved out of quietly

The European Union or the United States, chosen at the moment the organisation is created, which is the point at which the decision is cheap and reversible by simply making a different one. From then on it is fixed. There is no setting in the product, no setting in an administration console, and no request to support that moves it.

If a region cannot be honoured, the product refuses to create the organisation instead of creating it somewhere else and telling you later. Creating an organisation we cannot place where we said we would is worse than refusing, because the customer finds out at the only point they can still choose otherwise.

UK organisations should choose the European Union. It is the closest region available and it carries the data protection posture UK law expects, and we say so here instead of leaving it as a decision you make in two seconds on a form.

The data processing agreement

The application

What the browser is allowed to do

A content security policy that actually restricts something

The application sends a content security policy that permits scripts only from its own origin, forbids inline script, forbids objects and plugins entirely, forbids the page from being framed by anybody, and restricts where forms may be submitted. Connections are limited to the application's own origin. The directives are the ones defined by Content Security Policy Level 3, used for what they were designed for rather than set to a permissive default.

The practical effect is that a cross site scripting flaw, which is the most common serious defect in a web application of this kind, has nowhere to send anything even if one exists. It is a second line rather than a first: the first line is not having the flaw, and the second line matters because everybody eventually has the flaw.

Tokens are held in memory, not in local storage

The access token lives in a variable for the life of the page and is never written anywhere a script can read it later. The refresh token is the only thing that survives a reload. A refresh token presented twice is treated as evidence of theft and ends the whole session family rather than the single session, because the honest interpretation of a replayed token is that someone has a copy.

Strict transport security, and no mixed content

HTTP Strict Transport Security is set with a long lifetime and includes subdomains, so after a first visit a browser will not attempt an unencrypted connection even if something tries to make it. Every asset the product loads comes from its own origin. There is no content delivery network hosting our JavaScript, no third party tag manager, and no analytics script watching people work.

The marketing site ships no JavaScript at all

The site you are reading is static HTML and CSS with no script on any page. The menu opens with CSS, the frequently asked questions expand with a native element, and the illustrations animate with keyframes. There is nothing to compromise and nothing watching you read.

Six absences

Six things we do not have

A security page without this section has decided what it wants you to think rather than what is true. Two of these are things that are built and not yet switched on, and they are here for the same reason as the rest.

We do not hold SOC 2 or ISO 27001: Neither certification, and no audit in progress at the time of writing. Both are meaningful and both cost a great deal for a company of our size. If your procurement requires one, we are not the right supplier yet and would rather tell you now than at the end of a process.
There is no published penetration test: No third party test has been commissioned yet. When one is, the report will be available under an agreement rather than described in a sentence on a marketing page.
Bot protection is not enabled in production: Both ends are now written: the server demands a challenge on sign in after three failures, and the registration and sign in screens draw one wherever the deployment carries a key. Production carries no key at the time of writing, which the health endpoint reports honestly rather than concealing, so the demand is the only half that is live. It is the next thing being finished.
Rate limiting is not yet doing its job: Limits are defined in the code and, on inspection of live traffic, were not refusing requests as they should. That is under investigation. Writing it here rather than waiting until it is fixed is the point of having a section like this one.
There is no bug bounty: No paid programme. There is an address, it is read by somebody who can act on it, and a report will get an answer rather than silence.
We are a small company: That is a security property as much as a commercial one. There are fewer people with access, which is good, and fewer people to notice something, which is not. Weigh it honestly rather than taking a page like this as evidence either way.

The strongest security control available to you as a customer of any small supplier is not something the supplier can give you. It is holding a current copy of your own data somewhere they do not control.

Which is why the export is free, on every plan, and worth running before you need it rather than after.

If something goes wrong

Reporting, and what happens next

Reporting a vulnerability

Write to security@consonas.com with enough detail to reproduce the problem. You will get an acknowledgement from a person rather than a ticket number, and an answer when there is one.

We will not threaten you, we will not require you to sign anything before we will read your report, and we will not argue that a finding is out of scope because it is inconvenient. There is no paid programme, and we say so plainly instead of implying one exists and then declining to pay.

What we ask in return is the ordinary thing: do not access, modify or delete data belonging to anyone else while you are demonstrating a problem, and give us a reasonable period to fix it before publishing.

If there is an incident

Affected customers are told in plain terms, with what is known at the time and an explicit statement of what is not yet known, rather than after the account is complete and rounded off. Where the law requires a supervisory authority to be notified within seventy two hours, that happens.

The report goes to the customers affected rather than onto a blog, and it says what happened, what data was involved, what we have done, and what you may need to do. If the honest answer to a question is that we do not yet know, that is what it will say.

What your own audit trail gives you

Independent of anything we tell you, your organisation's audit trail records who did what and when, including any access by us. It cannot be edited by an administrator or by us. In an investigation on your side, that is the record that matters, and it is the reason it is on every plan rather than on an expensive one.

Bin, erase, close

What is held, for how long, and what erasure actually removes

Deleting a record

Deleting a relationship in the product moves it out of the working views and keeps it recoverable, because the most common reason a record is deleted is that somebody meant to delete a different one. It stays in your organisation, it stays in your export, and it is visible to anybody with the permission to look at deleted records.

That is deletion in the ordinary sense of tidying up. It is deliberately not the same operation as erasure, and conflating the two is how organisations end up believing they have honoured a request they have not.

Erasing a person

Erasure is a separate, deliberate action that removes the person from every place they appear rather than from the one you happened to be looking at. That includes the record, the connections to other records, the notes attached to them, their appearances in audiences, their entries in message history, their consent records and the files held against them.

What survives is the audit trail's statement that an erasure happened, when, and who performed it, without the content of what was erased. That is deliberate and it is the shape the law expects: you must be able to demonstrate that you honoured the request, and demonstrating it must not require keeping the thing you erased.

Closing an organisation

Closing an organisation is a two step action. You are told exactly what will be removed, counted table by table, and you are told to take an export first, because what happens at the end of it is a deletion we cannot undo for you.

Between the two steps and the deletion there are thirty days, and the screen that closes the organisation names the date. They exist because somebody eventually closes the wrong organisation, or closes the right one and is overruled the following morning, and a button with no way back is a cruelty rather than a discipline. During those thirty days the organisation is shut: nobody can write to it, and its owner alone can do three things, which are take the export, look at the plan, and reopen it. An administrator cannot do any of the three.

What there is not is a quiet retention period we do not tell you about. Thirty days is the number on the screen, in the terms and in the data processing agreement, and it is the same number whether an owner closed the organisation, an operator did, or it went a year without anyone signing in. When it is up the data is deleted, and the backups it appears in age out within a further thirty days.

What we keep regardless

Billing records, for as long as tax law requires them to be kept, which in the United Kingdom is six years. These contain the organisation, the amounts and the dates, and no customer records. Nothing about the people you work with is in them.

Two honest qualifications on that six years. It is a commitment we make and not a rule anything in the product enforces: no code keeps a billing record for six years or removes it on the day the sixth ends, and if we ever build one this page will say so. And there are none yet, because the paid plans have not opened: closing an organisation today leaves no billing record behind, because there was never one to leave.

Around the edges

Logging, email, and the customer portal

What appears in a log and what does not

Operational logging records that a request happened, which organisation it belonged to, which route it hit, whether it succeeded and how long it took. It does not record the contents of your records, the bodies of requests, the contents of messages, tokens, passwords or session identifiers.

The reason to be strict about this is that logs are the least protected copy of anything. They are read by more people, kept in more places and forgotten about more often than the database is, and a system that logs generously has quietly created a second, worse copy of its customer data. The privacy notice lists the same set from the other side, as data we hold and are answerable for.

Measurement is deliberately built the same way. The product records how much an organisation is using, in counts, with no token and no content, because knowing that an organisation wrote four thousand records last month requires none of those records.

Email, and the things done to protect it

Everything the product sends leaves from one domain we control, including a reply from your shared inbox, which comes from an address on that domain rather than from yours. That matters because a message can only be signed for the domain the sending service is set up for, and a message signed for one domain but sent from another fails the check at the far end. So the code compares the two settings before it sends anything and refuses an address that is not on the sending domain, rather than sending mail that would arrive unauthenticated. The application's health endpoint reports whether they agree, so a deployment that got it wrong is visible on the first request instead of in somebody's spam folder.

The SPF, DKIM and DMARC records for that domain are DNS rather than code, and no page here can honestly claim to have checked them: they are published when the domain is set up and we have not built anything that reads them back. What the software guarantees is the part underneath: that we cannot quietly start sending from a domain nothing is signing for.

Inbound mail that becomes part of a record is matched to the organisation and the relationship it concerns. A reply address is per organisation rather than shared, so a message intended for one customer's system cannot be delivered into another's by guessing an address.

Verification and password reset messages carry single use tokens with short expiries, and the link is bound to the address it was sent to. A token that has been used is spent, and using it again does nothing rather than working a second time.

The customer portal is a separate trust boundary

The portal is where someone who is not your staff signs in and sees their own enquiries. It runs against the same organisation database and under a strictly narrower set of rules: a portal session can address the matters belonging to that contact, the bookings and quotations belonging to the same contact, and the help articles you have marked as being for customers. Nothing else. The matters and the bookings are scoped by the identical test, and what comes out of a booking is a name, a stage, an outcome where there is one, and a date: no value, no owner, no note. A portal session cannot reach the relationship record itself, anybody else's matters or bookings, or any internal note, and cannot act on anything it can see beyond adding to its own conversation.

Portal sessions are held for the browser session rather than persisted, because a customer signing in from work is often signing in on a machine someone else uses. Closing the browser ends it. That is a slightly worse experience and a considerably better default.

A record marked sensitive is excluded from the portal separately from the internal rules, so marking something sensitive does not depend on someone also remembering that the customer can see their own matters.

Underneath

The platform, the suppliers, and the code we did not write

Where this actually runs

Consonas runs on Cloudflare's developer platform. Each organisation is a Durable Object with a database of its own, and the object storage and key value store are theirs as well, which means the physical security, the hardware, the network and the encryption at rest are their responsibility and are covered by their certifications rather than by ours.

We say this plainly because it is the honest division. A small company claiming credit for a large infrastructure provider's data centre controls is describing someone else's work, and a buyer who wants those assurances should be reading that provider's documentation rather than ours. What is ours is everything above it: the isolation model, the access control, the audit trail, the identity handling and the decisions about what to log.

Sub processors

The current sub processor list is on its own page and is kept current rather than annually. Adding a sub processor that touches customer data is a change we tell customers about instead of one discovered in a document, and the data processing agreement sets out how that notification works.

The list is deliberately short. Every additional supplier is another organisation with a copy of something, another agreement to hold them to, and another party whose incident becomes your incident. The default answer to whether to add one is no.

Dependencies and the supply chain

The application deliberately carries very few third party libraries, and the marketing site carries none at runtime because it ships no JavaScript. Every dependency is a piece of code we did not write running with our privileges, and the cheapest supply chain control available to a small team is to have almost nothing to control.

Where a library is genuinely required, such as the one that verifies SAML signatures, it is a vetted implementation instead of something written here. Cryptographic verification is exactly the kind of code that looks simple and is not, and writing our own would be the more dangerous choice by a wide margin.

Who has access on our side

Access to production is limited to the people who operate it, protected by two factor authentication, and reviewed when someone's role changes. There is no shared account, and there is no standing route from an operator's machine into a customer database, which is the point of the support access flow described above: the only way in is one that asks for a reason and tells the customer.

When it is not working

Availability, and what we will not pretend about it

There is no published uptime commitment yet

No service level agreement with a percentage and a credit, because we have not run long enough to make a promise of that kind meaningful. A number invented before there is history behind it is a marketing figure rather than a commitment, and the first time it is missed everybody discovers that.

What exists now is a health endpoint that reports honestly, including reporting the things that are not configured, and an intention to publish a status page and a real commitment once there is enough operating history for both to mean something.

What isolation does for availability

The same decision that separates your data separates your load. Because each organisation is its own database, a customer running a very heavy import does not slow down anyone else, and a problem inside one organisation's data is confined to that organisation.

It also changes what an upgrade risks. Migrations apply per organisation, when that organisation is next used, so a bad migration affects the first organisation to meet it rather than every customer simultaneously at three in the morning.

What you should do about it anyway

Run an export on a schedule and keep it somewhere we do not control. That is sensible with any supplier, it is the reason export is free on every plan here, and it is the only availability control that remains entirely in your hands.

Translating

Your questionnaire's words, and the ones used here

Most security questionnaires are written against the design this product deliberately does not use, so several questions arrive slightly bent. These are the five that most often need translating before the answer means anything.

The word on the form	What it usually assumes	What it means here
Tenant isolation	A column on every row naming which customer it belongs to, and a review that asks whether every query filters on it.	There is no shared row space to filter. The unit is an organisation with a database of its own, so the question becomes which database a request can address rather than which rows it remembered to exclude.
Data residency	A preference recorded on a form, honoured where convenient, and changeable by the supplier without telling you.	The European Union or the United States, chosen when the organisation is created and pinned from then on, with no setting to move it afterwards including for us. There is no United Kingdom region, which is usually what the form is really asking.
Audit log	Application logging kept for a period, rotated on a schedule, and clearable by whoever administers the system.	An audit trail no one can edit, including us, written for you rather than for our diagnostics. An audit trail an administrator can tidy up is a diary.
Least privilege	A role chosen from a fixed list of three, one of which is more than anyone needs.	Roles defined in your own words, scoped to everything, to a team, or to what a person owns, with sensitivity carried by a separate grant so that access to the ordinary work does not bring the difficult records with it.
Vendor access	Staff can open your account when they judge they need to, recorded in the supplier's own systems if it is recorded at all.	An action inside the product that needs a stated reason and a second approver, and that writes into your audit trail as well as ours, so you can check without asking.

Getting in, getting out

What actually goes wrong here is nearly always sign in

The identity provider is usually the thing that breaks

Assertions are verified against the certificate you configure. When that certificate is rotated or expires, verification fails and sign in fails, which is the correct behaviour and no comfort at all if single sign on is the only route in. That is what break glass is for, and the point of writing it down is that you write it down while nothing is wrong. An organisation working out its way back in during an outage at its own provider is doing that work at the worst possible moment.

One person, two organisations

An account can belong to more than one organisation. Membership sits in the control plane and permission sits inside each organisation, so a role in one grants nothing in the other, and the databases are separate regardless. Being trusted somewhere carries nothing with it when you arrive somewhere else.

The phone and the recovery codes are both lost

Recovery codes are issued once and each is single use, and they exist precisely so this case does not arrive. Used codes are marked used rather than removed, which is what lets the audit trail say which one was spent and when. The practical advice is dull and worth following anyway: keep them somewhere that is not the phone they exist to replace.

Somebody leaves in the middle of the week

With single sign on, removing them at your identity provider removes them here, which is most of the reason to have it: their next assertion is refused as a person who is not a member, and any session they still hold here is ended at that moment rather than left to expire. What there is not is a provisioning feed, so somebody added at your provider is not added here until they sign in. Without single sign on, removal is a membership change made inside your organisation, and whoever removes them is asked who inherits the records they owned. Sessions carry an expiry rather than lasting indefinitely, and the audit trail is what tells you what was done before the change, which is the question that actually gets asked afterwards.

Four settings an owner picks

Codes or passkeys, and the three other settings an owner has to pick

Codes or passkeys as the way your team proves it is them

Authenticator codes travel with the person and can be read out over the telephone to somebody convincing, which is exactly how a good phishing attempt ends. Passkeys cannot be read out at all, because the credential is bound to the origin, and the cost is that they live on a device and a new phone is a small errand. Most teams end up with both in use and should know which one they are actually relying on.

How widely the sensitive grant is held

Give it to everybody and marking a record sensitive stops meaning anything. Give it to one person and the work queues behind them the week they are away. The middle is usually right, and it is worth choosing deliberately instead of settling wherever the first request happened to land.

Single sign on, and the way back in

Choosing SAML makes your identity provider the source of truth for who works there, which is the right answer for most organisations already running one. It also makes an outage at that provider an outage at your CRM, unless the break glass route is agreed and written down before anyone needs it.

How often you take an export

Running one on a schedule puts a copy of your data somewhere we do not control, which is the strongest control available to you and also a copy you are now responsible for keeping safe. Both halves are true. The version of this decision that goes wrong is the one nobody makes.

Asked in diligence

Asked by the person who has to sign this off

Can Consonas staff read our records?

Not without opening your organisation through the product, which requires a stated reason and a second person to approve it, and which writes an entry into your own audit trail that you can read. There is no console onto a customer database and no standing access. The control that matters here is the second approver: a control one person can complete alone is a control that will eventually be completed alone.

Is data encrypted?

In transit, always, over TLS, with HTTP Strict Transport Security set so a browser will not attempt an unencrypted connection after the first visit. At rest, by the platform, across the database, the object storage and the key value store. We do not additionally encrypt individual fields with a customer held key, and if that is a requirement for you then it is one we do not currently meet.

What happens if somebody takes over an account?

The blast radius is that account's permissions inside one organisation. It is not a route into another customer's data, because there is no shared store to route into. Two factor sign in and passkeys are on every plan to make it less likely in the first place, and the audit trail is what lets you establish afterwards what was actually done.

Do you use our data to train anything?

No. Your records are not used to train models, are not pooled into an aggregate product, and are not sold, shared or licensed to anyone. The only processing is what is needed to run the product for you and what you ask for.

What are your backups and how fast is recovery?

Storage is replicated by the platform. We have not yet published a recovery point or recovery time objective, and we would rather say that than quote a number we have not tested to. Your own defence, which we would recommend regardless of supplier, is the export: complete, free, on any plan, and worth running on a schedule so that a copy exists somewhere we do not control.

How do I report a vulnerability?

Write to security@consonas.com with enough detail to reproduce it. You will get an acknowledgement from a person. We will not threaten you, we will not ask you to sign something before we will read it, and we will tell you when it is fixed. There is no paid programme and we will say so instead of implying one.

What happens if there is a breach?

We tell affected customers, in plain terms, with what we know and what we do not yet know, rather than waiting until the account is complete. Where the law requires notification to a supervisory authority within seventy two hours, that happens. An incident report goes to affected customers rather than to a blog. Both of those are undertakings by us rather than things software does, so the operator area now holds a register that starts a clock: declaring an incident stamps the moment, computes both deadlines from it, and lists every organisation still owed a message once its day is up. It sends nobody anything. A breach notification is written by a person who understands what happened, and the entry in your own audit trail is the record of that message having been sent.

Can we get a copy of your policies for procurement?

Ask, and be specific about what your process actually needs. We would rather answer a real questionnaire honestly than publish a set of documents written to survive one. Where the answer is no, it will be no in writing instead of a paragraph that reads like yes.

Check it yourself

Create a free organisation, put something in it, and run an export. That tells you more about a supplier than any page like this one.

Start free Send a questionnaire

Three people, a thousand relationships, no card and no time limit.