CCAOF-D6.2 · Domain 6 · Governance, Risk & Responsible Use · 15% of CCA-A

Following Organizational AI Governance Policy.

8 min read·7 sections·Tier A

Following your organization's AI governance is an employee-level checklist run before acting: is this data class allowed here, is this use case approved, does this output need review before it ships, and - when any of that is unclear - who do you escalate to before proceeding. That policy layer is separate from Anthropic's own model-level safeguards; Anthropic's Responsible Scaling Policy governs how Anthropic scales its own models, not whether your specific use of Claude with specific data is compliant. Anthropic RSP v3.4 Enterprise admin tooling also makes usage inside the sanctioned workspace reviewable after the fact, so working outside it, or sitting on a discovered gap instead of reporting it, is the actual risk, not a technicality.

Official Anthropic RSP + Compliance API docsCCA-A Domain 6 · GovernanceCCA-A only
Following Organizational AI Governance Policy, hero illustration featuring Loop mascot in a warm gallery scene.
Domain CCAOF-D6Governance, Risk & Responsible Use · 15%
On this page
01 · Summary

TLDR

Following your organization's AI governance is an employee-level checklist run before acting: is this data class allowed here, is this use case approved, does this output need review before it ships, and - when any of that is unclear - who do you escalate to before proceeding. That policy layer is separate from Anthropic's own model-level safeguards; Anthropic's Responsible Scaling Policy governs how Anthropic scales its own models, not whether your specific use of Claude with specific data is compliant. Anthropic RSP v3.4 Enterprise admin tooling also makes usage inside the sanctioned workspace reviewable after the fact, so working outside it, or sitting on a discovered gap instead of reporting it, is the actual risk, not a technicality.

2 (vendor + org)
Governance layers
CCAOF-D6
Exam domain
15%
Domain weight
3 (data, use case, review)
Employee pre-action checks
Escalate, don't decide alone
When unclear
02 · Definition

What it is

An Associate-level Claude user does not set AI policy, they operate inside one their employer already has, or should have: rules on what data can be pasted into Claude, which use cases are approved, who reviews AI-assisted work before it ships, and how usage gets audited afterward. Governance, at this level, is two layered things stacked on top of each other. The first is Anthropic's own vendor-level safety framework, how Anthropic itself scales and safeguards its models. The second is the organization's own admin controls and internal policy, layered on top when a company deploys Claude to its employees.

The two layers answer different questions. Anthropic's layer answers whether a model is safe to keep scaling; it does not answer whether a specific employee's use of a specific customer's data, inside a specific company's Claude deployment, satisfies that company's own data-handling rules. That second question belongs to the organization, and the associate's job is to follow the answer, not assume the vendor layer already covers it. Once a company enables audit tooling on its Claude deployment, usage inside the sanctioned workspace also becomes reviewable after the fact, which changes what "following policy" means in practice, from a trust exercise into something that can be checked.

03 · Mechanics

How it works

What actually falls to the employee, day to day, is a short checklist, run before acting, not after. Before pasting data: is this data class (customer PII, financial records, unreleased material) allowed in this tool under company policy, and am I inside the company's sanctioned workspace rather than a personal account? Before adopting Claude for a new workflow: is this use case on the approved list, or does it need sign-off first, even if the task looks obviously low-risk? Before shipping AI-assisted output externally: does this specific output type require a human reviewer's sign-off, and has that review actually happened? None of this requires understanding admin tooling or vendor-level safety frameworks, it requires checking the answer against the org's own policy before proceeding, not after.

When the answer isn't clear, escalate before proceeding, don't decide alone. "This use case seems fine to me" is not a substitute for approval, and guessing at a data-handling rule is not the same as confirming it. The standard escalation path is: check the written policy first, then raise it with the designated policy owner, AI governance lead, or compliance/legal contact your org names for exactly this - before running the task, not after. The same path applies in reverse: if you spot a gap (a use case running without approval, PII that reached an unsanctioned account, an AI-assisted output that shipped without required review), report it promptly through that same channel rather than quietly self-correcting and moving on; governance depends on gaps being surfaced, not smoothed over.

This is layered underneath two things an employee doesn't operate, but should recognize as separate from their own responsibility. Anthropic's own Responsible Scaling Policy (RSP) governs how Anthropic itself trains and scales its models, it is vendor-level and says nothing about whether a specific employee's use of specific data satisfies the company's own rules. Separately, an org's admin/security team enforces its policy technically, not just in writing, through Enterprise-tier tooling (audit access to usage, spend controls, role-scoped admin access), which means work done inside the sanctioned workspace is reviewable after the fact even without any complaint being filed. Neither of these is something an employee configures, but both are reasons "no one will notice" is a bad assumption, and why escalating a concern yourself is safer than hoping it goes unnoticed.

Most companies' internal policy structure echoes a recognizable pattern - NIST's AI Risk Management Framework (Govern, Map, Measure, Manage) - even if no one calls it that. Use-case approval is a Map step (classify the risk before deployment); required review before shipping is a Measure step; an escalation channel for gaps or mistakes is a Manage step. Recognizing the pattern explains why a policy asks for approval or review at all, rather than treating either as arbitrary friction, but an associate's job is following the steps, not designing the framework.

Following Organizational AI Governance Policy mechanics, painterly diagram featuring Loop mascot.
04 · In production

Where you'll see it

Marketing associate summarizing customer feedback

Checks whether customer PII is allowed in Claude under company policy and routes the task through an approved Project or workspace instead of a personal account before pasting a complaints spreadsheet.

Enterprise security team

Reviews audit-accessible usage logs to confirm AI-assisted work followed the required human-review step before it shipped externally - work outside the sanctioned workspace is a visible gap, not a hidden one.

Associate unsure about a new workflow

Checks the written policy, doesn't find a clear answer, and escalates to the org's named AI governance/compliance contact before running the task rather than guessing based on how low-risk it looks.

05 · When to use

Decision tree

01

Does the data you are about to paste into Claude include customer PII or other regulated data?

YesCheck whether your organization's policy allows this data class in this tool, or route the task through an approved Project or workspace instead of a personal account.
NoProceed, but confirm the use case itself is approved before continuing.
02

Is this use case on your organization's approved-use list?

YesProceed under the normal workflow.
NoGet sign-off before using Claude for it, even if the output looks harmless, an unapproved use case is a policy gap, not a technical one.
03

Does the output need human review before it ships externally?

YesRoute it through the required reviewer before sharing, this is a governance control, not an optional quality step.
NoShip it, but remember usage may still be audited afterward if Compliance API access is enabled on your org's deployment.
04

Are you working inside the company's sanctioned Claude workspace rather than a personal account?

YesYour usage is potentially auditable after the fact, working inside policy is both required and visible.
NoThis is itself a policy violation in most organizations, independent of what you actually did with the tool.
05

Are you genuinely unsure whether a data class, use case, or output is covered by policy, or did you discover a gap (unapproved use, misrouted data, a review step that got skipped)?

YesEscalate to your org's designated policy owner or compliance/legal contact before proceeding (or immediately after discovering the gap) - don't decide unilaterally and don't quietly self-correct a discovered gap without reporting it.
NoProceed under the checklist above; no escalation needed for a clear-cut case.
06 · On the exam

Question patterns

Following Organizational AI Governance Policy exam trap, painterly cautionary scene featuring Loop mascot.
An employee argues that because Anthropic publishes a Responsible Scaling Policy, their company's use of Claude with customer financial records is automatically compliant with the company's own data-handling rules. Is this reasoning correct?
No. The RSP governs how Anthropic scales and safeguards its own models, it says nothing about whether a specific company's use of a specific data set satisfies that company's own regulatory or data-handling obligations. The distractor "the RSP covers our compliance obligations too" conflates vendor-level model safety with org-level usage governance, two separate layers this objective tests separately.
A sales associate wants to paste a spreadsheet of customer complaints into their personal Claude account to draft a summary for an exec deck. What should they check first?
Whether an approved Project or workspace exists for this use case, and whether customer PII is allowed in it under company policy, not whether the output looks fine. The distractor "it is fine since Claude does not retain data by default" skips the actual question this objective tests: whether this org's policy permits this data class in this tool, regardless of any vendor-level retention default.
An employee uses an unsanctioned personal Claude account for a work task instead of the company's sanctioned workspace, reasoning that if the output is good, no one will know. What is wrong with that reasoning?
Work done inside a company's sanctioned Claude workspace is potentially auditable after the fact through Enterprise-tier admin tooling, so working outside it isn't hidden by being unaudited, it's a separate, more serious policy violation regardless of output quality. Since it was avoidable, the right move once realized is to flag it to the policy owner rather than let it stand unreported. The distractor "quality output means no one checks how it was produced" ignores that governance is about process, not just outcome.
A new associate isn't sure whether a task they're about to run counts as an "approved use case" under company policy, and their manager is unavailable. What should they do?
Check the written policy first, and if it doesn't resolve the question, escalate to the org's designated policy owner or compliance/legal contact before running the task, waiting for their manager specifically isn't required if another named escalation path exists. The distractor "proceed since the task seems low-risk and ask forgiveness later if needed" substitutes individual judgment for the organization's defined approval process, exactly what following governance means avoiding.
A new associate is told their company's AI policy requires use-case approval before deploying Claude to a new workflow, and finds this frustrating since the workflow seems obviously safe. What is the best way to understand why this step exists?
Use-case approval functions like the Map step in a governance framework such as NIST's AI RMF, identifying and classifying risk before deployment, independent of any one employee's judgment that a use case is "obviously safe." The distractor "skip approval since the task is low-risk in my judgment" substitutes individual judgment for the organization's defined process, exactly what following organizational governance means avoiding.
07 · FAQ

Frequently asked

Does Anthropic's Responsible Scaling Policy mean my company's Claude usage is automatically compliant?
No. The RSP governs how Anthropic scales and safeguards its own models. Whether your company's specific use of Claude with specific data satisfies your company's own regulatory or data-handling obligations is a separate, organization-level question.
How does a company actually enforce its AI policy, not just write it down?
Through product-level admin controls on Claude Enterprise (audit access to usage, spend approval workflows, role-scoped admin access) - technical enforcement rather than a document employees are trusted to remember. As an employee this mainly means: usage inside the sanctioned workspace is potentially reviewable after the fact.
I'm not sure whether a task or data class is covered by policy. What should I do?
Check the written policy first. If that doesn't resolve it, escalate to your org's designated policy owner, AI governance lead, or compliance/legal contact before proceeding - don't decide unilaterally based on your own risk judgment, and don't wait for a specific manager if another named escalation path is available.
I discovered a governance gap (unapproved use case, misrouted data, a skipped review step). Should I quietly fix it myself?
No - report it through the same escalation channel you'd use for a question, promptly. Governance depends on gaps being surfaced and tracked, not silently self-corrected, even when the fix seems obvious.
08 · Practice with AI

Work this with your AI

Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.

  • Drill it like the exam (scenario MCQs)
    Practice in the exam's scenario-MCQ format with trap awareness.
  • Explain it back (Feynman)
    Build durable, transferable understanding of a concept you can half-state.
  • Test me, adapting the difficulty
    Active recall practice on a concept you think you know.
  • Check my prerequisites first
    Before studying a concept that keeps not sticking.
  • Find the high-leverage 20%
    When a domain feels too big and you are short on time.
Self-check

Test yourself

Three diagnostic questions on this primitive. Reveal each answer when you have a guess. Want a full 60-question mock? Open the mock hub →

Q1An employee argues that because Anthropic publishes a Responsible Scaling Policy, their company's use of Claude with customer financial records is automatically compliant with the company's own data-handling rules. Is this reasoning correct?
No. The RSP governs how Anthropic scales and safeguards its own models, it says nothing about whether a specific company's use of a specific data set satisfies that company's own regulatory or data-handling obligations. The distractor "the RSP covers our compliance obligations too" conflates vendor-level model safety with org-level usage governance, two separate layers this objective tests separately.
Q2A sales associate wants to paste a spreadsheet of customer complaints into their personal Claude account to draft a summary for an exec deck. What should they check first?
Whether an approved Project or workspace exists for this use case, and whether customer PII is allowed in it under company policy, not whether the output looks fine. The distractor "it is fine since Claude does not retain data by default" skips the actual question this objective tests: whether this org's policy permits this data class in this tool, regardless of any vendor-level retention default.
Q3An employee uses an unsanctioned personal Claude account for a work task instead of the company's sanctioned workspace, reasoning that if the output is good, no one will know. What is wrong with that reasoning?
Work done inside a company's sanctioned Claude workspace is potentially auditable after the fact through Enterprise-tier admin tooling, so working outside it isn't hidden by being unaudited, it's a separate, more serious policy violation regardless of output quality. Since it was avoidable, the right move once realized is to flag it to the policy owner rather than let it stand unreported. The distractor "quality output means no one checks how it was produced" ignores that governance is about process, not just outcome.
Last reviewed: 2026-05-04·Refresh cadence: monthly
CCAOF-D6.2 · CCAOF-D6 · Governance, Risk & Responsible Use

Following Organizational AI Governance Policy, complete.

You've covered the full ten-section breakdown for this primitive, definition, mechanics, code, false positives, comparison, decision tree, exam patterns, and FAQ. One technical primitive down on the path to CCA-F.

More platforms →