The trust centre screen shows a percentage and a list of areas, each marked ready, monitor or missing. It is a useful review prompt and a poor headline number, and the difference between those two things is worth about twenty minutes of your attention if anyone in your organisation is likely to quote the percentage at anyone else.
This guide explains what the rows are actually testing, which of them your own configuration can move, and the two places where the display is easy to misread.
Nine rows, one percentage
The screen evaluates nine items spanning access control, integrations, audit coverage, identity, AI guardrails, change management, privacy workflow and customer-facing trust material. Each lands on one of three verdicts, and the percentage is a straight average: a ready row contributes full marks, a monitor row contributes half, a missing row contributes nothing.
With nine rows, each one is worth roughly eleven points, and moving a single row from monitor to ready shifts the headline by about five. The number therefore jumps in visible steps rather than drifting, which is worth knowing before somebody puts it on a slide and asks why it moved.
Every row carries more than a colour: a line of evidence explaining what was counted, a recommendation, a link to the dashboard screen where you would act on it, and the name of the API resource that exposes the same underlying data. That last one is the quiet feature. A row you disagree with can be checked against the data rather than argued about.
This is the thing to understand first, because it explains most of the surprises.
Each row combines up to two very different questions. The first is a capability check: does the underlying record-keeping for this area exist for your account at all — the stores and fields the feature needs in order to have anything to say. The second is a data check on your own account: do you have tokens, deliveries, exports, identities.
The capability half is what usually produces a missing verdict. If a row reads missing, the most likely explanation is not that you configured something badly but that the underlying capability is not present for your account — which is a question for your provider, not a task for your afternoon. The ready-versus-monitor half is the part your own setup moves.
The clearest illustration is the audit-coverage row, which is a pure capability check with no account data in it at all. It counts how many of the product's audit trails exist — ticket activity, article history, webhook deliveries, tool invocations, channel identity — and grades on how many of the five are there. Nothing you do in the dashboard changes that row. It reads the same for every account sharing the same platform, and it is telling you about the product's completeness rather than about your practice.
That is not a criticism — knowing which audit trails exist is genuinely useful when you are answering a security questionnaire, and answering security questions from customers covers what to do with the answer. It is just not a measure of how well you are running your account, and it is averaged into a number that looks like one.
The webhook row is the sharpest example of a pattern worth watching for across the screen. It reads ready when nothing has failed recently and nothing is stuck, and it reaches that verdict whether you have twenty webhook subscriptions running cleanly or none at all.
An account that has never configured a webhook scores exactly the same as an account running them flawlessly, because both have zero failures and zero stuck deliveries. Absence of evidence and good evidence produce the same colour.
Once you have seen it on that row you will spot the shape elsewhere: a verdict computed from problem counts will always flatter an account that is not using the feature. This is not a bug so much as an unavoidable property of scoring by exception, but it does mean a high score is compatible with having configured very little. Read the evidence line under each row, which states the counts, rather than the colour above it.
The time windows are not the same
Different signals on this screen are counted over different periods, and one asymmetry has a practical consequence.
Recent webhook failures are counted over the last day, so a genuine burst of delivery failures ages out of the count within twenty-four hours and the row returns to ready on its own. Stuck deliveries — ones still waiting to be sent — are counted with no time limit at all, so a single delivery that got wedged some months ago holds that row at monitor indefinitely.
The result is a row that can look permanently mildly unhealthy because of one old item, while a real incident that happened last week has already vanished from it. If a row sits at monitor and never moves, that is your cue to go and look at what is pending rather than to assume the row is broken; when your webhook does not arrive covers the diagnosis.
The colours are not comparable across rows
Each row defines its own thresholds, and they do not mean the same thing.
The API credential row, for instance, reaches ready only if you have at least one live token, and sits at monitor if you have none — so an account that deliberately does not use the API is marked as needing attention for not using it. That is a defensible prompt in a governance checklist and a poor signal if you read the colours as a health bar, because there is nothing to fix.
Compare that to the webhook row, where having nothing configured scores full marks. Two rows, opposite treatments of the same underlying situation. Both are reasonable in isolation, and averaging them into one percentage quietly implies a consistency that is not there.
The lesson is to read the screen as nine independent prompts, each with its own logic, rather than as nine measurements on a common scale. The percentage is a convenience for spotting movement over time, not a quantity to compare against anything.
What the score is not
Worth stating plainly, because a screen with a percentage and the word trust invites the assumption. The score is computed from your own account by the product itself. It is not an audit, it is not an external assessment, and it is not a certification of any kind. Nobody outside your account has reviewed anything to produce it.
If a customer asks for evidence of your security posture, this screen is a good place to gather material — the evidence lines tell you which controls exist and what your own numbers are — but the artefact you send them is your own written answer, alongside our published trust and security information, not a screenshot of a percentage. Sending the percentage invites exactly the misreading this guide is about. Evaluating live chat vendor security covers the questions worth asking and answering properly.
How to use it well
Treat it as a monthly review checklist. Open it, read the evidence line on every row, and ask one question per row: is this telling me about my configuration or about the platform, and if it is about my configuration, is the number it quotes the number I expect?
The rows that reward that attention most are the ones counting things you own. Live API tokens are worth reviewing regularly regardless of what the row says, and knowing which tokens are safe to revoke covers how. Stuck deliveries are worth clearing. Expired portal tokens are worth understanding. Those are real tasks with real outcomes, and they are what the screen is genuinely good at surfacing.
What is not worth doing is optimising the percentage. Several rows cannot be moved by anything you do, at least one rewards you for not using a feature, and the average of nine differently-scaled signals is not a quantity that improves in a meaningful sense. Fix the things the evidence lines point at, and let the number do whatever it does.
Put it into practice
- Read the evidence line, not the colour. The counts underneath are the part with information in them.
- Separate platform rows from account rows. A missing verdict usually means a capability is absent, not that you erred.
- Do not read ready as configured. Rows scored by exception flatter accounts that use nothing.
- Investigate a row stuck on monitor rather than ignoring it; an old pending item can pin one indefinitely.
- Never send the percentage to a customer as evidence. It is a self-computed prompt list, not an assessment.
- Review it monthly and act on the rows you own — tokens, deliveries, exports — and leave the number alone.
Screens like this are most valuable when they are read as questions rather than verdicts. Nine prompts asking whether you have looked recently at nine things worth looking at is genuinely useful. A percentage summarising them is a convenience that becomes a liability the moment somebody outside the conversation reads it as a grade.