Claude Enterprise Governance: Policies to Write Before Rollout

Most Claude Enterprise rollouts ship before the policy work is done, and then the rollout team spends the next three months retro-fitting policies onto behaviour that has already set in. The order can be reversed at almost no extra cost if the work is done before licence one is activated. The four policies every Australian organisation needs in writing before activating Claude Enterprise: acceptable use, data classification overlap, human-in-the-loop boundaries, and incident handling.

From running Microsoft 365 and Google Workspace rollouts across Brisbane SMB and government, InnovateX has mapped where Claude Enterprise earns its place alongside Microsoft Copilot and Google Gemini. The policy work is the part that travels the same way regardless of which workspace your organisation runs.

What policies do you need before turning on Claude Enterprise?

Australian organisations rolling out Claude Enterprise need four written policies operating before any non-admin user logs in. Acceptable use sets the boundaries on what content and tasks go through the platform. Data classification overlap maps your existing sensitivity scheme onto Claude’s prompt and output handling. Human-in-the-loop boundaries name which decisions a human must still own. Incident handling defines the response when something goes wrong, before the first something goes wrong.

Why this matters

The legal and audit teams will ask for these policies the day after the rollout. Producing them retroactively forces the team into the awkward position of either documenting current behaviour, which may not be defensible, or restricting current behaviour, which the user community resists. The four policies above are the smallest set that satisfies the Notifiable Data Breaches scheme, the Australian Privacy Principles, and the AI-specific obligations under ISO 42001. They also give the rollout team something concrete to point at when a user asks “can I put this client’s contract into Claude”.

The policies depend on the security baseline covered earlier in this series. This post assumes the security posture is mapped; the policies operationalise it.

The four policies

Acceptable use

The acceptable use policy defines what is and is not a legitimate task for Claude Enterprise inside this organisation. Most templated AUPs ignore the AI-specific cases and need extending.

Permitted tasks cover the work Claude was bought for. Drafting internal analysis, summarising public-domain documents, and code review on internal repositories all sit inside this category.

Tasks needing additional approval cover anything that touches client personal information, anything that goes external to clients without human review, and anything that would feed Claude output into a downstream model.

Never-permitted tasks breach the organisation’s standing duties regardless of context. They include impersonating clients in correspondence and generating content the organisation would not stand behind under its own name.

Pull the AUP from your existing M365 or Workspace policy set and extend it with these cases. Do not write a separate “AI AUP”. A parallel policy tree creates work for the legal team to reconcile later.

Data classification overlap

Your existing data classification scheme, however your organisation names the tiers (Public, Internal, Confidential, Sensitive), needs to map to which classes of data can enter Claude prompts and which cannot. Microsoft Purview labels and Google Vault retention policies enforce classification on documents at rest. Claude Enterprise does not read your tenant’s labels, so the policy has to do the work the labels would have done.

The shortest defensible version of the policy names each tier of your classification scheme, marks which tiers can be uploaded to or pasted into Claude, and notes the controls that catch a paste of a higher tier (DLP rules on the endpoint, prompt-time disclaimers in the Claude client, and audit-log review).

For ISO 42001 organisations the data classification overlap is also where your AI management system documents the input boundary for the AI subsystem. Two policies, one document.

Human-in-the-loop boundaries

Claude is good at drafting. Drafting is not the same as deciding. Human-in-the-loop boundaries name the decisions that a person must still own, even when Claude has produced an end-to-end version of the work.

Three categories cover most organisations. Client-facing communications go through human review before they leave the organisation. Decisions with legal, financial, or regulatory weight (procurement choices, hiring decisions, advice to clients) have a named human as the accountable owner, with Claude framed as a research and drafting assistant. Decisions that affect a single person without their consent (performance write-ups, access denials, eligibility determinations) follow the same rule.

The policy does not need to enumerate every case. It needs to name the principle and the categories, and to be reachable from the AUP.

Incident handling

Something will go wrong. A user will paste a client’s personal information into a prompt. Claude will produce output that the organisation would not want printed in a newspaper. The audit log will surface a pattern of use that the security team did not expect.

Incident handling defines who finds out, how fast, and what they do. The shortest version maps to the existing Notifiable Data Breaches response plan and adds three Claude-specific steps. Suspend the affected user’s Claude access via the admin portal. Preserve the relevant audit-log slice. Trigger the post-incident review against the AUP and the data classification policy.

For organisations on the ISO 27001 or ISO 42001 track, this is the AI-specific extension of the existing security incident response procedure. Not a new procedure.

Common mistakes

Writing the AI AUP as a separate document. A parallel policy tree is a reconciliation problem waiting for a legal team to discover it. Extend the existing AUP, do not fork it.

Skipping data classification overlap because “we already have Purview”. Purview labels live on documents, not in Claude prompts. The policy has to fill that gap.

Treating human-in-the-loop as a slogan instead of a list. “A human reviews everything” is not a policy. “Client-facing communications go through named-human review before they leave the organisation” is a policy.

Inventing a new incident response plan. Extend the NDB response with three Claude-specific steps. Do not write a parallel runbook the on-call team will not remember exists.

What to do this week

You can have a defensible first draft of these four policies on the page by Friday if you start Monday. The work splits into three pieces.

Pull the existing policies first. AUP, data classification, NDB response, and any AI-specific governance document already in flight. Most organisations have three of the four sitting in OneDrive or Drive.

Mark the gaps next. Where do the existing policies fall silent on Claude or AI? That is the extension brief. Most extensions are two to five paragraphs each.

Then draft and circulate. Send to legal and the CISO with a one-week comment window, iterate, sign, and activate before licence one.

Our AI Readiness Assessment covers the four-policy review as part of the standard pre-rollout package, with templates calibrated for Australian organisations on Essential Eight, SMB1001, ISO 27001, or ISO 42001.

Where InnovateX comes in

We draft the four policies in a working session with the legal, security, and operations leads. Australian-specific, framework-aware, and short enough that the people using Claude will read them. The output is a versioned, signed policy pack that satisfies the auditor and the rollout team simultaneously.

For organisations where AI policy is one symptom of a wider AI governance gap (no AI charter, no AI risk register, no senior owner of the AI agenda), a Fractional Chief AI Officer retainer carries this work on an ongoing basis rather than as a one-off engagement. The pillar on Fractional CAIO services for Australian SMBs covers when the retainer model makes sense.

This post is part of the Adopting Claude Enterprise series. The next post walks through the 90-day rollout plan for Microsoft 365 organisations, with the day-90 measurement covered later in the measurement scorecard post.