Setting Up a Safeguard Trust Center (Early Access), Step by Step

To set up a Safeguard Trust Center, open Compliance › Trust Center, choose Edit Trust Center or Advanced settings, fill in a public slug, organization name, headline and contacts, pick the frameworks and control areas to show, then turn on Publish Trust Center and save. Restricted documents such as an audit report or a penetration test summary go behind access requests, where a visitor accepts your NDA, confirms their email and waits for a reviewer or an auto-approval rule. The Trust Center is early access and is switched on per workspace, so if the tab is missing, ask your Safeguard administrator before anything else.

This guide walks through the whole flow as Safeguard's docs describe it today, explains why buyers ask for a trust page in the first place, and is plain about what the page does not prove and which decisions stay with your team.

Key takeaways

• Trust Center (early access). A public page at https://<slug>.trust.safeguard.sh that shows framework status, monitored controls, policies, subprocessors, an audit outcome and documents. It is switched on per workspace, and nothing goes live until someone turns on Publish Trust Center.
• Compliance and GRC suite (GA). The Trust Center reads from it. Frameworks, controls, tests, policies and the vendor register you keep there are what the page shows, so the page is only as good as the programme behind it.
• Live, not a snapshot. Published controls are read from continuous monitoring, so a control that starts failing shows as failing without a republish. A framework's live readiness updates within five minutes.
• Restricted documents need a file, an NDA and an access flow. Access management is also switched on per workspace. Only a compliance reviewer can approve a request, unless an auto-approval rule you wrote decides it.
• Questionnaire auto-answer is part of the early access Trust Center. Treat every drafted answer as a draft. Safeguard's AI assistant and MCP clients can prepare work but never approve, accept or sign off.
• A readiness score is not an audit. Safeguard's docs say so directly, and a framework that needs an independent auditor cannot be shown as compliant on a self-assessment.
• MCP server (GA) and desktop app (early access, beta) appear in the demos at the end. Autonomous remediation (GA, ships switched off), Gold Open Source (GA), Gold Registry (GA) and fork and patch (early access) appear in the remediation section.

Why do buyers ask for a trust center?

Most software sales to a company with a security team pass through a vendor review. The buyer sends a questionnaire, asks for your audit report, asks who processes their data on your behalf, and asks how to report a vulnerability. The same questions arrive from every prospect in a slightly different spreadsheet, and each round stalls a deal.

A trust center is the public answer to the questions that do not change. It does not replace the review. It shortens it, because the reviewer arrives already knowing your frameworks, your policies, your subprocessors and how to request the documents that cannot be public. Safeguard's own product page puts the pitch plainly: the page answers the standard questions "before anyone opens a spreadsheet."

Buyers also have their own obligations. Several standards put duties on them to understand and keep watching their suppliers, and a page that stays current is easier to rely on than a PDF that went stale a week after it was sent.

The buyer's side: supply chain risk is their duty too

NIST SP 800-161 Rev. 1 is the US federal guidance on cybersecurity supply chain risk management (C-SCRM). Its abstract describes the concern directly: organizations worry about products and services that may be vulnerable "due to poor manufacturing and development practices within the supply chain," and about their limited visibility into how what they acquire is built and run. The publication asks organizations to identify, assess and mitigate those risks at every level, including in risk assessments for the products and services they buy. A trust page is one of the inputs to that assessment.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, makes a related point from the producer's side. Its abstract notes that because the SSDF gives a common vocabulary for secure development, purchasers and consumers "can also use it to foster communications with suppliers in acquisition processes." In practice that means buyers ask suppliers which secure development practices they follow, and they expect an answer they can file.

CISA's Secure by Design Pledge pushes in the same direction, with an emphasis on public transparency. Signers make a good faith effort toward seven goals over a year, and where they make measurable progress, they "should publicly document" it within one year of signing. The pledge is voluntary and not legally binding, but it has made public posture statements more normal for software makers.

What vendor review norms shape what you can publish?

The norms below decide what belongs on the public page and what has to sit behind a request. None of them is a Safeguard rule. They are the expectations your reviewers bring with them.

Standard questionnaires. The Cloud Security Alliance publishes the STAR Level 1 Security Questionnaire, CAIQ v4.1, released in January 2026. CSA describes it as a set of yes or no questions a cloud customer or auditor may ask a provider to gauge compliance with the Cloud Controls Matrix (CCM), and it is the questionnaire providers use to submit to the STAR Registry. The STAR Registry itself is publicly accessible, and Level 1 is a self-assessment. The Shared Assessments Standardized Information Gathering questionnaire (SIG) is another widely used format; its site was not reachable for this guide, so check its current version with Shared Assessments directly. Whichever format your buyers send, the questions repeat, which is why a trust page and a library of reviewed answers save so much time.

Audit report distribution. The AICPA describes SOC reports as CPA examinations that give "independent assurance" to a service organization's customers, which it calls user entities. It describes SOC 3 reports as general use reports that "can be freely distributed" because they carry less detail than SOC 2. The practical consequence is that the detailed SOC 2 report is not something to link from a public page. Providers share it with named parties, usually under NDA, and that is exactly the pattern a restricted document with an access request supports.

Subprocessor duties under GDPR Article 28. The EDPB's Guidelines 07/2020 on controllers and processors explain the duty. Under Article 28(2), a processor must not engage another processor without the controller's prior specific or general written authorisation, and under a general authorisation the processor must inform the controller of any intended addition or replacement so the controller can object. The guidelines add a detail that matters for trust pages: it is not enough for a processor to give the controller generalized access to a subprocessor list that changes from time to time. The processor has to actively flag each new subprocessor. Article 28(4) also keeps the processor fully liable to the controller for its subprocessors. A public subprocessor list is helpful, but it does not discharge the notification duty on its own.

Vulnerability reporting. RFC 9116 defines security.txt, a machine readable file that tells researchers how to report a vulnerability to you. The RFC says the file complements, and does not replace, a security policy. A trust page that names a security contact address does the human readable half of the same job.

What goes on the page?

Safeguard's setup docs list the sections the public page can carry. Each section appears only when it has something in it, so an empty section never shows up as a blank heading.

• Frameworks. You pick which frameworks to publish. Each shows one status: Compliant, In progress, Not assessed or Signed.
• Published controls. You pick control areas, and each is read live from continuous monitoring. Only areas from frameworks you publish are listed, and an area appears once a compliance scan has evaluated it.
• Published policies and Sub-processors. On your main Trust Center page these come from your policy and vendor registers whenever those registers have entries.
• Coverage by offering. A grid of what each of your products covers. It stays hidden until you set it up.
• Data collected. What personal data you hold and what you do not. The docs make a good point here: saying no is a stronger answer than leaving a category out.
• FAQ. The questions reviewers ask before they email you, shown in your order.
• Updates. Dated posts, such as a new report or a framework achieved, newest first.
• Audit outcome. The auditor's opinion from a completed audit.
• Documents. Public and restricted files, once access management is on.

Some sections appear only where they are switched on for your workspace:

• Quick summary: up to 12 short highlights at the top of the page, such as annual audits, penetration tests or a bug bounty, each with an optional icon, detail and https link. The docs instruction is short and worth repeating: state only what is true today.
• FAQ categories, such as Access Management, Encryption or Vendor Management.
• Incidents and security advisories: an update can be an Announcement, an Incident or a Security advisory. An incident carries a status (Investigating, Identified, Monitoring, Resolved or Not affected) and a dated history.
• AI governance: the AI in your product in your own words, covering the models, who makes them, where they run and how you govern them, on its own tab.

How framework statuses are decided

The status next to each framework is the part reviewers read first, so it is worth knowing where each one comes from.

Two rules in the docs stop the page from overstating your position. A framework that needs an independent auditor or certification body cannot be declared compliant on a self-assessment; you show its certification instead. And when you publish live readiness for a framework, the page shows the readiness score of your own controls, which Safeguard's docs describe as "not an audit," and it shows Compliant only when every in-scope control passes.

The frameworks docs go further. A readiness score is the share of in-scope requirements that pass, a requirement waiting for evidence counts as not yet passing, and the score reads 100 only when everything in scope passes. The docs state that a readiness score is Safeguard's assessment of what it can see and is not an audit opinion or a certification. Choosing a framework does not certify compliance either. Keep that sentence in mind when you write your headline.

Before you start: what has to be true first

The Trust Center is a view on your compliance programme, so most of the setup work happens before you open the Trust Center tab. Check these first.

1. The feature is on. Compliance › Trust Center must be visible. If it is not, the docs say the Trust Center is not switched on for your workspace and you should ask your Safeguard administrator. Access management, which you need for restricted documents, is switched on per workspace too.
2. Your frameworks are chosen. Open Compliance › Manage, then the Frameworks tab, find each framework that applies, switch it on and select Save. Out of the box, Safeguard switches on every framework except the national data protection and cybersecurity laws, which you turn on yourself. Your plan decides which frameworks you can choose from. The library covers hundreds of frameworks, so be deliberate: publish the ones you actually work to.
3. A compliance scan has run. A control area appears on the public page only once a compliance scan has evaluated it.
4. Your registers have entries. Published policies come from your policy register and subprocessors from your vendor register. If those are empty, those sections stay hidden.
5. The right people hold the right roles. Publishing an audit outcome and deciding access requests both need a compliance reviewer or an administrator. The approvals docs define a reviewer as an administrator (Super Admin, Tenant Admin or Org Admin), a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone granted the matching compliance permissions. The Auditor role alone is not a reviewer.
6. Legal has the NDA text ready. You will paste it into the NDA section and publish a version before the access portal can be turned on.
7. Someone owns the contact inboxes. The security contact and privacy contact addresses will be public. Make sure each one reaches a monitored queue.

Step by step: create and publish the page

These steps follow the Trust Center setup page in Safeguard's docs. Where the docs do not show a screen, this guide describes the outcome rather than inventing one.

1. Open Compliance › Trust Center. This is where the page, and later its access management sections, live.
2. Choose an editor. The docs offer two. Edit Trust Center opens your real public page in a mode where you click any text to change it in place, then save. Advanced settings opens the same content as a form with everything the page has, including logos, the coverage grid, contact details and which policies are listed. Most teams fill in the form first and use the in-place editor for wording later.
3. Set the public slug. This is required and becomes the address: https://<slug>.trust.safeguard.sh. Pick something short and stable, usually your company name, because prospects will bookmark it and paste it into their vendor records.
4. Set the organization name. Also required, shown at the top of the page.
5. Write the headline and description. A short line and two or three sentences under your name that say what your company does and what the page reports. Describe scope, not achievement. "Security and compliance status for our hosted platform, read from continuous monitoring" ages better than a list of claims.
6. Add masthead links. Links shown beside your contact addresses, such as your privacy policy or status page. Each must start with http:// or https://.
7. Set the brand color and logo. A hex color and a logo URL. Safeguard's product page describes the page as yours, with your logo, accent and name in the masthead.
8. Set the security and privacy contact emails. They appear in the page's contact section, the first for vulnerability reports and the second for data subject requests.
9. Choose frameworks. Pick the frameworks to publish. Read the status each one will show, using the table above, and decide whether any framework showing Not assessed should publish its live readiness instead or simply stay off the page for now.
10. Choose published controls. Pick the control areas to show. Remember they are live: a control that starts failing will show as failing.
11. Fill the sections that make reviews shorter. Data collected, FAQ and, if you sell several products, Coverage by offering. If your workspace has the Quick summary, add only highlights that are true today.
12. Publish. In Advanced settings, turn on Publish Trust Center and save. When it is off, the public page returns 404. The docs stress that publishing is always an explicit action: nothing goes live on its own, and new content such as a highlight starts as a draft.
13. Check the live page. Use View public page to open it. Saved changes appear on it, and a framework's live readiness updates within five minutes.

What about my own domain?

Safeguard's Trust Center product page says that publishing at <slug>.trust.safeguard.sh needs no DNS record or certificate step, because a wildcard already covers it, and that you can also point a hostname such as trust.your-domain.com at the service, with a certificate issued once the hostname is authorised. The setup docs do not yet show the custom domain steps, so ask Safeguard support to walk you through it rather than guessing at DNS records.

Is the Trust Center the same as Portal?

Not quite, and the naming is worth getting straight. Portal (GA) means two things in Safeguard: the free entry tier, and the SBOM publish and share product. Safeguard's offering files list the Trust Center alongside the Portal product, and Portal's sharing docs cover sending SBOMs to customers with direct shares, expiring links and a branded customer portal. The Trust Center setup you manage under Compliance › Trust Center is a separate, early access flow. Separately again, the "Portal address" in Trust Center access settings is the sign-in address for approved document viewers, not the Portal product. If you want a deeper look at SBOM distribution, the companion post on publish versus share covers it.

Public versus restricted documents: how access requests and NDA gating work

The documents section is where most of the value sits, because the files reviewers want most, such as a SOC 2 report or a penetration test summary, are the ones you cannot post publicly. Safeguard handles this with restricted documents and an access request flow. Access management is switched on per workspace. When it is on, Compliance › Trust Center has these sections: Page, Access requests, Viewers, Activity, Documents, NDA, Settings and, where switched on, Security contacts.

Add documents

On Documents, choose Add document and set three things.

• Category: Compliance report, Penetration test, Questionnaire, Policy, Privacy, Financial, Security or Other.
• Visibility: anyone can download a Public document; only an approved viewer can download a Restricted one.
• On the public page: whether the document is listed at all.

Each file shows its size and SHA-256. Audit reports come from your audits, so here they can only be shown on or hidden from the public page. One detail is easy to miss: a restricted document listed without a file shows to viewers as not yet available. List a document only once the file is ready.

Set up access requests

The access requests docs give the setup order:

1. Publish your Trust Center.
2. On Documents, add at least one document with Visibility set to Restricted.
3. On NDA, choose Create new version, write the agreement and Publish it. Requesters accept the current version before their request reaches you.
4. On Settings, turn on Access portal. It can be turned on only when the checklist under "Before you turn it on" is complete: Trust Center published, NDA published, at least one restricted document, and sign-in links configured on the server. If that last item is not ticked, the docs say to contact Safeguard support.

The Portal address under Settings is where approved viewers sign in, and Open the portal shows it.

What the visitor sees

1. On your Trust Center, the visitor chooses Request access and gives their first and last name, work email, company, their relationship to you (existing customer, prospective customer, partner, auditor or other) and, optionally, a reason.
2. Under Access, they ask for Full access to every restricted document or Limited access to the documents they choose.
3. They accept the NDA by reading it, ticking the box and typing their full name exactly as entered. Where the customer setting is on, a visitor who says they are an existing customer can request access as a customer and skip the NDA.
4. They receive an email and choose Confirm my email. Only then does the request reach your team. Requests that are never confirmed are deleted automatically after 7 days.
5. Once approved, they get a sign-in link that works once. After signing in they see what they can download and until when, and they can ask for a new link at any time.

Disposable email addresses are refused when the request is sent. If Refuse free email addresses is on in Settings, addresses from free mail providers are refused too.

Decide a request

Open Access requests. Each request shows the requester, NDA acceptance, whether the email was verified, its flags and when it was sent. Flags such as Free email, Always review, Allowlisted, Existing customer, Previously denied, Already a viewer, Access was revoked, Renewal and No NDA on file help a reviewer decide quickly.

Approve asks for three things: the access level (Full, which includes documents added later, or Limited), when access ends (after a number of days, or on a date between one day and two years away), and an optional internal note only your team sees. Deny takes an optional reason, which is emailed only if you choose to email the requester. You can also select several requests and approve or deny them together; a bulk approval gives each requester what they asked for, for your default access length.

Only a compliance reviewer can decide a request. That is deliberate, and it lines up with the approvals rule that Safeguard's AI assistant and MCP clients can draft and submit but never approve.

Auto-approval, and why to start strict

Under Settings › Auto-approval, rules can approve a request without a person, but only after the requester has verified their email and, when you require one, accepted the NDA. The docs give the order in which rules apply:

1. A domain listed under Always review these domains always waits for a person.
2. Allowlisted domains are approved.
3. Existing customer domains are approved.
4. Every verified request approves everyone who confirms their email and accepts the NDA.
5. Any business email approves any address that is not from a free mail provider.
6. Anything else waits for a person.

A domain matches its subdomains too. You also set whether an auto-approved viewer gets what they requested or full access, and a default access length between 1 and 730 days. Where switched on, you can list exact customer email addresses, give matched customers full access, and let customers covered by their agreement skip the NDA. A visitor who claims to be a customer but does not match waits for a person.

A sensible starting point for most teams is an allowlist of existing customer domains, Always review for your competitors' domains, and everything else waiting for a person. "Any business email" is convenient, but it approves anyone with a corporate address, which is a much wider audience than "prospects under NDA."

Manage viewers and keep the audit trail

Viewers lists everyone who can sign in, and everyone who could, filterable by Active, Expiring in 14 days, Expired, Revoked or All. For each viewer you can change the end date or access, send a sign-in link, revoke access (the viewer is signed out at once), restore revoked access until a date you choose, or open their activity. A reminder setting from 0 to 60 days emails viewers before their access expires, and 0 turns it off.

Every step is recorded. A request shows what was asked for, when the email was verified, the decision and its history. The NDA acceptance records the version, the name typed, the time, the IP address and browser, and the agreement's SHA-256, so you can show exactly what was accepted. Activity reports requests, approval rate, median time to decision, active viewers and downloads over 30 days, 90 days or 12 months, and its access log can be exported as CSV. The NDA section lists every version as Draft, Current or Retired with its text hash and a PDF copy; publishing a new version applies to new requests, and existing viewers keep the acceptance they gave.

Under Settings › Notifications you name assignees, who are told about every request (the first one owns its review task), add extra addresses to notify, and decide whether denials are emailed by default.

How do you keep the page in sync with live compliance monitoring?

A trust page that drifts out of date is worse than no page, because a reviewer who finds one stale claim stops trusting the rest. Safeguard's design keeps the page tied to the programme behind it in five ways.

Controls are read live. Each published control area is read from continuous monitoring, so a failing control shows as failing without anyone republishing. That cuts both ways: it is honest, and it means a misconfigured connector or an expired piece of evidence can show up on a public page. Fix the underlying control, not the page.

Live readiness updates within five minutes. For a framework showing Not assessed, Publish live readiness shows the readiness score of your own controls, and Stop publishing live readiness takes it off again. Once continuous tests have completed a check, the page says "Continuously monitored" with the time of the last check. Showing how many tests pass is opt in, and the docs say to ask Safeguard support to turn it on.

The audit outcome follows the auditor. When an auditor records an issued opinion in the audit workspace, it appears under Audit outcome on Compliance › Trust Center. Publishing it shows the opinion type, framework, period and auditor firm, and lists the signed report as available on request through an approved access request. Only a compliance reviewer or administrator can publish or take it down, and the page takes it down by itself when the auditor corrects the opinion or a certificate expires.

Policies and subprocessors come from your registers. When you approve a new policy version or add a vendor, the page reflects your registers rather than a hand-edited list. That still leaves your GDPR Article 28 notice duty with you, as covered above.

Updates reach subscribers. Visitors can subscribe with their email address and are emailed when you publish a change. Where confirmed subscriptions are on, they choose topics (Updates and announcements, or Incidents and security advisories) and confirm by email first. Where security contacts are on, the Security contacts section lists the people your customers named to receive security notifications, and Notify about an update sends a published update to every security contact by email. The docs warn that an email cannot be unsent, so read an incident update twice before you send it.

For the programme side of this, the companion post on continuous compliance in Safeguard covers frameworks, controls, evidence and tests in detail.

How does questionnaire auto-answer work, and what still needs a human?

Safeguard's offering files describe the Trust Center as a public posture page plus questionnaire auto-answer, and describe auto-answering security questionnaires in formats such as SIG and CAIQ. Both sit inside the early access label. The Compliance and GRC suite (GA) also has a Questionnaires area alongside Frameworks, Controls, Evidence, Tests, Policies, Risks, Vendors and Connectors. The Trust Center docs do not yet publish a step by step questionnaire screen, so this section describes the outcome and the limits rather than a click path.

The idea is simple. Most questionnaire rows ask about things your programme already records: which frameworks you work to, whether a control is in place and tested, which policies exist and when they were approved, who your subprocessors are. When those facts live in one system, a first draft of the answers can be assembled from them instead of from last year's spreadsheet.

What still needs a person:

• Every answer before it leaves. A drafted answer is a draft. Safeguard's approvals docs are explicit that its AI assistant and MCP clients can read your programme and prepare changes, but cannot approve, accept, launch or acknowledge anything. Those decisions are made by a person in the app.
• Questions about intent, contracts and commitments. Questions about notification timelines in your contracts, liability, insurance, data residency commitments or roadmap are business and legal answers, not control states.
• Questions where the honest answer is "partly." A yes or no format such as CAIQ pushes toward a clean yes. If a control is in place for one product and not another, write the qualification, even if the format makes that awkward.
• Anything that would contradict the trust page. If a questionnaire answer says a framework is complete and the page shows it In progress, the reviewer will notice. Keep the two consistent.
• Evidence the platform cannot see. The frameworks docs note that some requirements need evidence a scan cannot see, such as an HR record, a policy or an access review, and pass only when a person attests them with evidence.

If your team works in Claude or another assistant, the Safeguard MCP server (GA) can read compliance data and help prepare answers within the access your role allows. Writes wait for your confirmation in that client, and decisions still stay in the app.

What should never go on a public trust page?

The page is public and, according to Safeguard's product page, indexable by search engines. Treat every field as if a competitor, an attacker and a regulator will read it, because all three can.

• Full audit reports. Gate SOC 2 reports and similar detailed reports as restricted documents. The AICPA treats the less detailed SOC 3 as the general use report.
• Full penetration test reports. At most, list that a test happened and offer a summary on request. Unfixed findings in a public file are a gift to an attacker.
• Architecture diagrams with real hostnames, IP ranges or internal service names.
• Credentials of any kind, including test keys or sample tokens in a policy excerpt.
• Customer names or logos, unless each customer has agreed in writing. Safeguard's own product page makes the same choice: it does not list which companies hold a trust center, because that is theirs to disclose.
• Personal data of staff beyond the role addresses you chose to publish. Use a monitored role inbox for the security and privacy contacts, not a named person's address.
• Claims you cannot evidence today. A framework status, a highlight or a FAQ answer that is aspirational. The docs rule for highlights applies everywhere: state only what is true today.
• Certification language a framework does not support. Do not write "certified" for a framework that has no certification, and do not show a pledge as compliance.
• Incident details that are still under investigation beyond what you have confirmed. Use the incident statuses and update the history as facts firm up.
• Draft content. New content starts as a draft for a reason. Review it before it goes out.

What to check before publishing, given the feature is early access

Early access means the feature is real in the product and still maturing. Safeguard's offering files describe early access capabilities as available and expanding, with depth that varies, so plan a short review rather than assuming every option in this guide is on for your workspace.

1. Confirm which sections your workspace has. Quick summary, FAQ categories, incidents, AI governance, confirmed subscriptions, security contacts and the customer access options are all "where switched on." Check which you can see before you promise a stakeholder a feature.
2. Read every framework status aloud. For each one, ask: is this backed by a current audit report or certificate, by live readiness, or by a declaration? Would we defend it in a review?
3. Open each published control area. Is it passing for the right reason? Is any connector behind it disconnected or stale?
4. Check the registers. Is every subprocessor current, with purpose and location? Is every listed policy the approved version?
5. Test the access flow end to end. Request access from an outside address, accept the NDA, confirm the email, approve the request, sign in with the link and download a file. Then revoke and confirm you are signed out.
6. Check auto-approval rules with a test domain. Make sure Always review catches the domains you intended and that "Any business email" is off unless you truly want it.
7. Confirm the contact inboxes are monitored, and that a vulnerability report sent to the security address reaches someone the same day.
8. Have legal read the NDA version and the Data collected section.
9. Check the page logged out, from a browser that has never signed in to Safeguard, so you see what a prospect sees.
10. Decide who owns the page. Name one person who reviews it monthly and after every audit, incident or subprocessor change.

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

The Trust Center is a useful tool for a real problem, and it has clear edges. These are the ones to plan around.

• It is early access and switched on per workspace. So is access management, and several sections are available only where switched on. Do not commit a launch date to a customer until you have confirmed which parts your workspace has.
• It is not an independent attestation. The page shows what you configure and what Safeguard's monitoring can see. A readiness score is not an audit opinion or a certification, and a framework that needs an independent auditor cannot be shown as compliant on a self-assessment. Reviewers will still ask for the auditor's report, and they should.
• It does not perform or replace your audit. Safeguard records an auditor's issued opinion when the auditor enters it, and takes it down when the opinion is corrected or a certificate expires. The audit itself is done by your auditor.
• Restricted documents need a file and an access flow. A restricted document listed without a file shows as not yet available. The access portal will not turn on until the page is published, an NDA is published, at least one restricted document exists and sign-in links are configured on the server.
• It does not write your legal agreements. The NDA text, your DPA and your subprocessor notification process are yours. Publishing a subprocessor list does not by itself meet the active notification duty the EDPB describes under GDPR Article 28.
• Questionnaire answers need human review. Auto-answer drafts; a person signs off. Safeguard's AI assistant and MCP clients cannot approve, accept or sign off on anything.
• It does not decide access requests for you, apart from the auto-approval rules you write. A loose rule such as approving any business email will approve people you did not intend.
• Custom domain setup is not yet documented step by step. The product page describes it; ask support for the steps.
• It does not handle vulnerability intake or incident response. The page shows your security contact and carries incident updates. Running the inbox, triage and response is your process.

Common mistakes

Publishing every framework that is switched on. The library is broad, and publishing a long list of frameworks showing Not assessed or In progress reads as noise. Publish the frameworks your buyers ask about and that you work to.

Treating live readiness as an audit result. It is the readiness of your own controls. Say so in the description, and do not put "compliant" in the headline because a readiness score reached 100 for a framework that needs an auditor.

Listing a restricted document before the file exists. Visitors see "not yet available," request access, and then wait for a file nobody has uploaded.

Turning on "Any business email" on day one. It is the widest automatic rule. Start with allowlisted and existing customer domains.

Using a person's email as the security contact. People go on leave and change jobs. A role inbox survives both.

Forgetting the subprocessor notice duty. A current list on the page is good practice; under Article 28 you still have to tell controllers about intended changes so they can object.

Sending an incident notification in a hurry. Notify about an update cannot be unsent. Have a second person read it.

FAQ

How do I turn on the Safeguard Trust Center?

The Trust Center is early access and switched on per workspace. If you do not see Compliance › Trust Center, ask your Safeguard administrator to enable it. Access management for restricted documents is also switched on per workspace.

What is the Trust Center URL format?

The page is published at https://<slug>.trust.safeguard.sh, where the slug is the public slug you set in the page settings. Safeguard's product page also describes serving it on your own domain; ask support for the steps.

Why does my published Trust Center return a 404?

Publishing is an explicit action. In Advanced settings, turn on Publish Trust Center and save. When it is off, the public page returns 404.

Can I share my SOC 2 report through the Safeguard Trust Center?

Yes, as a restricted document. Add it on Documents with Visibility set to Restricted, publish an NDA, and turn on the access portal. A visitor requests access, accepts the NDA and confirms their email, and a compliance reviewer or one of your auto-approval rules decides the request. Audit reports recorded from your audits can be shown on or hidden from the public page.

How long does approved access to restricted documents last?

You choose. When approving, set access to end after a number of days or on a date between one day and two years away. Auto-approved viewers get your default access length, which can be set from 1 to 730 days. You can change the end date or revoke access at any time.

Does the Trust Center update automatically when a control fails?

Yes. Published control areas are read live from continuous monitoring, so a failing control shows as failing without a republish. A framework's live readiness updates within five minutes.

Is a Compliant status on the Trust Center the same as being certified?

No. Compliant can come from live readiness with every in-scope control passing, from a current audit report or certificate, or from a self-assessment where the framework allows one. Safeguard's docs say a readiness score is not an audit opinion or a certification, and a framework that needs an independent auditor cannot be declared compliant on a self-assessment.

Can an AI assistant approve Trust Center access requests or questionnaire answers?

No. Safeguard's approvals docs say its AI assistant and MCP clients can prepare and submit work but never approve, accept, launch or acknowledge anything. Only a compliance reviewer decides access requests, unless an auto-approval rule you configured decides them.

What should a trust page include for GDPR?

At minimum, a current subprocessor list with purpose and location, a privacy contact for data subject requests, and an honest Data collected section. The page does not replace your DPA or the duty to actively notify controllers of subprocessor changes under Article 28.

Related reading

For the strategy behind trust pages, read how to build a trust center and what a trust center should contain. Smaller teams starting from nothing may find a trust center in the first week for a small SaaS useful, and the Portal trust center post covers the Portal side. In this series, the posts on continuous compliance in Safeguard, publish versus share for SBOMs and supplier software risk with Safeguard TPRM (GA) cover the programme, distribution and buyer sides of the same review.

To try Safeguard, download the apps at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

A trust page shows reviewers how you handle vulnerabilities, and the first follow up question is usually how fast you actually fix them in the open source you ship. The section below is the remediation side of that answer, so the controls your page reports on have something real behind them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to the Safeguard MCP server (GA) with OAuth, and choosing which tools Claude can use. For a Trust Center owner, the same connection lets an assistant read your compliance data and help prepare questionnaire drafts or a page review, while writes wait for your confirmation and approvals stay with people in the app.

Click through it at your own pace, or open it full screen.

The second demo shows the Safeguard desktop app, which is in early access (beta), sending work to a computer running the Safeguard CLI, with each command approved before it runs. It is not a Trust Center screen. It shows the same principle the Trust Center relies on: an assistant can prepare the work, and a named person makes the decision.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard Docs: Trust Center setup
• Safeguard Docs: Trust Center access requests
• Safeguard Docs: Requests and approvals
• Safeguard Docs: Approvals
• Safeguard Docs: Compliance frameworks
• Safeguard Docs: Compliance
• Safeguard Docs: Portal sharing
• Safeguard Docs: Claude MCP integration
• Safeguard: Trust Center product page
• Safeguard: Download
• AICPA and CIMA: SOC 2, SOC for Service Organizations: Trust Services Criteria
• AICPA and CIMA: SOC 3, Trust Services Criteria for General Use Report
• Cloud Security Alliance: STAR Level 1 Security Questionnaire (CAIQ v4.1)
• Cloud Security Alliance: STAR Registry and program
• EDPB: Guidelines 07/2020 on the concepts of controller and processor in the GDPR
• EDPB: Guidelines 07/2020, final version (PDF)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218, Secure Software Development Framework version 1.1
• CISA: Secure by Design Pledge
• IETF RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• Anthropic Help Center: Get started with custom connectors using remote MCP

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.