Learn · AI Governance

When Work Moves to a Personal Account

Shadow AI is the distance between the AI policy your board approved and what your people do at 21:40 on a Wednesday to finish a piece of work. It is almost never defiance. It is someone hitting a limit in the path you gave them and routing around it — and the risk that lands on you is not that they used a model, but that the work left your identity boundary and everything attached to it.

The criterion this actually lands on. CC6.7 reads: “The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives.” A personal account is the unauthorised process. This is not a rule about AI. It is a control about where information is allowed to go.

Talk to a Compliance Advisor ISO 42001 Hub

CC6.7the criterion this lands on

0DPAs covering a personal account

20+frameworks TCSA advises across

Plain-English explainer · Vendor terms and plan tiers change — verify current documentation · Last reviewed August 2026

Shadow AI is a product gap before it is a control gap, and it is cheapest to treat in that order. When an employee moves a piece of work into a personal ChatGPT, Claude or Gemini account, what you lose is not abstract. You lose enterprise identity and the offboarding that goes with it, retention and deletion you can actually reach, the contractual protections in your enterprise agreement, the admin audit log, the egress path your DLP was tuned around, and the ability to bound an incident. Underneath all of those sits the loss with commercial consequences: you can no longer answer a customer asking where their data went. Most organisations respond to that list by writing an enforcement policy. The ones that actually reduce shadow AI write a product requirement first, then a policy that is narrow enough to be enforceable, then detection proportionate to the question they are asking. This page covers all three in that order, plus the evidence a licensed CPA firm requests when it tests the control, and what to do in the first hour after you find confidential material somewhere it should not be.

Key Takeaways

Shadow AI is rarely defiance. It is someone hitting a capability ceiling, a usage cap, a missing model, an approval queue or a missing seat in the sanctioned path, and routing around it to finish the work in front of them.
What is lost is specific and listable: enterprise identity and the joiner-mover-leaver lifecycle, retention and deletion you can reach, the contractual terms in your enterprise agreement, the admin audit log, the egress path DLP watches, and the ability to say what was exposed.
The hardest pattern is not the employee who never adopts the enterprise tool. It is the one who uses it for most of their work and switches to a personal account at exactly the moments the work is hardest — which is usually when it is also most sensitive.
Punishment is a weak primary control and a reliable way to destroy your best detection channel. The trust services criteria themselves ask management to consider the excessive pressures that lead people to circumvent controls, under CC1.5.
Detection should be proportionate and disclosed. Sanctioned-tenant usage analytics and expense records answer the governance question at almost no privacy cost, while inline content inspection answers a narrower question at a much higher one, and in parts of the EU it is a co-determination matter rather than a configuration choice.
The primary control is making the approved path better than the personal one — model parity, visible caps with a same-day raise, a seat for everyone including contractors, and an exception route that returns an answer within a business day. Everything else on this page is secondary to that.

Why it happens

Six drivers, and none of them is malice

In readiness work we have yet to see a shadow AI case that started with someone deciding to breach a policy. Every one of them started with someone deciding to finish a task. The distinction matters because it determines which lever works: you cannot deter a decision that was never framed as a decision, but you can remove the obstacle that forced it.

A capability the sanctioned deployment does not have

File upload disabled, code execution switched off, web access turned off, a connector not yet approved, a shorter session than the task needs. Enterprise deployments are usually configured conservatively at launch and rarely revisited. The person is not looking for a different tool. They are looking for the feature that was removed from the one you gave them.

A usage or message cap they hit mid-task

Caps are the single most common trigger we see, and the worst-designed part of most enterprise rollouts, because they are usually invisible until the moment they bite. Somebody two hours into a piece of analysis is told to come back in three hours. A personal subscription resolves that in ninety seconds and costs them the price of a lunch.

The model they want is not on your plan

Model preference is real, it is task-specific, and it is not vanity. People form accurate views about which model is better at long-context reading, at code, at structured extraction. If your tenant offers only the cheapest tier while the personal product offers the frontier one, you have priced your own control out of the market for exactly the hardest work.

Latency and friction in the approved path

An extra sign-in, a VPN, a tenant that takes eleven seconds to load, a request form with a two-week queue. Friction does not need to be large to lose. It only needs to be larger than opening a new browser tab. Every second you add to the approved path is a subsidy paid to the unapproved one.

No seat at all

The most avoidable driver. Licences go to engineering and product, and the people handling customer escalations, contracts, recruitment notes and financial models — often the ones touching the most sensitive material — are left out. They do not stop using AI. They stop using yours.

The approval path has no answer for a novel case

A policy that says AI use must be approved, with no named approver, no service level and no route for something the list does not cover, is a policy that returns no answer. People treat silence as permission far more often than they treat it as prohibition, and they are not being unreasonable when they do.

Why punishing it fails, in the criteria’s own words

The instinct after the first discovery is a stern all-hands and a disciplinary line in the policy. It reliably produces three effects, only one of which anybody wanted. Reported incidents fall, which is read as success. Actual incidents do not fall, because none of the six drivers above has changed. And the disclosure channel — the only source of truth about personal accounts, since you have no telemetry inside them — closes, because the rational move for anyone who has already made a mistake is now silence.

“Considers Excessive Pressures — Management and the board of directors evaluate and adjust pressures associated with the achievement of objectives as they assign responsibilities, develop performance measures, and evaluate performance.”

— a point of focus under CC1.5 (COSO Principle 5)

That point of focus is not a licence to ignore the behaviour. It is an instruction to examine the conditions that produce it, and it sits alongside the ones that do carry teeth: the same criterion contemplates evaluating performance and taking disciplinary action, and CC1.1 expects the entity to establish standards of conduct, evaluate adherence to them, and address deviations in a timely manner. The workable posture keeps both halves. Discipline is reserved for concealment, for repetition after correction, and for the deliberate movement of the data classes you have named as prohibited. Everything else is handled as an incident, and the person who tells you about it is treated as the reason you found out.

There is a competence obligation running under all of this too. Deployers of AI systems in the EU carry an AI literacy duty under the EU AI Act, an obligation that has been amended since it first applied and whose current timetable is worth verifying for your own entity rather than taking from a summary. Independent of any regulation, the practical point stands: a workforce that has never been told which data classes are prohibited, or why, cannot be held to a standard it was never given.

The actual exposure

What is lost when work leaves the boundary

“Data goes to a third party” is the wrong summary, because data goes to a third party on the enterprise account as well. The difference is everything that was attached to the enterprise account and is not attached to the personal one. Read the third column against the second. The last row is the one that shows up in a deal.

What you lose	On the enterprise account	On a personal account	Criteria touched
Enterprise identity and the access lifecycle	Access is granted through your identity provider, carries your authentication policy, is tied to a managed device where you require one, and is removed on the last day of employment along with everything else.	The account belongs to the individual, not to you. It survives their resignation, their laptop wipe and your offboarding checklist. Nothing in your joiner-mover-leaver process reaches it, and no revocation you perform has any effect on it.	CC6.1 · CC6.2 · CC6.3
Retention, deletion and legal hold	Retention is a setting you own, deletion is something you can effect, and a hold is something you can impose across the tenant when litigation or a regulator makes it necessary.	You can ask the individual to delete a conversation. You cannot verify it, you cannot reach copies or caches, and you cannot impose a hold on an account you do not administer. Whether deletion is available and what it actually removes varies by product and by plan tier — verify it in current vendor documentation rather than assuming.	C1.1 · C1.2
Contractual data protection	An enterprise agreement with a data processing addendum, defined confidentiality terms, a sub-processor list, a stated transfer mechanism, security commitments you can point a customer at, and terms addressing whether inputs are used to improve models on your tier.	A consumer contract between the vendor and your employee, to which your organisation is not a party. There is no processor contract, which is the thing GDPR Article 28 and DPDP Act 2023 section 8(2) both require before a processor handles data on your behalf — and no chain of terms you can show a customer.	CC9.2 · C1.1
Administrative audit logging	An admin console that can tell you which accounts exist, when they were active, and — depending on the product and tier — what was attached or connected. It is the record that lets you answer a question about a specific week.	Nothing. No admin visibility, no export, no ability to enumerate what happened. The only source of truth about what was pasted is the person who pasted it, which is why the disclosure channel matters more here than any telemetry.	CC7.2 · CC4.1
Egress control and DLP	A known destination that your gateway, DLP and browser policy can be tuned around: block classes of upload, warn on pastes above a size, allow the sanctioned domain and inspect what leaves through it.	A destination that looks identical at the network layer to the sanctioned one on the same vendor domain, so a domain allow-list cannot distinguish them. CC6.7 asks the entity to restrict the transmission, movement and removal of information to authorised users and processes. A personal account is precisely the unauthorised process that criterion is written about.	CC6.7 · CC6.8
The ability to bound an incident	Scoping is a query. You can establish which accounts, which period, which connectors, and produce a defensible statement of what was and was not exposed.	Scoping is an interview. Everything you tell a customer, a regulator or your auditor rests on one person’s recollection of what they pasted at 21:40 six weeks ago, and on how safe they feel being complete about it.	CC7.3 · CC7.4
Output ownership, provenance and indemnity	Terms negotiated by you covering ownership of outputs and whatever indemnity the vendor offers on your tier — the position your own customer contracts and your engineering policy are written against.	Consumer terms your legal team has never read, agreed by an individual, governing material that is now in your codebase or your customer deliverable. Provenance for that artefact cannot be reconstructed from your systems.	CC9.2 · CC8.1
The answer to the customer’s question	A written answer with a system boundary, a named vendor, a DPA reference and a control the auditor tested. It ends the thread.	Silence, or a hedge. This is the loss that has commercial consequences long before it has regulatory ones: the question in the security review is not whether you use AI, it is whether you can say where the data went. Not being able to answer reads worse than most answers.	CC2.3 · C1.1

A note on the contractual row, because it is the one that gets stated too strongly in both directions. Enterprise and consumer tiers differ structurally in retention defaults, admin control and the contractual protections available — that much is durable across vendors and worth relying on. What is not durable is any specific statement about a named product’s current behaviour. Whether inputs are used to improve models on your tier, what retention applies, what deletion actually removes and which sub-processors are involved are all questions to answer from the vendor’s current documentation at the time you write the control, and to re-check when you renew. Write the governance question into your vendor review rather than writing the answer into your policy.

The exposure has a name in the AI security literature as well: the OWASP Top 10 for LLM Applications lists Sensitive Information Disclosure at LLM02 in its 2025 edition, having moved up from sixth in the previous one. Verify the current edition and item numbering before you cite it in a policy, since OWASP re-ranks between editions.

The hard case

Enterprise for most of it, personal at the limit

The employee who never adopts your enterprise tool is a manageable problem. Their usage is zero, the negative signal is loud, and a conversation usually fixes it. The genuinely hard case is the opposite: someone who does ninety per cent of their work in the sanctioned tenant, is a visible advocate for it, and switches to a personal account at the moments they hit a wall.

Four properties make it hard, and they compound. The switch correlates with difficulty, and difficulty correlates with sensitivity. Nobody opens a personal account to draft a meeting agenda. They open one for the customer escalation, the incident write-up, the diligence document, the contract analysis — the work with the highest concentration of exactly the material your policy names. Your exposure is not distributed evenly across their AI use. It is concentrated in the worst possible tail.

The telemetry looks healthy. Sanctioned-tenant usage reports show an active, engaged user. Domain-level egress cannot distinguish the two accounts, because they live on the same vendor domain. The negative signal that catches the non-adopter — a seat that is never used — is absent by construction. Detection is weakest precisely where the stakes are highest.

The switch happens mid-task, with context already assembled. This is the part organisations underestimate. The person has already pasted the schema, the log extract or the document into the enterprise session. Hitting the limit does not send them back to first principles. It sends them to a new tab where they paste the same material again, because re-assembling context is the expensive part. The personal account therefore receives the fully assembled version of the sensitive material, not a fragment of it.

And the person is not a policy problem. They are usually a high performer with a legitimate reason, which is why a disciplinary frame produces a bad outcome twice over: it is unjust on the facts, and it teaches the most capable users of AI in your organisation that telling you things is expensive.

The only control that addresses this pattern at its cause is the sanctioned path itself. You are not competing with a policy violation. You are competing with a consumer subscription of roughly twenty dollars a month that removes the limit at the exact moment the limit is felt. That comparison — per-seat cost against the cost of one scoping exercise, one customer notification and one exception in a report — is the argument to take to the budget conversation, and it is the only one on this page that removes the driver rather than policing it.

Detection

Proportionate to the question you are asking

Before choosing an approach, decide which question you are answering. “How much shadow AI do we have and where?” is a governance question and is answered by aggregate signals at low privacy cost. “Did this specific person paste this specific thing?” is an investigative question, and reaching for investigative tooling to answer a governance question is how monitoring programmes lose their mandate.

Approach	What it actually sees	What it cannot see	Privacy cost	Where it fits
DNS and egress telemetry on managed devices	That a device reached a given AI vendor’s domain, when, and roughly how much data moved. Aggregated across the organisation it gives you a usage picture without touching content.	Which account was used — enterprise and personal traffic share the same domains. Personal devices, mobile networks and anything outside the managed estate are invisible.	Moderate. It is metadata about individuals’ activity and needs to be disclosed in your monitoring notice. Retention of the telemetry itself becomes a data protection question of its own.	Establishing the shape of the problem before deciding what to build. Weak as an individual-accusation tool, and it should not be used as one.
Inline content inspection at a gateway or CASB	Prompt and upload content on managed devices, which is the only technique on this list that can distinguish a personal account from an enterprise one in real time and block a specific paste.	Anything on an unmanaged device, and anything on a mobile phone photographing a screen. Certificate pinning and app-native clients defeat parts of it.	High, and in several jurisdictions it carries legal weight beyond policy: TLS interception of employee traffic engages works-council consultation in parts of the EU and employee-notice requirements in most places. It reads private communications by design.	Regulated environments with a specific, documented data class to protect, where the intrusion has been assessed and agreed rather than switched on because the licence included it.
Managed browser or enterprise extension telemetry	Which profile is signed in on the tab, paste and upload events above a threshold, and — where the product supports it — a warning or block at the moment of paste rather than after it.	Personal browsers, personal profiles, native desktop apps and anything on a device you do not manage.	Moderate to high depending on configuration. A warn-and-log design is far easier to justify to staff than a silent-capture one, and it usually works better because it interrupts at the decision point.	Organisations that already run a managed browser. The interruption is more valuable than the record.
Sanctioned-tenant usage analytics	The negative signal, which is the underrated one. Who has a seat and never uses it. Whose weekly usage falls while their output does not. Which teams were never given seats at all.	Any direct evidence of a personal account. It tells you where to ask, never what happened.	Low. It is your own tenant, your own contract, and the data is about the use of a corporate tool. Aggregate reporting at team level answers most governance questions without ever naming a person.	The default first move, and the best signal for the enterprise-mostly-personal-sometimes pattern. It is also the only one that points at the fix rather than the offender.
Expense claims, corporate cards and SaaS-spend discovery	Reimbursement claims and card charges for personal AI subscriptions, and team-level subscriptions bought outside procurement. In practice this finds more real shadow AI than most security tooling.	Free tiers, personal cards never claimed, and anything paid for by someone who has decided not to be reimbursed.	Very low. These are corporate financial records already reviewed for other purposes. No new collection and no new intrusion.	Every organisation, immediately, at no cost. Ask finance before you buy anything.
Endpoint DLP on clipboard, upload and file operations	Large or classified content leaving a managed device by upload or clipboard, including into a browser tab, with the option to block on classification rather than on destination.	Unmanaged devices. Generates significant false positives against normal work unless classification is mature.	High, and operationally expensive. It watches everything the person does with data, not only what they do with AI.	Organisations that already run mature data classification. Deploying endpoint DLP specifically to catch shadow AI is a large project answering a small part of the question.
Self-disclosure under a stated amnesty	What actually happened, in the person’s own words, including the parts no telemetry could reach — what was in the file, why they switched, and whether it has happened before.	Anyone who does not trust the promise. Its yield is exactly as good as management’s credibility, which is the uncomfortable and accurate thing about it.	Lowest of all. Nothing is collected that the person did not choose to tell you.	The highest-quality signal available and the cheapest to run. It is also the first thing a punitive posture destroys, which is the main practical argument against a punitive posture.

Four rules keep a detection programme defensible, and they are worth writing into the policy rather than holding as intent. Disclose before you collect — undisclosed monitoring costs more trust than it earns and, in several jurisdictions, is a legal exposure rather than a cultural one. Aggregate first, escalate to naming — report at team level by default, with a written trigger for when an individual is identified and who approves that step. Limit the purpose in writing — telemetry collected to govern AI use should not quietly become a performance-management input, and saying so is what makes the programme survivable. Retain the telemetry for a stated period — monitoring data about employees is personal data and needs its own retention decision, not an indefinite default.

One further rule earns its place because it settles most internal arguments quickly. If a detection capability is one you would not be comfortable describing in the AI policy that staff read, it is a capability you should not deploy. The discomfort is information.

The primary control

Make the approved path genuinely better

Every row below converts an enforcement problem into a product decision. This is the same move a small team makes when it replaces “changes are peer-reviewed” with a branch protection rule: remove the discretion rather than supervise it. CC5.2 (COSO Principle 11) is the criterion that recognises technology as a control activity in its own right, and it is where the leverage is.

The limit they hit	What happens next	The sanctioned-path answer
A usage or message cap hit mid-task	Opens a personal account to finish the piece of work, then usually keeps using it because the context is already there.	Make the cap visible before it is reached, and give a self-serve raise for roles that legitimately hit it. If you cannot afford unlimited, you can afford to tell people where the line is and how to move it the same day.
The model they want is not on your plan	Uses the enterprise tenant for routine work and the personal account for the hardest problems — the pattern with the worst risk profile, because difficulty and sensitivity correlate.	Buy model parity for the roles that need it rather than the cheapest tier for everyone. The delta between plan tiers is smaller than the cost of one scoping exercise, and far smaller than one customer notification.
A capability disabled at deployment	Works around the specific missing feature — file upload, code execution, a connector — while otherwise complying.	Re-review the launch configuration on a stated cadence with a named owner. Most disabled features were switched off during a rollout nobody has revisited since, for a risk assessment nobody has re-read.
Latency or friction in the approved path	Drifts to whatever is one click away, usually without ever making a conscious decision about it.	Measure time-to-first-token and time-to-sign-in in your tenant as product metrics, because that is what they are. Remove the extra authentication hop if your risk assessment allows it.
No seat issued	Uses a personal account for everything, in full view, often believing they are permitted to because nobody said otherwise.	Default to a seat for every employee and every contractor with a corporate identity. Per-seat cost is the cheapest control on this page and the only one that removes the driver entirely rather than policing it.
A genuinely novel use the list does not cover	Either abandons a useful idea or proceeds quietly. Both outcomes are bad, and the second is worse.	Publish a named approver, a same-day or next-day service level, and a bounded time-limited exception with an expiry date. An exception route that returns an answer within a day is worth more than three additional monitoring tools.

Two of these deserve emphasis because they are the ones budget conversations resist. A seat for everyone, including contractors with a corporate identity, removes an entire population from the unmanaged column and is usually cheaper than the tooling proposed to monitor that same population. Model parity for the roles that need it is what actually addresses the hard case above, because a tenant offering only the cheapest tier has, in effect, outsourced your hardest and most sensitive work to consumer accounts. Where the AI tooling itself is in scope of a management system, the governance around which systems are approved, who owns them and how their use is controlled is the substance of an ISO/IEC 42001 AI management system — a certifiable standard whose Annex A reference controls include AI policy, internal organisation and roles, and the organisation’s own use of AI systems. Certificates there are issued by accredited certification bodies, not by advisors.

Drafting

Policy language that is actually enforceable

A policy is a control activity deployed through documented expectations — that is CC5.3 read literally, and CC2.2 adds the requirement that it be communicated. Both mean the document has to be capable of telling someone what to do. Most AI policies fail that test in five identifiable ways.

Clause that does not hold	Why it fails	What to write instead
"Employees must not share confidential information with AI tools."	Undefined and self-contradicting once you have deployed an enterprise assistant that people are supposed to share work with. It also fails the only test that matters at 21:40 on a Wednesday, which is whether the person reading it can tell what to do next.	Name the data classes rather than the adjective, and name the destination: customer production data, personal data of data principals or data subjects, credentials and secrets, unpublished financial results, and material under a customer NDA must not be entered into any AI tool outside the approved list. Everything else may be entered into an approved tool.
"AI use must be approved before use."	No approver, no route, no service level, no definition of what constitutes use. It returns no answer, and silence is read as permission.	Name the approver by role, publish the request route, and commit to a response time. Approved tools are listed at a stated location, reviewed quarterly by a named owner. Requests for anything not listed are answered within one business day by that owner.
"Personal AI accounts are prohibited."	Unenforceable at the level it is written, because you cannot see personal accounts on personal devices — and a rule everyone knows is unenforced weakens every other rule in the document.	Prohibit the act rather than the account: company information as defined above must not be entered into a personal or non-corporate AI account. Personal use of AI on personal time and personal data is outside the scope of this policy. That version is testable and does not require you to police anyone’s private life.
"Violations may result in disciplinary action."	It reads to the person who has just made a mistake as a reason to say nothing, which is the outcome you least want. It also makes no distinction between an error and a concealment.	Separate the two explicitly. Disclosure of an inadvertent disclosure, made promptly, is treated as an incident to be handled and not as a disciplinary matter. Concealment, repetition after correction, and the deliberate movement of prohibited data classes are disciplinary matters. Then keep the promise the first time it is tested, because it is only worth what it is worth then.
Silence on monitoring.	Telemetry that staff discover rather than being told about costs more trust than the telemetry was ever going to earn, and in several jurisdictions undisclosed monitoring is a legal exposure rather than a cultural one.	State what is collected, at what granularity, for what purpose, who can see it and how long it is kept. A useful drafting test: if you would not be comfortable writing a monitoring capability into the policy, do not deploy it.

One structural point runs through all five. A policy is the standard you will be tested against, so every sentence in it is a promise an auditor can examine and a buyer can quote. A clause promising that all AI use is monitored, in an organisation where a third of access comes from unmanaged devices, does not protect you — it manufactures the exception. Write the narrower thing that is true, and put the scope limit in the document rather than leaving it to be discovered. The same discipline applies to control ownership: an AI policy with no named owner and no review date is not a control, it is a statement.

Worked example

240 people, 140 seats, one expense claim

An illustrative composite, not a client. A B2B data-analytics company of 240 people, Security and Confidentiality, Type 2, observation period 1 January to 30 June 2026. Read the middle column first: the gap between the baseline row and the detection row is the whole story.

Baseline	12 Nov 2025	Enterprise AI assistant goes live for 140 of 240 staff — engineering, product and support. Solutions engineering, contracts and recruitment get no seats. The acceptable-use policy is published and acknowledged by all 240, including the 100 with nowhere sanctioned to go.
The switch	4 Mar 2026, 21:40	A solutions engineer working a customer escalation hits a file-size limit on the sanctioned deployment. They open a personal account, upload a customer schema export and roughly four thousand rows of sample data, and resolve the escalation by 23:10. They are not being reckless. They are finishing a job for a customer at the end of a long day.
Detection	2 Apr 2026	Finance queries an expense claim for a personal AI subscription submitted with the March batch. No security control detected anything. The organisation’s most effective shadow AI control that quarter was an accounts payable review, which is a finding in itself.
Disclosure	3 Apr 2026	The engineer discloses fully under the amnesty clause published in January. Two unrelated disclosures follow within the week, both from the group with no seats — the amnesty is worth more in that week than in the previous three months combined.
Scoping and assessment	3–10 Apr 2026	What was uploaded is reconstructed from the engineer and from the customer ticket. Whose data it was, which contract governed it, what the consumer tier’s terms said about training and deletion at that time, and whether the confidentiality commitment in that customer’s agreement was breached. The classification decision and the notification decision are made and recorded by the security lead, not by the engineer.
Control change	14 Apr – 9 May 2026	Seats extended to all 240. The file-size limit is raised after a re-review of the launch configuration. A named owner and a one-business-day exception route are published. An exception register opens with three entries by period end.

Twenty-nine days elapsed between the event and the detection, and the control that found it was an accounts payable review. Every security control in the programme — the acknowledged policy, the tenant usage report, the egress telemetry — was operating and none of them saw it. That is not a failure of the controls as designed. It is what the detection table predicts: domain-level telemetry cannot separate the two accounts, and tenant analytics cannot see an account outside the tenant.

At fieldwork in July the populations are small and legible, which is the pattern to expect on this control. Six monthly telemetry reviews, all six tested. Three exception-register entries, all three tested for a distinct approver and an expiry date. Two hundred and forty policy acknowledgements, sampled. One incident in the incident population, tested against the incident-response control end to end. The auditor spends more time on the one incident than on the other three controls combined, because a single incident handled well is the most informative artefact in the period.

The extension of seats in April, from 140 to the full population of 240, is a mid-period control change and belongs in the system description as one, described with the date it took effect. The incident itself is disclosed and tested rather than hidden. A security incident during the observation period is not automatically an exception, and an incident that was detected, scoped, decided and remediated inside the period frequently reads as evidence that the incident-response control works.

A hundred people were asked to acknowledge an AI policy and given nowhere sanctioned to comply with it. The gap between those two numbers is the control finding, not the engineer.

— the lesson in the composite

Evidence

What the CPA firm actually requests

Teams expect to be asked for the AI policy. What they are actually asked for first is a population — because a sample drawn from an incomplete list proves nothing about the list it came from, and establishing that the information you produced is complete and accurate is a step in its own right before any testing begins.

The request	What satisfies it	What gets rejected
Define the population the policy applies to	A system-generated roster of every employee and contractor with a corporate identity during the period, reconciled to HR records and to the sanctioned tenant’s user list, with the query, date range and record counts visible.	A list of licence holders offered as the population when the policy applies to everyone. A roster that does not reconcile to headcount. A count that changes between the first extract and the second.
Evidence the policy was communicated and acknowledged	An acknowledgement export covering the full roster including mid-period joiners and contractors, with acknowledgement dates inside the period, plus the version of the policy in force on each of those dates.	An all-hands slide. A single acknowledgement campaign run in the final month for a control described as operating on hire. Acknowledgements against a policy version that was superseded during the period.
Evidence the approved-tool inventory is maintained	The inventory with a named owner, review dates inside the period, and at least one recorded decision — an addition, a removal, or a documented reason for no change — showing the review was performed rather than scheduled.	An undated list. An inventory that omits tools visible in the expense records, which is the reconciliation the auditor will actually run.
Evidence the monitoring control operated at the stated cadence	The report or telemetry review for each occurrence in the period, the reviewer’s dated sign-off, and at least one instance where something was queried, investigated and closed out.	A dashboard screenshot taken during fieldwork for a period that closed months earlier. A monthly review with two of six months missing. A review that has never found anything, which invites the question of whether it is performed at all.
Evidence exceptions were approved and bounded	An exception register with requester, an approver who is a different person, the data classes and tools permitted, an expiry date, and evidence that expired exceptions were closed or re-approved.	An open-ended exception with no expiry. Requester and approver as the same account. An exception granted after the activity it covers had already happened.
Evidence a disclosure was handled as an incident	The incident record with detection date and route, the scoping note, the classification decision and who made it, the notification assessment with its recorded basis, the remediation, and the closure date.	A chat thread. A conclusion that no notification was required with no recorded reasoning. A record whose only author is the person who made the disclosure.

Two pieces of vocabulary make this easier to follow. What the auditor is establishing about anything you export is its completeness and accuracy, and the artefact class has a name: information produced by the entity, usually shortened to IPE. That is why the query, the filter, the date range and the record count have to travel with the result. Sample sizes then behave the way they do everywhere else in a SOC 2 examination: neither the trust services criteria nor AT-C 205 prescribes a number, and a small population is usually tested in full. An exception register with three entries is a population of three, and one missing approval in it is a deviation rate of a third with no sampling risk to absorb it.

An ISO/IEC 42001 certification audit asks a different set of questions about the same subject matter, and it is worth knowing the difference before you build one evidence set for both. The certification body examines a management system, while the CPA firm expresses an opinion on control effectiveness over a period. So expect questions about the AI policy and who approved it, the roles and responsibilities assigned for AI, the inventory of AI systems in use and how it is kept current, how impacts are assessed, and how competence and awareness obligations are met. Much of the underlying evidence overlaps with the table above, but the framing and the deliverable do not. Certificates are issued by accredited certification bodies, SOC reports by licensed CPA firms, and integrating the two management systems is a separate exercise from mapping their evidence.

TCSA does the readiness, control design, evidence preparation and coordination on both sides of that line. TCSA does not certify, attest, audit or sign — those belong to the certification body and the CPA firm respectively, and the separation is what makes their output worth something. More on the evidence mechanics in the evidence collection guide.

The response

When you find it somewhere it should not be

The sequence below is written for the case that actually occurs: a disclosure, not a forensic discovery. The two failure modes to avoid are deleting before you have scoped, and concluding before you have checked which clocks are running.

First hour	Contain	Establish what was entered, into which product and account, and when — from the person, in a conversation that is not disciplinary, because the completeness of this account is the whole basis of everything that follows. Ask them not to delete anything yet: deletion feels like containment and can destroy the record you need, and if any litigation hold or regulatory duty applies it may be prohibited outright. Decide who owns the incident, and make sure it is not the person who made the disclosure.
First day	Scope and classify	Reconstruct the content precisely — which customer, which data classes, how many records, whether personal data was involved and whose. Check the account tier’s current terms on retention, deletion and whether inputs are used for training, in the vendor’s own documentation as it stands today rather than from memory or a blog post. Then classify: a policy deviation, a confidentiality-commitment breach, a personal data breach, or more than one of these. Record the classification and its reasoning.
First day	Check the clocks	Notification obligations run from awareness, not from conclusion, and they are the part organisations miss while they are still scoping. Under GDPR the supervisory authority clock is 72 hours from becoming aware of a personal data breach. The DPDP Act 2023 requires a Data Fiduciary to intimate the Data Protection Board and each affected Data Principal of a personal data breach in the prescribed form and manner. Customer contracts frequently carry their own notification triggers that bite on unauthorised disclosure regardless of demonstrated harm — read the contract, not the summary.
First week	Decide and record	Reach a documented conclusion on notification, including a decision not to notify if that is where the analysis lands. A decision not to notify is defensible, but an undocumented one is not, and it must be made by someone other than the person involved. Then delete where deletion is available and lawful, and record what deletion the vendor’s current terms actually effect, because the honest answer is sometimes that you cannot verify it.
Within the month	Change the cause	Remediation that restates the policy is not remediation. Ask which of the six drivers produced this — the cap, the model, the missing capability, the friction, the missing seat or the unanswered request — and close that one. Update the exception register, the tool inventory and the monitoring scope, and put the change through your normal change process so it is evidenced. If the observation period is still open, this is a mid-period control change and belongs in the system description.

Three things are worth saying plainly about this sequence. Deletion is not containment when you cannot verify it, so record what you asked for, what the vendor’s current terms say deletion does, and what you were unable to confirm — an honest gap documented beats a confident claim you cannot support. The classification decision must have an author who is not the person who made the disclosure, for the same reason no control is a control when requester and approver are the same name. And a conclusion of “policy deviation, not a reportable breach” is a perfectly legitimate landing point. It is only indefensible when nobody wrote down why. Where personal data is involved, the analysis runs through your obligations as a data fiduciary or controller, and the difference between the Confidentiality and Privacy categories determines which of your own commitments the incident touches.

Where this gets contested

The edge cases that generate the questions

The design above covers the common eighty per cent. These are the situations that produce genuine disagreement — between security and legal, between a company and its auditor, and between a vendor and a buyer’s security team — and where settling the answer in advance is worth several days.

The personal account that predates employment

Most people arrive with an AI account they have used for years, holding a mixture of personal and previous-employer material. You have no standing to demand access to it and no lawful basis to inspect it. What you can do is govern the boundary going forward: state in onboarding that company information goes only into corporate accounts, issue the seat on day one so there is no gap to bridge, and make the offboarding conversation explicit about not carrying company material out in a personal account — which is a confidentiality obligation you already have, not a new one you need to invent.

Contractors and agency staff with no corporate seat

This is the largest unmanaged population in most organisations and the one most policies quietly ignore. A contractor with access to your systems and no sanctioned AI tool will use a personal account, and their contract with you probably says nothing about it. Two workable routes: issue them a seat under the same identity provider as everyone else and treat the cost as part of the engagement, or write the prohibition and the approved-tool list into the contract itself and accept that you are relying on a contractual control rather than a technical one. What does not work is a policy that binds employees only, in an organisation where a third of the people with system access are not employees.

The personal subscription bought with a work email address

The most deceptive case on this list. A consumer-tier subscription registered to a corporate address looks sanctioned in every log you have — the domain is right, the identity looks right, and a domain allow-list waves it through. It has none of the enterprise contractual terms, none of the admin visibility and none of the retention control. Most vendors offer a domain-claim or verified-domain mechanism that surfaces or converts these accounts. Whether yours does, and what it does to existing accounts, is worth checking in current vendor documentation before you assume your tenant view is complete.

Bring-your-own-device and the personal phone

On a device you do not manage there is no telemetry, no DLP and no browser policy, and there is not going to be. Pretending otherwise produces a control description your auditor will test and find hollow. The honest design states the scope limit — technical enforcement applies to managed devices, while on unmanaged devices the control is the contractual and policy one — and then compensates by removing the reason to reach for the phone in the first place. Where you cannot enforce, reduce the incentive.

The model is not available in the country your team works in

Regional availability, data-residency configuration and enterprise plan coverage do not map cleanly onto where your people are, and a team in an unsupported region is structurally pushed toward personal accounts and consumer tiers. Treat it as a scoping question rather than a compliance failure: establish which of your entities can be covered by the enterprise agreement, what the residency position is for each, and where a different vendor or a self-hosted option is the honest answer. Do not write a policy that requires people to use something they cannot access.

The executive exception

When a founder or an executive uses a personal account, the policy is functionally void for everyone below them, and the staff notice long before the auditor does. It is also the highest-value account to compromise, and it usually holds the board pack. The only workable answer is the same one that works for privileged system access at small companies: no informal exemption, a documented exception if there is genuinely a reason, and someone independent enough to raise it — an audit committee member, a non-executive director or an external advisor — who sees the exception register.

Works councils and employee-representation constraints

In parts of the EU, deploying monitoring that observes employee activity is a co-determination matter and cannot simply be switched on because a licence includes it. That is a genuine constraint on the middle rows of the detection table, not an excuse. It also argues for the design this page recommends anyway: aggregate first, name people only on escalation, and spend on the sanctioned path before you spend on surveillance of the unsanctioned one. Consult before you deploy, not after somebody finds the extension.

The auditor asks about a control you cannot test everywhere

A control described as blocking personal AI accounts, tested against an estate where 30 per cent of access comes from unmanaged devices, is a control with a hole the auditor will find. Describe it accurately instead — the technical control operates on managed devices, the policy and contractual control operates across the population, and the exception register captures the difference. A narrower control described precisely tests clean. A broad control described loosely produces an exception on your own words.

Where you need a named owner for this whose job is not also to be the person using the tools, that is what a fractional CISO or DPO engagement is for. Where the question is which AI uses need an impact assessment at all, start with risk assessment versus impact assessment and the roles an organisation can occupy.

From the other side of the table

What buyers push back on and the answer

These seven now appear in most enterprise security reviews, and they are increasingly asked by procurement rather than by security. The difference between a good answer and a defensive one is specificity — and, in two of them, a willingness to describe a limit rather than imply coverage you do not have.

"How do we know your staff are not putting our data into a personal ChatGPT account?"

You cannot answer this with a guarantee, and a vendor who offers one is telling you something about their control environment rather than about their staff. The answerable version has four parts: the data classes that are prohibited from any AI tool and how they are defined, the sanctioned tools and the contractual terms behind them, the technical controls on managed devices and their stated scope limits, and the disclosure route with the incident record it feeds. Adding the fifth part — the exception register and what is currently in it — usually ends the thread, because a buyer reading a register of six bounded exceptions is looking at a working system rather than a claim.

"Do you monitor employee AI use?"

Expect this question from both directions, sometimes in the same review. A security team asks it hoping the answer is yes, while a privacy or employment-side reviewer asks it hoping the answer is proportionate. The response that survives both is specific about granularity: what is collected, at what level of aggregation, who can see it, what triggers an escalation to naming an individual, how long it is retained and where it is disclosed to staff. Answering with a product name tells them nothing. Answering with a data-collection description tells them everything they came to find out.

"Your policy allows exceptions. What stops the exception becoming the rule?"

Three properties, and they are the same three that make any exception process testable. Every exception carries an expiry date on the day it is granted. Every exception is approved by someone other than the requester. And they are recorded in a register that is reviewed on a stated cadence, so the pattern is visible — twenty exceptions for the same missing capability is not an exception process failing, it is a product gap the register has correctly surfaced. Offering the register’s current contents, rather than describing the process in the abstract, is what makes this answer land.

"You disclosed a shadow AI incident during the period. Why is that not disqualifying?"

Because the alternative reading is that a vendor with no disclosed incidents has no detection. A thoughtful reviewer weighs how it was found, how quickly it was contained, whether the scoping was honest about what could not be established, whether the notification decision had a recorded basis and an author independent of the person involved, and whether the remediation changed a cause or restated a rule. An incident found by finance and closed by extending seats to the group that had none is a better story than a clean period with a policy nobody could have complied with.

"We require that no customer data touches any LLM."

Establish first whether that is a hard contractual gate or a questionnaire default, because the two get very different answers. If it is contractual, it is a scoping conversation: which processing genuinely involves their data, whether it can be excluded from AI-assisted workflows, and whether the commitment can be written narrowly enough to be true — a commitment you cannot evidence is worse than a negotiation you found uncomfortable. If it is a questionnaire default, the useful counter is the specific one: here are the tools, the contractual terms, the retention position and the control that was tested.

"Is your AI vendor a named sub-processor in our DPA?"

A fair question with a mechanical answer, and one where the shadow AI problem shows up in a form legal teams recognise. Your sanctioned vendor either is or is not on your sub-processor list, and if their processing touches your customers’ personal data it should be. A personal account cannot be on that list at all — the contract is between the vendor and your employee, and your organisation is not a party to it. That is the clearest way to explain to a commercial audience why a personal account is a different category of problem rather than a smaller version of the same one.

"What happens if an employee’s personal AI account is compromised?"

Say the true thing: you would have no telemetry, no admin console and no ability to enumerate what was in it, so your detection would depend on the vendor notifying the individual and the individual notifying you. That is exactly why the containment strategy is to keep company material out of those accounts rather than to secure them, and why the disclosure channel is a control rather than a courtesy. A vendor who describes that dependency plainly is more credible than one who implies coverage they do not have.

How these land in a written questionnaire rather than a call is covered in SOC 2 and security questionnaires.

Frequently Asked Questions

What is shadow AI?

Shadow AI is the use of AI tools and accounts for company work outside the tools your organisation has approved and administers — most commonly a personal ChatGPT, Claude or Gemini account, but also unapproved team subscriptions, browser extensions and locally installed assistants. The word shadow refers to visibility rather than intent: the defining property is that your organisation cannot see it, govern it, retain or delete what went into it, or bound what was exposed if something goes wrong. It is the AI-era instance of shadow IT, with one important difference — the barrier to entry is a browser tab and about twenty dollars a month.

Is an employee using a personal ChatGPT account for work a security incident?

It depends on what went into it, and that question has to be answered before the classification. If the content included customer data under a confidentiality commitment, personal data, credentials or regulated material, then yes — it is at minimum an unauthorised disclosure and potentially a reportable one, and your incident process should run. If the content was a public blog draft or a piece of generic code, it is a policy deviation to be recorded and corrected. What is not acceptable is deciding which of those it was without scoping, or letting the person who made the disclosure make the classification. Record the decision and its basis either way.

Should we just ban personal AI accounts outright?

A ban on personal accounts as such is unenforceable, because you cannot see personal accounts on personal devices, and a rule everyone knows is unenforced weakens every other rule in the document. The enforceable version prohibits the act rather than the account: named data classes must not be entered into any AI tool outside the approved list, whoever owns it and wherever it runs. That version is testable, it does not require you to police anybody’s private life, and it survives the obvious challenge of an employee using AI at home on their own time for their own purposes.

How do we detect shadow AI without reading employees’ prompts?

Start with the signals that cost nothing in privacy terms. Expense claims and corporate card records for personal AI subscriptions find more real shadow AI than most security tooling. Sanctioned-tenant usage analytics give you the negative signal — who has a seat and never uses it, whose usage falls without their output falling, which teams were never issued seats. DNS or egress telemetry on managed devices adds volume and destination without touching content. Inline content inspection sees prompts, but it carries the highest privacy cost, is defeated by unmanaged devices, and in parts of the EU it is a works-council matter rather than a configuration choice.

Is there a SOC 2 control for shadow AI?

There is no criterion named for AI, and there does not need to be. The behaviour lands squarely on existing criteria: CC6.7, which requires the entity to restrict the transmission, movement and removal of information to authorised users and processes, is the closest fit and the one most auditors will reach for. CC6.8 covers unauthorised software where local tools and extensions are involved, CC9.2 covers the vendor risk in the sanctioned tool, CC5.3 and CC2.2 cover the policy and its communication, and CC7.2 through CC7.4 cover detection and incident response. Where Confidentiality is in scope, the criteria on identifying and disposing of confidential information apply as well.

Does ISO 42001 require us to manage shadow AI?

ISO/IEC 42001:2023 is an AI management system standard, certifiable by an accredited certification body, and it requires an organisation to define its AI policy, assign roles and responsibilities, and control how AI systems are used within the organisation — its Annex A reference controls include AI policy, internal organisation and the use of AI systems. Unmanaged personal-account use is, in management-system terms, AI use that falls outside your defined scope and controls, so it surfaces during certification as a gap between what the system claims to govern and what is actually happening. Do not attempt to cite specific Annex A control numbers from a summary. Read the standard.

What do we tell a customer who asks whether their data went into a personal AI account?

Tell them what you can establish and be explicit about what you cannot. A good answer names the sanctioned tools and the contractual terms behind them, states the prohibited data classes, describes the technical controls and their scope limits — including honestly that unmanaged devices are outside technical enforcement — and points at the disclosure route and the incident record it feeds. If an incident occurred and touched their data, tell them, with the scope, the decision and the remediation. The answer that damages a relationship is not a disclosed incident. It is a confident assurance that later turns out to have been unverifiable.

Can we require an employee to delete conversations from their personal account?

You can ask, and most people comply immediately. You cannot verify it, you have no admin path to it, and you should be careful about asking before you have scoped, because deletion destroys the only record of what was exposed and may be prohibited outright if a litigation hold or a regulatory duty applies. Whether deletion is even available, and what it actually removes across caches and backups, varies by product and by plan tier and changes over time — check the vendor’s current documentation rather than assuming. Record what you asked for, what was done, and what you could not confirm.

What should an AI acceptable-use policy actually contain?

Six things, each of which makes something testable. Named prohibited data classes rather than the word confidential. A list of approved tools with a named owner and a stated review cadence. An exception route with an approver by role and a service level, producing time-bounded exceptions in a register. A monitoring notice stating what is collected, at what granularity, who sees it and how long it is kept. A disclosure clause that distinguishes a promptly reported mistake from concealment, and means it. And a scope statement that says where technical enforcement applies and where the control is contractual instead.

What do we do about contractors who cannot be given an enterprise seat?

This is the largest unmanaged population in most organisations and the one most policies quietly ignore. There are two workable routes. Issue them a seat under the same identity provider as everyone else and treat the licence cost as part of the engagement — usually cheaper than the tooling proposed to monitor them. Or write the prohibited data classes and the approved-tool list into the contract itself and accept that you are relying on a contractual control rather than a technical one, which is a defensible position provided you describe it that way to your auditor. What fails is a policy binding employees only, in an organisation where a large share of system access is not held by employees.

Written By Expert Auditors

Surendra Pal SinghChief Information Security Officer & Data Protection OfficerCISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi ChauhanLead AuditorISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Last reviewed: August 2026 • Content verified by certified lead auditors

Keep Exploring