Trust Center

The builder at /trust-center publishes a customer-facing summary of your security, privacy, compliance, certifications, approved resources, and subprocessors. The public page is served at /trust/[trust-id] or through a configured custom domain.

A trust center reduces repetitive due-diligence work only when it stays consistent with the internal program. Treat it as a governed publication, not a marketing page detached from controls and evidence.

Build the page

The builder provides live preview and four configuration areas:

Branding

Configure light/dark logos, contact email, typography, primary/secondary/accent/hero colors, hero style, and dark-mode support. Branding should not obscure dates, status, or disclosure boundaries.

Content

Write introduction/title/tagline copy and up to two calls to action, such as vulnerability reporting and privacy policy links. The Resources section can publish approved policy versions available for enabled frameworks. Verify external and mailto: links before publication.

Sections

Enable or disable page sections, select visible frameworks, and configure certification details such as number, verification state, and certificate file. Choose which vendor records appear as subprocessors.

Only publish claims and artifacts you are authorized to disclose. “Compliant,” “verified,” or similar labels should match the actual scope, period, legal entity, and certificate/report wording.

Advanced

Configure a custom domain. Noru provides automatic SSL after DNS/domain setup and publication. Domain changes can affect customer bookmarks and certificate issuance; coordinate them through change management.

Save, preview, publish

1. Save creates or updates the private draft.
2. Preview renders the saved configuration for inspection.
3. Publish pushes the current draft to the public delivery layer; propagation can take about a minute.
4. Later saves remain draft changes until republished.
5. Unpublish removes the public page while retaining internal configuration.

Before every publication, compare framework/certificate scope, policy versions, subprocessor list, contact details, and claims against internal source records. Keep a recurring review cadence and republish after material approved changes.

Certificate requests (/trust-center/requests)

Public visitors can request a private certificate attachment. Requests show requester name/email, framework/certificate, request time, and status. An authorized reviewer can reject the request or approve it, which sends the certificate.

Review the requester's identity, relationship, purpose, and any NDA/access conditions before approval. Publication metadata and a request form are not access authorization. Avoid attaching reports or certificates containing confidential scope details unless the recipient is entitled to them.

Relationships

• Framework visibility comes from organization framework configuration.
• Approved policies can become public Resources.
• Certifications use uploaded files and explicit status/number metadata.
• Subprocessor content draws from selected vendor records; keep privacy and vendor data consistent.
• The dashboard shows whether a trust page has been published.

Compliance value and limits

Trust centers support transparency, customer due diligence, vendor-sales efficiency, and consistent communication. They are not required by every framework, do not replace contractual disclosures, and do not prove that controls operate. Public content should always be narrower than or equal to what reliable internal evidence supports.