Home › Study guides › CCAO-F › Domain 6 › Lesson 6.2

CCAO-F · Domain 6 · 15% of the exam · Lesson 6.2 · 19 min read

Sensitive data and privacy: protect it before you share it

How to classify data before it reaches Claude, share only what a task needs, spot re-identification risk, and know what privacy settings do and do not do.

Written against objective 6.2 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

6.2.1 Where a privacy mistake really happens

Beatriz runs operations for a group of six physiotherapy clinics. Missed appointments are her biggest scheduling headache: every no-show is a paid hour with an empty treatment room, while the complaint log fills with patients who could not get a slot. A year of booking exports and front-desk complaint logs should explain both, and Claude could find the patterns in an afternoon.

Then she opens the exports. Each appointment row holds the patient's name, date of birth, phone number and condition. The complaint log is free text, and people write freely: "my husband Kieran had to wait", "the new receptionist told me", "since my knee operation in March". Uploading both files as they are would hand Claude thousands of patients' health details, plus the names of relatives and staff who never agreed to any of this. Almost none of it is needed to learn which slots people miss.

The analysis itself is a good use of Claude. The risk sits in one moment: the upload. Once a file is in a chat, it has been shared, and nothing you type afterwards can take it back. So the protection comes first, and its heart has a name: data minimisation, sharing only what the purpose requires.

6.2.2 Classify before you share

Here is the question that catches people out: is this file sensitive? A file is the wrong unit. It is a bundle of fields, and each field has its own level. Many organisations use four levels under names of their own; learn the idea, then use your organisation's labels.

Memorise the last row and one rule: a file takes the level of its most sensitive field. Beatriz's no-show counts per clinic are internal. Add one column of conditions and the whole file is regulated, because health information now travels with every row. Her complaint log is regulated too, for a less obvious reason: free text carries whatever people chose to write, including other people's names and health details.

Regulated means a law or a contract controls how the data may be used. For example, in the European Union the General Data Protection Regulation (GDPR) covers personal data. In the United States, the Health Insurance Portability and Accountability Act (HIPAA) covers patient health information held by healthcare providers, insurers and the firms that work for them. Another US law, the Family Educational Rights and Privacy Act (FERPA), covers students' education records. Which law applies, and what it allows, is a legal judgment that is not yours to make. Your part is to recognise when data MIGHT be regulated, follow your organisation's guidance, and ask the privacy or legal owner when the guidance does not cover your case.

Beatriz does exactly that. She does not know which rules cover clinic records, and she does not need to. She knows conditions are health data, so she books fifteen minutes with Rafael, the clinics' privacy lead, before she prepares anything.

6.2.3 Give Claude only what the task needs

It is tempting to upload everything and let Claude work out what matters. Resist it: by the time Claude could set a field aside, it has already received it. Minimisation runs the other way. Start from the purpose, list the fields that serve it, and build an extract that contains nothing else.

Think of a plumber quoting for a new bathroom. You give them the room's measurements and photos of the pipes, not your house keys and last year's bank statements in case they prove useful. The precise version: every field you share should answer a question the task actually asks. Five techniques get you there.

• REMOVE what the task never uses: names, phone numbers, addresses.
• GENERALISE what it needs only roughly: an age band instead of a birth date, a month instead of a date.
• REPLACE identities with codes when rows must stay linked: P0412 instead of a name, with the key kept by you and never uploaded.
• AGGREGATE when counts are enough: no-shows per clinic per weekday instead of one row per visit.
• INVENT when only the shape matters: synthetic rows that look like the real ones but describe no one.

With Rafael's agreement on the fields, Beatriz builds her extract. Patients become codes, so repeat no-shows still count, and only the 64 complaints tagged as scheduling go in, with every person replaced by a role. Look at the second paragraph of her request, which says what the file leaves out on purpose, and at the last line, which limits what the report may show.

Purpose: find when and why patients miss appointments at our six clinics, so we can change reminder timing and slot lengths. This is a scheduling review, not a review of individual patients or staff.

Attached file 1: one row per appointment for the last 12 months. Columns: clinic, month, weekday, time band, days booked in advance, booking channel, age band, treatment group, outcome (attended, cancelled, no-show). Patients appear as codes such as P0412 so repeat no-shows can be counted. Names, contact details, birth dates and diagnoses have been removed on purpose.

Attached file 2: the 64 complaints tagged "scheduling", with every person replaced by [PATIENT], [RELATIVE] or [STAFF].

Tasks:
1. No-show rate by clinic, weekday, time band and days booked in advance.
2. The main scheduling complaint themes, with a count for each.
3. Three changes worth testing, each tied to the figures behind it.

Do not report any group with fewer than 10 appointments; merge it into a wider group instead. Describe complaint themes in your own words rather than quoting complaints.

Claude can help with the preparation too, without seeing a single real record. Describe the columns, or paste three invented rows, and ask for the spreadsheet steps to drop, band and code them. You get the method; Claude never gets the patients.

6.2.4 Removing names is not enough

Here is the failure that slips past careful people. Beatriz's extract has no names. Yet one scheduling complaint reads: "[PATIENT] had the only Saturday slot at Harbour Road on 14 June, a week after her hip replacement, and the locum [STAFF] never arrived." Nobody named her. Any receptionist at Harbour Road knows exactly who she is.

This is re-identification: working out who a record is about from details that are harmless on their own. A clinic, a date, an operation, a role: each fits many people, but together they may fit only one. It works like a game of Guess Who: no single question names the face, yet three answers leave one card standing. Precisely: a record identifies someone when its combination of details matches one person, whether or not a name is present.

The people best placed to re-identify are often the readers of the result, who know the patients, the staff and the calendar. So minimise with this risk in mind: generalise exact dates to months, drop rare details the purpose does not need, such as a named operation, and suppress small groups. One no-show among patients over 80 at the smallest clinic on Saturdays points at a person.

Beatriz rewrites the Harbour Road complaint in her extract as "[PATIENT] waited for a weekend appointment that the covering therapist did not attend". The scheduling problem survives; the person does not. Then she checks the output as well as the input: a report that quotes a vivid example can carry an identifying detail straight back out, so she reads Claude's examples for exactly that.

6.2.5 What settings and instructions can and cannot do

Suppose Beatriz had uploaded the raw exports with a line at the top: "This data is confidential. Do not keep or remember it." It feels like a safeguard. It is not one. Claude reads the conversation and writes a reply; it does not run the storage, set retention or choose what trains future models. Your account's terms and settings decide those.

It is like asking the person who answers your call not to record it, when the phone system does the recording: they can agree politely, and the recording happens anyway. Claude may even reply that it won't keep the data. Real settings do exist, so be clear about what each one controls.

Notice the pattern: every real setting acts AFTER you share. The account matters too, because the terms differ. Free, Pro and Max accounts run under consumer terms an individual accepts; Team and Enterprise accounts run under commercial terms the organisation agreed, with settings its administrators control. Some safeguards exist only on some plans: the Help Center, for example, describes a HIPAA-ready setup that Enterprise plans can enable and other plans cannot, covering only some features. Whether your organisation needs anything like that, and which account may hold the data, is for its privacy and legal owners to decide, not for you or Claude.

6.2.6 Connectors and Projects widen what Claude can reach

So far the data reached Claude because Beatriz attached it. Two features let Claude reach data without a fresh upload, and both widen the circle.

A connector links Claude to a service such as Google Drive or email so it can search and read what is there. It inherits your permissions: whatever your account can open, Claude can reach through it. Claude can also bring a connected service into a conversation on its own when that fits the request. Beatriz's Drive account can open the raw booking exports, referral letters and an HR folder; switch Drive on for the scheduling question, and all of that is within reach.

A Project keeps instructions and files together for recurring work, and its knowledge is available in every chat inside it. On Team and Enterprise plans a Project can be shared, and even members who can only view it can see that knowledge. A raw export saved there sits in front of everyone the Project reaches, in every future conversation.

Scope each one to the task. Put only minimised files in Project knowledge, switch a connector on only in the chats that need it, and disconnect services you no longer use. Beatriz sets up a Project called Scheduling review in the clinics' work account, adds her two prepared files and nothing else, and shares it only with the two clinic leads redesigning the booking rules.

6.2.7 The exam traps

Every trap here either shares too much or protects too late. The right answer protects the data first and lets the legitimate work go on.

• ✗ Uploading the full export because the analysis stays in-house. ✓ Who reads the result does not lower the data's sensitivity. Minimise first, then upload.
• ✗ Uploading everything and asking Claude to strip out or ignore the personal details. ✓ Remove them before upload; by the time Claude could filter them, it has already received them.
• ✗ Treating "don't keep this", an incognito chat or a privacy setting as the safeguard. ✓ These act after sharing. The control is not sharing, or sharing minimised data through an approved account.
• ✗ Deleting the names and calling the data anonymous. ✓ Check for combinations of place, date, role and rare events, and generalise, aggregate or drop what could single someone out.
• ✗ Deciding for yourself what the law allows, or dropping the analysis to be safe. ✓ Follow policy and ask the privacy owner. Minimised data usually lets the work go ahead.
• ✗ Connecting a whole Drive, or saving raw records in a shared Project, for convenience. ✓ Scope connectors, Project knowledge and membership to what the task needs.

6.2.8 Put it together: prepare a dataset before Claude sees it

You now have the whole routine. Start from the purpose and the fields it needs, classify them, and ask the privacy owner about anything that may be regulated. Remove, generalise, code or aggregate the rest, then check for combinations that still point to one person. Share through an approved account, with connectors and Projects scoped to the task. The exercise below uses invented data only and shows what skipping the preparation costs.

This lesson dealt with the data in front of you. Following organisational AI policy (6.3) covers the approved tools, admin controls and sign-offs that decide which account counts as approved. The ethics of AI use (6.4) asks what clean data cannot answer: even when an analysis is allowed, who could it affect, and is that fair?

Key takeaways

• ✓ The upload is the moment of risk; protect data before Claude receives it, because nothing afterwards can un-share it.
• ✓ Classify each field as public, internal, confidential or regulated; a file takes the level of its most sensitive field.
• ✓ When data may be regulated, follow your organisation's guidance and ask the privacy or legal owner instead of interpreting the law.
• ✓ Minimise before upload by removing, generalising, coding or aggregating fields, or by using synthetic rows, so Claude gets only what the purpose needs.
• ✓ Removing names is not anonymisation; a unique combination of details can still identify a person, in the data and in Claude's output.
• ✓ Instructions, incognito chats and privacy settings act after sharing; the control is not sharing, or sharing minimised data through an approved account.
• ✓ Connectors and Projects widen what Claude can reach, so scope them to the files, services and people the task needs.

Check your understanding

4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• How long do you store my data?
• Is my data used for model training? (commercial products)
• Use incognito chats
• Use connectors to extend Claude's capabilities
• What are projects?
• HIPAA-ready Enterprise plans
• The CCAO-F exam guide, summarised