checklist

AI trust center checklist for small teams

A practical checklist for building a customer-facing AI trust center page that explains approved tools, customer data rules, vendor review, retention, incidents, and evidence without over-claiming.

Use this checklist to create a customer-facing AI trust center page before customer security reviews become a sales bottleneck.

A small team does not need to pretend it has an enterprise trust portal. It does need one clear page that explains how AI tools are approved, what customer data rules apply, who owns reviews, how connectors and meeting bots are controlled, how evidence is maintained, and where the limits are. If a tool or workflow is not already approved, run the AI Tool Risk Checker before adding it to the page.

Bottom line

An AI trust center page should answer five customer questions:

1. What AI tools do you use?
2. What customer data can those tools access?
3. Who approves and reviews AI tools?
4. How do you handle retention, deletion, access, connectors, browser extensions, and meeting bots?
5. What proof can you share without exposing private records?

Do not use a trust page to make broad promises. Use it to publish accurate, dated, customer-safe summaries backed by internal evidence. The Small Team AI Security Checklist is the baseline control set behind the page.

When to build this page

Signal	Build now?	Reason
Customers ask whether employees use ChatGPT, Claude, Cursor, Copilot, meeting bots, or AI browser extensions	Yes	Repeated AI questions should become reusable approved language.
Sales sends one-off security answers by email	Yes	A dated page reduces inconsistent answers.
Procurement asks for an AI policy or security questionnaire	Yes	The trust page becomes the table of contents for evidence.
You are adding a paid product, consulting offer, or customer-facing AI workflow	Yes	Buyers will want to understand data handling and control ownership.
You have no approved tool inventory	Not yet	Create the inventory first.
You cannot explain customer data handling by tool	Not yet	The page would create more risk than trust.
You want to imply SOC 2, ISO, HIPAA, PCI, or legal assurance without having it	No	Do not publish unsupported assurance language.

If the page would contain guesswork, stop and complete the inventory, policy, and review records first.

Trust page map

Section	What to publish	Evidence behind it
Scope	Which product, team, region, data classes, and workflows the page covers.	Product scope note and data classification table.
Approved AI tools	Tool name, purpose, owner, approved users, approved data classes, and review date.	Approved AI tool inventory.
Customer data rules	What can be entered, uploaded, synced, transcribed, summarized, or prohibited.	Customer data approval records and policy.
Vendor review	How AI vendors are reviewed and how often.	Vendor review packet and renewal records.
Access and admin controls	Who can administer tools and how access is reviewed.	Access review record and admin setting screenshots.
Connectors and OAuth	Which source systems can connect to AI tools and who approves them.	Connector register and source-system owner approval.
Browser extensions	How AI extensions are reviewed for permissions and host access.	Browser extension allowlist and review evidence.
Meeting bots	Consent, transcript location, sharing rules, and retention.	Meeting bot approval and transcript retention rules.
Developer AI tools	Repository scope, code context rules, terminal use, and review owner.	Developer AI tool inventory and engineering policy.
Retention and deletion	How long governance evidence and AI-related records are kept.	Evidence retention schedule.
Incidents and escalation	How suspected AI tool incidents are reported, investigated, and closed.	Incident response and remediation workflow.
Evidence sharing	What redacted evidence can be shared with customers.	Customer evidence package.
Limitations	What certifications, audits, or controls you do not claim.	Leadership-approved limitation statement.

Keep the public page concise. Link deeper artifacts only when they are customer-safe.

Customer-safe copy blocks

Use these copy blocks as a starting point, then replace placeholders with your actual facts.

Block	Draft text
AI tool use	”Our team uses approved AI tools for approved business workflows. Each approved tool has an owner, approved use cases, approved data classes, and a review date.”
Customer data	”Customer data may be used with AI tools only when the tool, workflow, data class, and vendor terms have been approved. Sensitive or regulated data requires explicit owner review.”
Model training	”Our AI tool policy prohibits using customer data in workflows or settings that allow public model training unless that data class and workflow have been explicitly approved.”
Connectors	”AI connectors require source-system owner approval, scope review, and periodic access review before production use.”
Meeting bots	”Meeting bots require participant notice, transcript storage rules, sharing limits, retention rules, and owner approval before use.”
Browser extensions	”AI browser extensions are reviewed for permissions, host access, data access, vendor posture, deployment scope, and update risk before approval.”
Developer AI	”Developer AI tools require repository scope rules, code context rules, sensitive file restrictions, and owner review before production use.”
Incidents	”Suspected AI tool incidents are routed to the responsible owner for containment, scope review, customer impact assessment, remediation, and closure evidence.”
Evidence	”Customers may request redacted control summaries, dated review records, or redacted screenshots appropriate to the request scope.”
Limitations	”This page describes our current internal controls and does not represent a third-party audit, certification, legal opinion, or compliance guarantee.”

Do not publish a copy block until the evidence behind it exists.

Evidence table

Public claim	Minimum internal evidence
”Approved AI tools are reviewed”	Tool inventory with owner, approval date, review date, and decision.
”Customer data is restricted”	Data classification table and approved-use matrix.
”Connectors require approval”	Connector register with source system, scope, owner, and review date.
”Meeting bots have consent and retention rules”	Meeting bot policy, notice language, transcript location, sharing rule, and deletion cadence.
”Browser extensions are reviewed”	Extension ID, permission review, host access review, deployment scope, and owner.
”Developer AI has code context rules”	Developer AI inventory, repository scope, sensitive file rule, and review date.
”Access is reviewed”	Monthly or quarterly access review record.
”Incidents are handled”	Incident intake route, severity rules, containment checklist, remediation plan, and closure record.
”Evidence can be shared”	Redacted evidence package and approval workflow.
”Limitations are disclosed”	Approved limitation statement and list of unsupported claims.

Evidence should be dated. Stale trust pages create more risk than missing trust pages.

What not to publish

Do not publish:

1. Raw customer records, support tickets, transcripts, meeting recordings, prompts, code, or logs.
2. Full user directories, admin exports, private screenshots, internal IPs, account IDs, or vendor dashboard URLs.
3. Credentials, private keys, recovery codes, billing details, tax data, payout data, or private applicant information.
4. Unreviewed incident details, suspected customer impact, or unresolved security findings.
5. Vendor claims copied from marketing pages without checking current terms and settings.
6. Certifications, attestations, or compliance guarantees you do not have.
7. Future roadmap promises that sound like current controls.
8. Customer names, logos, or data examples without permission.

When in doubt, publish a summary and keep the raw evidence internal.

Update cadence

Trigger	Update the page?	What to check
New AI tool approved	Yes	Tool owner, use case, data class, vendor review, access, and retention.
AI connector added or removed	Yes	Source system, scope, owner, and review date.
Meeting bot policy changes	Yes	Notice, recording consent, transcript location, sharing, and retention.
Browser extension allowlist changes	Yes	Permissions, host access, deployment scope, and owner.
Developer AI tool scope changes	Yes	Repository scope, sensitive file rule, terminal use, and owner review.
Vendor terms or admin settings change	Yes	Model training, data retention, subprocessors, export, and access controls.
Customer questionnaire exposes a gap	Yes	Add limitation or update control evidence after remediation.
Incident, rollback, or remediation closes	Maybe	Update only customer-safe process language, not raw incident details.
Quarterly review completed	Yes	Last reviewed date and outdated statements.

Assign one owner for page accuracy. Do not let sales, marketing, and security maintain separate versions.

Approval workflow

1. Draft the trust page from the current evidence packet.
2. Mark every claim as public, customer-under-NDA, internal only, or do-not-share.
3. Verify each claim against the current tool inventory, data rules, vendor review, and access review.
4. Send customer data, legal, regulated data, incident, and certification language to the right owner.
5. Remove unsupported assurance language.
6. Publish only customer-safe summaries.
7. Save the published URL, date, approver, and source evidence.
8. Add the page to your customer questionnaire response workflow.
9. Review the page after every AI vendor or workflow change.
10. Re-run the AI Tool Risk Checker for any newly disclosed workflow.

A trust page is part of operations. Treat it like a control record, not a marketing page.

Redaction checklist

Before publishing or sharing evidence, remove:

Evidence type	Redact
Admin screenshots	User emails, account IDs, workspace IDs, billing details, unrelated app grants, hidden settings, and private URLs.
Access review records	Full employee directory, private HR fields, disabled-user details beyond the review result, and unrelated systems.
Connector records	Private app IDs, token-like values, full permission exports, unrelated source systems, and private tenant identifiers.
Meeting bot records	Participant names, transcript text, customer names, recordings, calendar details, and private meeting links.
Browser extension records	Browser history, employee browsing data, unrelated extensions, and private policy console details.
Developer AI records	Source code, repository secrets, private file paths, infrastructure names, and internal incident references.
Incident evidence	Raw timelines, customer identifiers, suspected impact notes, and unreviewed remediation details.

Keep a private original only when policy, contract, legal hold, or incident response requires it.

Readiness score

Score each item before publishing.

Control	0 points	1 point	2 points
Tool inventory	Missing	Partial list	Approved list with owners and review dates
Customer data rules	Missing	Generic rule	Data-class-specific rule
Vendor review	Missing	One-time review	Review packet plus cadence
Access review	Missing	Informal	Dated review with owner and findings
Connectors	Missing	Known by admin only	Register with scope and source owner
Meeting bots	Missing	Tool rule only	Consent, sharing, location, and retention rules
Browser extensions	Missing	User choice	Allowlist and permission review
Developer AI	Missing	Verbal rule	Repository and code context policy
Incident process	Missing	Generic escalation	AI-specific intake, containment, and closure
Evidence sharing	Missing	Ad hoc	Redacted customer evidence package

Publish a public AI trust page when the score is 14 or higher. If the score is below 14, publish only a short security contact note and fix the evidence gaps first.

Customer request routing

Request	Route to	Default response
”Send your AI policy”	Operations or security owner	Share the public summary or customer-safe policy excerpt.
”List all AI subprocessors”	Vendor review owner and legal reviewer	Share only current, reviewed vendor and subprocessor information.
”Prove our data was deleted”	Data owner and legal reviewer	Use approved deletion evidence, not raw system exports.
”Send admin screenshots”	Workspace admin and security owner	Provide redacted settings evidence when appropriate.
”Confirm no AI model training”	Tool owner and data owner	Answer by tool, setting, data class, and workflow.
”Describe an incident”	Security owner and business owner	Escalate before disclosing any customer impact language.
”Sign security terms”	Business owner and legal reviewer	Do not answer from the trust page alone.

Record customer follow-up questions. They show which trust page sections need clearer wording.

Metrics to track

Metric	Why it matters
Trust page visits	Shows whether customers use the page before asking questions.
Questionnaire volume	Shows whether the page reduces repeated manual work.
Average security review response time	Measures sales friction.
Repeated unanswered questions	Identifies missing content.
Evidence requests by type	Shows which proof customers actually need.
Page updates per quarter	Shows whether the page is maintained.
Controls changed after customer questions	Turns trust work into better operations.
Deals delayed by AI security review	Helps prioritize deeper evidence or a formal trust center.

If the same question appears three times, add a customer-safe answer block.

Evidence checked

This checklist is aligned with:

1. NIST AI Risk Management Framework, which frames AI risk management around governance, mapping, measuring, and managing AI risk.
2. NIST Cybersecurity Framework FAQ, which describes CSF 2.0 governance and stakeholder communication outcomes.
3. NIST Privacy Framework getting started guidance, which links privacy risk management to trust, communication, and the full data lifecycle.
4. Cloud Security Alliance CAIQ explainer, which describes CAIQ as a questionnaire for transparency and assurance rather than a certification.
5. Cybergiz templates for AI tool inventory, security questionnaires, access review, evidence retention, vendor review, connector review, browser extension review, meeting bot rules, developer AI rules, and incident response.

This page is not legal, procurement, compliance, audit, or certification advice.

FAQ

Is an AI trust center page the same as a SOC 2 report?

No. A trust page is a customer-facing summary. A SOC 2 report is a third-party attestation. Do not make the page sound like an audit report if no audit exists.

Should a small team publish every AI tool it uses?

Publish the approved tools that are relevant to customer data, production workflows, support, engineering, meetings, or customer-facing operations. Keep experimental or internal-only tools out of the public page until reviewed.

Can this page replace security questionnaires?

Usually no. It can reduce repetitive questions and serve as the source for approved answers, but customers may still require their own questionnaire, contract terms, or evidence review.

Should the trust page be public or shared only with customers?

Start public if the content is high-level and customer-safe. Keep sensitive evidence, detailed screenshots, and customer-specific responses behind a reviewed request process.

What if a customer asks for a certification we do not have?

Say that you do not currently claim that certification, then describe the specific controls you do maintain. Do not imply certification through wording like “aligned with” unless the scope and evidence are clear.

How often should the page be reviewed?

Review it quarterly and after every new AI tool, connector, meeting bot workflow, developer AI scope change, vendor terms change, incident, or customer questionnaire gap.