Trust Center

The Trust Center lets you publish a public page for an organization that summarizes its security posture from live Breeze telemetry. It is an evidence summary, not a certification. Manage it from the organization record, in the Trust Center tab.

What the page shows

A set of security controls grouped by category, each marked Met, Needs attention, Not met, or Not assessed.
Optional percentages, an optional device count, and an optional “Managed by” block naming your company.
An introduction, a security contact email, and a website that you write.
Documents you explicitly choose to share. Nothing is shared by default, and each document is confirmed before it is added.
A “How this page is verified” section that states the method used.

What it never shows

Device names, hostnames, users, IP addresses, or any other per-device detail.
A single overall posture score. The page reports individual controls only.

How controls are evaluated

Each control is evaluated against the devices (or accounts) it applies to:

Eligible: the units the control applies to.
Assessed: eligible units that reported evidence inside the evidence window.
Passing: assessed units that meet the control.

The rules are fixed and shown on the public page:

Evidence older than 30 days is not counted.
A control is evaluated only when at least 80% of eligible units were assessed (the coverage floor). Below that, it reads Not assessed, never 0%.
A control reads Met at 95% or higher, Needs attention at 80% or higher, and Not met otherwise.

Controls are re-evaluated every hour while a page is published, and again when you publish. The hourly refresh re-reads the evidence only: your page settings, introduction, contact details and document list stay as they were at the last publish. Edits you save in the Trust Center tab reach the public page when you publish again. Removing a document from the page still takes it off the public page at the next refresh.

Who can publish

Publishing is limited to partners whose account is trusted. A new account must first earn trust, and a restricted account cannot publish. The Trust Center tab explains the reason when publishing is unavailable.

To publish or unpublish you need the organizations:write permission and a session with multi-factor authentication. Viewers without write permission can see the tab but cannot change it.

A page’s public URL is built from the partner slug and the organization slug. Renaming either one changes the URL of every trust page built from it, and the old links stop working.

Customer authorization

When you publish a customer’s page you must confirm that the customer authorized it and record who gave that authorization (name and role). Breeze stores the attestation with the date. A partner’s own page needs no customer authorization, so only your own internal organization can be marked as the partner page.

Framework references

Controls can show references to safeguards in frameworks such as CIS Controls v8 and the Essential Eight. These are indicative mappings, never a statement of compliance. Each public page carries the required attribution. CIS Controls are a registered trademark of the Center for Internet Security, Inc.

Declared controls

Some practices cannot be measured from telemetry, such as security awareness training, an incident response plan, vendor risk management, a data inventory, periodic access reviews, a backup and recovery plan, penetration testing and cyber insurance. You can declare these on the page.

A declaration is a short statement (10 to 1000 characters) made by a named member of your team, on behalf of your company. You confirm that it is accurate and that you are authorized to make it. You can attach a document from the organization’s library as evidence; the public page names it only when that document is also shared on the page.
Declaring, re-declaring and withdrawing need the organizations:write permission and a session with multi-factor authentication, and each action is recorded in the audit log.
The public page lists declared controls in their own section, labeled “Declared by your company on date”. They never carry a Met or Not met status, and they are never counted in the number of controls met.
Each declaration expires exactly 365 days after it is made. Thirty days before it expires, users with organizations:write on the organization get an in-app notification and an email. An expired declaration stays on the public page, muted and marked “Declaration expired on date”, until you withdraw it or publish again. A publish never carries an expired declaration forward, so re-declare it first to keep it on the page.
A new or re-declared control appears on the public page when you publish again. A withdrawal and an expiry take effect at the next hourly refresh, without a publish.

Documents available on request

A linked document can be Public (anyone with the page link downloads it) or Available on request. A document on request is listed on the public page by title, with no download link. Changing a document’s visibility asks you to confirm the disclosure again.

A visitor who wants it fills in a short request form: name, work email, company and the reason they need it. Then:

Breeze emails the visitor a confirmation link. The request reaches you only after they click Confirm request on that page. The link expires after 24 hours.
Users who can edit the organization get an in-app notification and an email. If you turn on Create a ticket for each confirmed request in the Document access requests section, Breeze also opens a ticket.
You approve or deny the request in the Document access requests section of the Trust Center tab. Approving requires multi-factor authentication. A denial emails the requester, with your note if you add one.
An approved requester is emailed a download link that works for 7 days. It covers the documents offered on request on the published page at the moment you approved. Resend link emails a new link and the old one stops working; the 7 days do not restart. Revoke ends access immediately.

Requests open only while the page is published. Downloads stop if you unpublish the page, if the document is removed, deleted or replaced by a newer version, or if you switch it back to Public.

Non-disclosure terms

You can add non-disclosure terms in the Document access requests section. Requesters must accept them before they can send a request, and Breeze records the exact text each requester accepted. The terms are shown as plain text and reach the public page when you next publish.

Privacy and retention

Access links are single-purpose and only ever appear after the # in the address, so they are never sent to a server in a URL or written to an access log. Breeze stores only a hash of each link. Requests (name, email, company, purpose) are deleted 365 days after their last status change, except for an approval that is still in force. Expired links are deleted after 30 days. Each request, confirmation, decision and download is recorded in the audit log.

Framework view

A trust page can map its controls to one or more security frameworks and show how many of each framework’s safeguards have evidence behind them. For example: “Evidence shown for 12 of 106 safeguards (9 verified by Breeze telemetry · 3 declared by the provider).” A safeguard counts when a shown control that references it was assessed from telemetry, or when a current declared control references it. Expired declarations and controls that are not assessed are listed but not counted. This is a summary of evidence, not a statement of compliance, and the page never says a business is compliant with, certified to, or meets a framework.

Choose frameworks in the Framework view section of the Trust Center tab. Use default clears the page’s own choice and falls back to the partner template, then the built-in default. The editor suggests Essential Eight for partners in Australia and Cyber Essentials for partners in the United Kingdom. The default is NIST CSF 2.0.

The CIS Controls v8 view requires BREEZE_TRUST_CIS_FRAMEWORK_VIEW (default off). Enabling it is an operator decision after CIS licensing is confirmed. While it is off, CIS cannot be selected and the framework view omits it; control cards still show their CIS references. See the environment reference.

Hardening safeguards

When the CIS Controls v8 view is enabled, the configuration hardening control gains a collapsed Safeguards evidenced by hardening checks list. Breeze maps each hardening check the agent runs, per operating system, to the CIS Controls v8 safeguards it supports, and evaluates each safeguard from the latest scan of every eligible device: a device passes a safeguard only when every mapped check that produced a result passed, and not applicable or errored checks do not count for or against it. Each safeguard then uses the same coverage floor and thresholds as every other control, so a safeguard with too little scan coverage shows as not assessed.

The list is partial by construction. Only some hardening checks map to a named safeguard, and a check with no mapping still counts toward the overall hardening pass rate. The public page shows safeguard identifiers, Breeze’s own short descriptions and a status. It never shows the hardening checks’ own titles or identifiers. The list appears only while BREEZE_TRUST_CIS_FRAMEWORK_VIEW is on, and it is not a statement of compliance.

Subprocessors, FAQ and history

Three optional blocks give buyers and auditors the context behind the controls. All three are drafted in the Trust Center tab and reach the public page only when you publish.

Subprocessors. List the third parties that process data for your customer. Add from detected tools suggests the security products, backup service and Microsoft 365 connection Breeze already knows about, and you can add any others by hand (up to 50). A suggestion is only a prefill: review the purpose, location and website before you save. Websites must start with https://.
FAQ. Up to 30 questions with short formatted answers (2,000 characters each), shown as expandable items. Answers are cleaned of scripts and unsupported formatting when you save and again every time the page is built.
Controls met over time. Off by default. When on, the page shows a 90-day chart of how many controls were met. The chart is built from the page’s earlier snapshots, so turning it on can show changes from before you enabled it. It shows change-points only (a point appears when the number changes at a re-evaluation) and does not claim every hour was verified. The setting follows the usual inheritance (page, then partner template, then default) and the Trust Center tab shows which one applies.

Partner defaults

Set defaults for every customer’s page once, in Settings → Partner → Trust Center: which of the optional blocks show (percentages, device count, “Managed by”, search indexing, the 90-day history), an introduction, the controls hidden by default and the framework view. A field you leave blank uses the Breeze default, and the form shows that default next to it.

Each organization’s Trust Center tab shows where each setting comes from: Set for this organization, Partner template, or Breeze default. A value an organization sets for itself always wins. Reset to inherited removes that value so the organization follows your defaults again. For the introduction, choose between the partner template’s introduction, no introduction, or a custom one.

Publishing freezes the values the page was published with. A later change to your defaults reaches a published page only when that page is published again.

Changing the defaults needs the organizations:write permission, access to every organization in your partner account, and a session with multi-factor authentication. Partner users limited to selected organizations can view the defaults but not change them.

Badge

A published page offers a live status badge you can embed on your website. The badge links to the public page and goes dark when the page is unpublished.

Self-hosting

Nothing to configure. Trust pages are served under /portal/trust/..., which your existing reverse-proxy rule for /portal already covers. The public API lives under /api/v1/trust/. Proxies that already forward X-Forwarded-Proto and X-Forwarded-Host (Caddy’s default) need nothing; if yours strips them, canonical URLs fall back to the internal origin.

PARTNER_TRUST_MODE applies only to hosted installs; self-hosted installs skip the trust gate.