Pre-Launch Governance Checklist
Why this list exists
Most organisations that run into problems with AI deployments do not fail because of the technology. They fail because governance was skipped or deferred: a policy that was "going to be written next month," an escalation path that was "common sense," a second admin account that was "not urgent."
This checklist is the minimum viable governance layer. Do not open Claude Enterprise to your broader organisation until every item is done. Each item exists because something went wrong at an organisation that skipped it.
Item 1: Acceptable-use policy published
What it is: A written document — even a single page — that tells every employee:
- What they are allowed to use Claude for
- What they are not allowed to do
- What to do when something goes wrong
What it must cover:
Approved use cases
Be specific. "Use Claude for work tasks" is not a policy. Examples of useful specificity:
✓ Drafting and editing internal documents, emails, reports and presentations
✓ Summarising meeting notes and research
✓ Writing and reviewing code (internal projects only)
✓ First-pass analysis of non-confidential data
✓ Learning and professional development
Prohibited data types
Name the categories explicitly. Do not assume employees will intuit them:
✗ Customer personal data (names, addresses, financial details, health information)
✗ Unpublished financial results or material non-public information
✗ Passwords, API keys or security credentials
✗ Details of pending litigation, regulatory investigations or legal proceedings
✗ Personal employee records (performance reviews, salary, disciplinary notes)
✗ Patient data of any kind
What to do when Claude produces a wrong or harmful output
This is the section most policies omit. Cover three cases:
Factual error: "If Claude provides information you are using to make a decision, verify it from an authoritative source before acting. Claude can be wrong. Do not present Claude's output as fact without verifying."
Potentially harmful output: "If Claude produces output that is offensive, discriminatory, legally problematic or otherwise inappropriate, do not use it. Report it immediately using [the feedback channel — see Item 4]."
Output shared externally: "Any AI-assisted content sent to clients, regulators or the public must be reviewed and approved by a qualified human before sending. You are responsible for the content of anything you send."
Where to publish it: Your intranet, the onboarding materials sent to new Claude users, and the Project system prompts of any Project where the policy is particularly relevant.
Item 2: Security configuration complete
Confirm all four settings are in place before inviting users:
| Setting | Required state | Where to set |
|---|---|---|
| SSO / SAML | Live and tested, or deliberately waived | Admin Console → Identity (SSO) |
| Two-factor authentication | Enforced for all non-SSO users | Admin Console → Security → 2FA |
| Session duration | Aligned to your IT security policy (typically 8–24 hours) | Admin Console → Security → Session |
| Admin accounts | Minimum two admins active | Admin Console → Members |
Test SSO before launch. Do not turn on SSO enforcement until you have successfully logged in via the SSO flow at least twice from two different accounts. A misconfigured SSO at launch locks everyone out simultaneously.
2FA and SSO interaction: users who authenticate via SSO do not need 2FA enforced in Claude — their IdP handles it. Enforce 2FA only for non-SSO users (e.g., contractors, external collaborators who do not have corporate IdP accounts).
Item 3: Training opt-out confirmed
Enterprise contracts opt out of Anthropic using your organisation's data for model training by default. This is a contractual guarantee, but you must verify it is active in your console and document it for your compliance record.
How to verify:
- Admin Console → Privacy & Data (or Settings → Data controls, depending on your console version)
- Find the model training section
- Confirm it shows "Off" or "Opted out" or equivalent
- Take a screenshot
Why document it: your DPO (Data Protection Officer), legal team or enterprise clients may ask whether your AI tool uses company data for training. A screenshot with a date is the evidence that answers that question in 30 seconds rather than requiring a contract review.
Store it: compliance file, shared with your DPO. Add it to your annual review cycle — confirm it is still active after any contract renewal or plan upgrade.
Item 4: At least two admins
A single-admin organisation has a single point of failure. If that admin account is:
- Compromised and locked out
- Held by an employee who leaves
- Lost access due to email/IdP changes during an IT migration
...the organisation loses all administrative access until Anthropic support can intervene. This can take days.
The rule: minimum two admins, from two different corporate email accounts, verified as active before launch.
Choosing the second admin: not the IT manager's personal assistant. Not the most senior person available. The right second admin is someone who:
- Will actually be reachable in a crisis (different timezone is a bonus)
- Understands what Claude Enterprise is and what the Admin Console does
- Can make governance decisions (suspend a user, pull a Project) without needing approval for every action
Document the admins: name, email, role, and phone number in your AI governance register. Review quarterly — if one leaves the organisation, appoint a replacement before revoking access.
Item 5: Feedback channel open
Your users will discover things about how Claude behaves in your organisation that you could not anticipate. Some will be useful (a workflow that works exceptionally well). Some will be concerning (Claude giving confident but wrong legal advice, or producing output with an inappropriate tone).
Without a feedback channel, you hear about neither. The good stays siloed. The bad escalates into an incident.
What to create: a Slack channel, email alias or web form. It does not need to be sophisticated. A channel called #claude-feedback with a pinned message saying "Post here if Claude produces something wrong, harmful or useful" is enough.
What to tell users: mention the channel in every onboarding session. Include it in the acceptable-use policy. Put it in the Project system prompt: "If Claude produces unhelpful or inappropriate output, report it at [channel]."
What to do with feedback:
- Review the channel at least weekly
- Categorise reports: factual errors, tone/appropriateness concerns, system prompt issues, feature requests
- Act on patterns: three reports of the same factual error in the Legal Project means the system prompt or knowledge files need updating
- Close the loop: reply to reporters so they know it was seen and acted on (or not, and why)
Who owns it: name a specific person — not "the IT team." An unnamed owner means no owner.
Item 6: Escalation path defined
Before an incident, not after. The question is not whether Claude will produce a harmful output — it will, eventually. The question is what happens next.
Write down answers to these questions:
If Claude produces harmful output that reaches a client or external party:
Who is notified first? (typically: the employee's manager + the AI governance owner)
Who assesses the severity? (legal counsel, DPO, or a named senior leader)
Who has authority to pause usage? (this person must be reachable 24/7 if you operate globally — do not name someone who is unreachable on weekends)
What is the pause mechanism? (Admin Console → can an admin deactivate the relevant user or Project immediately? Test this before launch.)
Is there a regulatory notification obligation? (if PII was involved in the output, GDPR Article 33 may require notifying your supervisory authority within 72 hours — your DPO should advise)
Template escalation path
| Trigger | Notify | Within |
|---|---|---|
| Harmful output reaches external party | Manager + AI governance owner | 1 hour |
| Factual error causes business decision | AI governance owner | Same day |
| Suspected data policy breach | DPO | 2 hours |
| User reports inappropriate output | Feedback channel owner | 48 hours |
| System-wide anomaly (Claude behaving unexpectedly for all users) | IT lead + Anthropic support | Immediate |
Write this down. A verbal understanding is not an escalation path. A Confluence page, a section of the AUP, or a shared doc in the governance folder — any written form is sufficient.
The launch-readiness sign-off
Before inviting your first non-pilot user, confirm each item:
| # | Item | Owner | Status | Date confirmed |
|---|---|---|---|---|
| 1 | AUP published and accessible | ☐ | ||
| 2 | Security config complete (SSO/2FA/session) | ☐ | ||
| 3 | Training opt-out screenshot in compliance file | ☐ | ||
| 4 | Two active admins verified | ☐ | ||
| 5 | Feedback channel live, owner named | ☐ | ||
| 6 | Escalation path written and shared | ☐ |
When all six are checked, you are ready to launch. Not before.
Key takeaway
Governance is not a bureaucratic overhead on top of the deployment — it is the thing that makes the deployment sustainable. An organisation that launches without these six items will spend far more time firefighting problems than the 4–6 hours it takes to complete this list. Do it once, do it before launch, and revisit it annually.
📖 Official Documentation See this in practice in Anthropic's live support docs: