Matching Controls to Sensitivity for the CCAO-F Exam

Persistence is not permission

This knowledge point is where the sensitivity tiers and the feature-level controls meet, and the CCAO-F exam sets an evaluate-level bar: pick the correct control for a given tier, and see through the single most seductive error in the whole data domain. That error is believing Incognito mode makes sensitive data safe. It does not. Incognito governs persistence - whether a session is remembered - and persistence is a different question from permission - whether the data was allowed into the feature at all.

The two questions are easy to conflate because both feel like "handling the data responsibly." Keeping them apart is the whole skill. For most data the two questions collapse into one easy answer; for regulated data they come apart sharply, and answering the persistence question while ignoring the permission question is exactly how a compliance failure happens quietly.

The control map across the three tiers

The mapping from tier to control is the backbone of this knowledge point.

Green data needs no special control. It is already safe to use, so you can work with it in an ordinary session without reaching for Incognito or worrying about persistence. Adding controls it does not need is not wrong, but it is not required.

Yellow data that should not persist across sessions is the natural case for Incognito. This is confidential-but-not-regulated material - an M&A draft, an unannounced product spec - where you want the analysis now without it entering Memory or chat history. Incognito fits precisely because the concern is persistence: the data is permitted for the work, but you do not want it lingering. The organization's underlying data-retention policy still applies, but for keeping the material out of history and Memory, Incognito is the right match.

Red data needs an approved, confirmed entry point, and that requirement stands regardless of Memory settings. For regulated data, the question is not "how do I keep this from persisting" but "is this entry point allowed for this data at all." No Incognito toggle answers that. Red data goes into a feature only once an approved path is confirmed, and if none exists, the correct action is to stop and escalate, not to reach for a persistence control.

Why Incognito cannot rescue red data

The reason Incognito cannot make red data safe is worth stating plainly, because it is the crux of the evaluate-level judgment. Incognito controls whether something gets remembered; it does not confirm whether the data was allowed there in the first place. Those are two independent facts about a session. You can run a session in Incognito and still have put data into a feature that was never approved for it. Excluding that session from Memory does nothing to cure the underlying problem - that regulated data entered an unapproved entry point.

So for red data the order of questions is fixed. "Is this allowed here?" is settled before "how do I handle it here?" A practitioner who reaches for Incognito on patient records has answered the second question and skipped the first, and skipping the first is the failure. The permission question comes first, always, for regulated data.

Entry points differ, so ask

A further wrinkle is that different claude.ai entry points can handle data retention differently depending on how the organization has configured Claude. You are not expected to memorize the technical retention behavior of every entry point. You are expected to hold the habit: when in doubt about a given entry point and a given kind of data, ask before uploading. This connects to the default-to-more-sensitive rule - uncertainty about whether an entry point is approved for the data means treating it as not-yet-approved and confirming first. Know your data's sensitivity, then match the feature and its controls to it, and when the entry point's permission status is unclear for sensitive data, resolve that before anything is uploaded.

What the exam trips candidates on

The first trap is using Incognito mode on regulated data and treating that as sufficient compliance, when the entry point itself was never approved. This is the headline misconception. The credited answer recognizes that Incognito addressed persistence while leaving the real question - was this entry point approved for regulated data - unanswered, and that the correct move for red data with no confirmed path is to stop and escalate.

The second trap is confusing Incognito's effect on chat history and Memory with an exemption from the organization's data-retention policy. Incognito excludes a session from history and Memory; it does not lift retention. An answer that treats Incognito as putting data outside all organizational retention has overstated its scope.

Common misreadings to avoid

How this shows up on the exam

Domain 6 evaluate-level questions give you a data tier and a proposed control and ask whether the handling is right. The reliable move is to map the tier to its control - green none, yellow-non-persistent Incognito, red an approved entry point - and, whenever regulated data appears, to check whether the answer settled permission before persistence. The classic wrong answer uses Incognito on red data and calls it compliant; the right answer stops and escalates when no approved path is confirmed.

This is the capstone of Task 6.2. It draws the feature controls and the tiers into a single judgment, and the "stop and escalate when no approved path exists" instinct it builds is the same one that governs when ethical questions must be escalated.