Overview

Organizations that are SOC 2 audited, hold ISO 27001 or process personal data for customers in the EU all get to the same question once the teams want to use AI. Can we? And if we can, how do we do it without failing the next audit or having to write a breach notification?

My answer is yes. None of these frameworks stops an organization from using AI. They ask the same seven things of an AI system that they ask of any other system:

  • Does it exist in the inventory?
  • What data does it touch, and where does that data go?
  • Who is the vendor, and what does the vendor do with the data?
  • Who can reach it?
  • What did it do?
  • Who is accountable for it?
  • Can we show all of that working over time?

SOC 2, ISO 27001, GDPR and the EU AI Act each have their own vocabulary for these seven, and I go through where each one writes them down in What the frameworks ask for.

What is new with AI is where the model sits in the data flow, how easy it is for a well-meaning colleague to send confidential data through a consumer tool, and how fast the vendors and the regulations move.

This post covers how I think and engineer around the frameworks when AI is in scope, and what I think matters most for four teams: the colleagues who use AI in their work, the engineers who build with it, operations, and the business that carries the whole compliance picture.

I am not a lawyer. Where I describe a regulation I link the primary text and say how I read it.

In this post:

My experiences

From around 2018 I stepped further into leadership, and the compliance side of security came with that. I have worked a lot with SOC 2 Type II, ISO 27001 and GDPR since then, and the EU AI Act is now on the same list. I write from the side of the table that builds and runs the product and then has to show the evidence.

In recent years, especially since the exponential increase in AI use with generative AI, compliance audits require more robust controls and reports for how AI is used within an organization. I’ve been part of doing these audits together with the auditors, as well as strengthening the organizational compliance posture and understanding to ensure a smooth audit process. For me, AI was first in scope in an audit in the last 1-2 years, and it’s increasing. Previously it might’ve been a nice-to-have, but now it’s something most frameworks and auditors expect you to be able to answer and show evidence of.

In past years, I wrote about the readiness side in Establish your organizational compliance readiness and about the engineering side in Embrace a Secure Software Development Lifecycle (SDLC) for Azure. Both still hold, and neither mentions AI.

I also run coding agents on real codebases, which I write about in my agentic AI engineering series. The opinion from that series I lean on here is that an instruction is a request until something can deny it, which I argue in Why instructions aren’t enough for coding agents. Auditors treat a policy with no evidence behind it the same way.

The incidents that make all of this urgent are in AI security engineering: the same failures, but new ways to attack, and I do not repeat them here.

What the frameworks ask for

So, looking at some of the common frameworks, it helps me to strip each down to what they ask about an AI system. Start small and then expand, or ‘less is more’ as we used to say at Microsoft.

Five cards, one per framework, each marked with what kind of rule it is and what it asks for. SOC 2 Type II is an attestation and asks for risk assessment, access control, change management and vendor management. ISO/IEC 27001 is a certifiable standard and asks for an asset inventory, classification, supplier and cloud review, and logging. GDPR is law and asks for a processor contract, an impact assessment, limits on automated decisions, and erasure. The EU AI Act is law and asks for AI literacy for staff, telling people when something is AI, and extra duties for high-risk uses. The NIST AI RMF is voluntary guidance with four functions: Govern, Map, Measure and Manage. Arrows lead from the first four cards to one panel with the seven questions they all ask about an AI system: is it in our inventory, where does the data go, what does the vendor do with the data, who can reach it, what did it do, who is accountable for it, and can we show it working over time.

SOC 2 Type II. I read the Trust Services Criteria as applying to an AI system the way they apply to any other system. They ask me to assess risk (CC3), control logical access (CC6), manage change (CC8) and manage vendors (CC9.2), and to show those controls operating over the audit period. For an AI system that means the model provider is a vendor, a prompt change is a change, and an agent is a logical access path. The auditor then asks to see each control working on dates they pick from the audit period.

ISO/IEC 27001:2022. ISO/IEC 27001:2022 has a similar shape, with the controls named in Annex A:

  • Inventory of information and other assets in 5.9.
  • Classification and labelling in 5.12 and 5.13.
  • Supplier relationships and cloud services in 5.19 to 5.23.
  • Privacy and protection of personal data in 5.34.
  • Logging in 8.15.
  • Secure development, change management and test information in 8.25 to 8.33.

The AI system goes into the asset inventory, the risk treatment plan and the Statement of Applicability like anything else. ISO/IEC 42001:2023 is the separate management system standard for AI, for organizations that want an AI-specific certificate. As I read it, it follows the same management system structure as ISO 27001 and adds an AI system impact assessment and controls for the AI system life cycle.

I see many organizations in the AI-space now starting to highlight their ISO 42001 compliance certifications, which is another signal to me that it’s important to keep your eyes on.

GDPR. I’ve spent significant time in the GDPR when AI is in scope, because these parts need a new answer once a model is in the data flow:

  • Article 5. Purpose limitation and data minimisation are my test for whether a piece of data should go to a model at all.
  • Article 28. When the model provider processes personal data on my behalf it is a processor, so there has to be a contract, and its sub-processors need the same obligations. If I am a processor myself, the model provider becomes my sub-processor. My customers must have authorised that, and under a general authorisation they have to be informed of the addition and given the opportunity to object.
  • Article 35. A data protection impact assessment (DPIA) is required when processing, “in particular using new technologies”, is likely to result in a high risk. You should assume that generative AI on personal data needs one until your privacy officer has assessed it and says otherwise.
  • Article 22. People have the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects on them. I write down where that line is before HR or sales gets near it.
  • Chapter V. The region of the model endpoint is a transfer question.
  • Article 30. The processing goes into the records of processing.
  • Article 17. The right to erasure is hard to honor once personal data sits in a vector index, a cache, a log or a fine-tuned model. The EDPB’s Opinion 28/2024 from December 2024 looks at when an AI model can be considered anonymous, and the EDPB’s summary is that this “should be assessed on a case by case basis”. So I do not assume that a model trained on personal data is out of reach of an erasure request.

The EU AI Act. The AI Act is risk-based, and as I read it most workplace uses of AI fall outside the high-risk tier. Article 5 bans a short list of practices outright, such as social scoring and inferring emotions in the workplace, and has applied since 2 February 2025. Beyond the bans, three parts apply to almost everyone:

  • Article 4, AI literacy. It has applied since 2 February 2025 and covers staff and anyone else who operates or uses AI systems on the organization’s behalf. The EU amended the AI Act in July 2026 with a regulation called the Digital Omnibus on AI, and it rewrote this article. Providers and deployers now have to “take measures to support the development of AI literacy”, and the article says this does not require them to guarantee any specific level of AI literacy for any individual.
  • Article 50, transparency. It has applied since 2 August 2026 and covers telling people that they are interacting with an AI system, marking AI-generated content and disclosing deep fakes. Generative systems that were already on the market have until 2 December 2026 to mark their output.
  • Annex III, high-risk uses. Point 4 lists employment: recruitment and selection, decisions on promotion and termination, task allocation based on behaviour or personal traits, and monitoring and evaluating performance. HR is the department I expect to reach the high-risk tier first, often without knowing it. The Digital Omnibus moved the high-risk obligations for Annex III uses from 2 August 2026 to 2 December 2027. From that date, Article 26 requires an organization that uses such a system, which the Act calls a deployer, to assign human oversight to people with the competence and authority for it and to keep the system’s logs for at least 6 months. An employer also has to inform workers’ representatives and the affected workers before using such a system at the workplace.

Two more dates are on the timeline below. The obligations for providers of general-purpose AI models have applied since 2 August 2025, and as I read them they sit with the company that provides the model and not with an organization that only uses it. High-risk AI that is built into regulated products such as medical devices follows on 2 August 2028. Article 99 sets the fines: up to EUR 15 million or 3% of worldwide annual turnover for breaking the transparency obligations in Article 50 or the deployer obligations in Article 26, and up to EUR 35 million or 7% for a prohibited practice.

A timeline of five EU AI Act dates, each with the rule in plain words and what an organization needs. 2 February 2025, applies now: some uses are banned, such as social scoring and reading emotions at work, and staff get support to understand AI. What you need: a check that none of your uses is on the banned list, and AI training with a record of it. 2 August 2025, applies now: duties for the companies that provide general-purpose AI models, with nothing new if you only use a model. 2 August 2026, applies now: people are told when they talk to an AI system, AI-generated content is marked and deep fakes are disclosed. What you need: a chatbot you offer says that it is an AI, and content your tool generates is marked, by 2 December 2026 for tools already on the market. 2 December 2027, still ahead and moved from 2 August 2026: high-risk uses such as hiring and evaluating staff, education and credit scoring. What you need: trained people who oversee the system, its logs kept for at least 6 months, and workers informed before it is used. 2 August 2028, still ahead and moved from 2 August 2027: AI that is a safety part of regulated products such as medical devices and toys. A bar at the bottom gives the fines in Article 99: up to EUR 15 million or 3% of worldwide annual turnover for breaking the rules on telling people it is AI or on using high-risk AI, and up to EUR 35 million or 7% for a banned use. The EU AI Act dates as they stand in November 2026. This is my reading of the law and not legal advice.

NIST AI RMF. The AI Risk Management Framework from January 2023 and its Generative AI Profile from July 2024 are voluntary guidance and not regulation. If you need a structure for an AI risk assessment, their four functions, Govern, Map, Measure and Manage, are a reasonable place to start. My own work has been with SOC 2 Type II, ISO 27001 and GDPR, and I include the AI RMF here because it is written for AI risk specifically. I covered the older NIST, MITRE and CISA material in Frameworks to strategically improve your cybersecurity.

Sector regulation adds its own layer. DORA has applied to financial entities since 17 January 2025, and NIS2 covers essential and important entities. Under both I would treat the AI vendor as an ICT third party, and I do not go further into them here.

Put side by side, I read the same seven things out of SOC 2, ISO 27001, GDPR and the EU AI Act:

  • An inventory
  • A data flow
  • A vendor review
  • Access control
  • Logging
  • An accountable person
  • Evidence over time

How I think and engineer around the frameworks

In the last year, several organizations I’ve spoken with are curious about how, or where, to start with compliance work for their AI efforts. It’s not always easy to get started, but here’s my initial line of thinking based on my experiences.

Each of the seven questions is an engineering problem with a known answer. This is what I build, in the order I build it.

I build the register first. It is one list of every AI system in use or in development: owner, purpose, data classes, vendor, deployment class, risk tier, whether it has a DPIA, and the date it was last reviewed.

Today, I also assume AI is already in use before anyone formally adopts it, so the register starts with finding out what is there. AI features inside tools we already use go on the list too, because a vendor that turns on an AI feature changes the data flow without anyone buying anything. The register feeds the asset inventory, the Statement of Applicability, the records of processing, the vendor list and the risk register, and it is the first thing I would show an auditor.

The policy starts from the data and not from the tools. The second artifact is a table with the data classes down the side (public, internal, confidential, personal data, special category) and the deployment classes across the top (consumer tool, enterprise tenant with a DPA and no training, private deployment in our own region). Every cell says yes, no, or yes with a condition. Once the table exists, most questions of the form “can we use tool X for Y” can be answered from it, and the policy fits on one page. So, for an inventory - always start digging from the data, not the tools.

A table with five types of data down the side (public, internal, confidential, personal data, special category) and three kinds of AI tool across the top: a consumer tool on a personal account, an enterprise tenant under a contract, and a private deployment in our own cloud and region. Each cell holds a Yes, No or Conditional pill with a one-line condition under it. Public data is a yes everywhere, the consumer tool is a no for everything else, and special category data is a no for the enterprise tenant and conditional for a private deployment. A line under the table names what a fuller table adds: the region, how long the vendor keeps the data, whether the tool can act on its own, and who approves an exception. A simplified example of a first table: which type of data may go into which kind of AI tool. Every organization fills in its own cells, and a fuller table also covers the region, how long the vendor keeps the data, whether the tool can act on its own, and who approves an exception.

The rest of this section follows one question from a user to an AI assistant in the product. The assistant looks up documents, calls a model at a provider, and can then take an action. These are the technical controls I put at each step:

A flow of six steps for one question from a user to an AI assistant, each with its technical control. 1, the user asks: single sign-on, so it is an approved tool and a known person. 2, the assistant runs: its own identity with minimal access, expiring credentials and no shared keys. 3, it finds documents: a permission check, so only documents the user may open go into the prompt. 4, it calls the model: a fixed endpoint set in code, with a company contract, one region and no consumer fallback. This is the only step outside our own systems, at a provider under contract. 5, the answer returns: the output is checked against a schema before it can trigger anything. 6, it takes an action: a person approves anything that cannot be undone. Every step writes to one log that the application cannot edit, with personal data removed before it is written. Below, the four audit questions these controls answer: who can reach it, where does the data go, what did it do, and can we show it over time.

I treat the model provider as a processor, in the contract and in the code. The contract side is a DPA, a no-training clause, retention terms, a sub-processor list and a region commitment. The code side makes it impossible for the application to reach any other endpoint: an allow-list of hosts, the enterprise endpoint pinned in configuration, and no fallback to a consumer endpoint when the enterprise one is down. A commitment that exists only in the contract is the same kind of request I described in Why instructions aren’t enough for coding agents, so I back each one with something in code that an auditor can test.

Every AI component gets its own identity with the least access that works. An agent or an AI feature is a non-human identity. It gets its own principal, scoped to the resources the work needs, with short-lived credentials and no keys shared with humans or other environments. I described the fence I use for my own coding agents in Read-only MCP servers by default, and never run as my own identity. I read the access controls in Annex A and the logical access criteria in SOC 2 as asking for the same design.

The model is not an access control. If a retrieval step can read a document, the model can quote it to whoever asks. So I trim permissions at retrieval, against the source system’s own access list, before anything reaches the prompt.

Logging is the evidence, so I design it as evidence. The log holds the prompt, the retrieved context, the tool calls, the output, the model and version, the identity that ran it, the time, and the person who approved anything irreversible, written to a store the application cannot edit. I think personal data and other sensitive information should be scrubbed before it enters any system or log, and I wrote up one way to do that in Redacting sensitive information with Application Insights in C#. Retention follows the retention schedule, which also makes the log a place that erasure requests have to reach.

Logging is, of course, also a separate topic we could dive a lot deeper into. I have both pseudonymization and redaction of various data flying into logs, but then also retention differences depending on which type of logs we’re talking about. Your compliance framework reports and audits, and your internal policies, will control how many days you need to persist each type of log, and what goes in there. So if you’re relying on logging for evidence-based data when auditors show up, you need to ensure the retention is also configured at the right levels so you know the data will be available. For example, default retention in Azure Log Analytics that I work a lot with will expire before a typical default template for ISO 27001/SOC 2 would claim - so that’s your job to align, too.

Prompts and models are code, and a model change is a change. Strange statement in a way, but a system prompt lives in source control and goes through review. A model version is pinned, and a new version goes through change management with an evaluation set as the regression test. Hopefully. When a provider deprecates a model, I want to handle it as a supplier change with a risk assessment. Sometimes that assessment can be very brief, but making a note and decision around it and getting that logged helps with your upcoming audits, so the most current models are always part of your most current risk register.

A human sits where the regulation requires one and where the blast radius is large. Article 22 and the high-risk tier say where the law wants a person. For everything else I use the hard lines from What the humans do, what the agents do, and where the hard lines are, which stay with me and never with the agent. The approval gate has to hold. Microsoft’s AI Red Team reported in June 2026 that human-in-the-loop bypass was the failure mode they saw exploited most consistently.

The DPIA is per use case, and it has to be kept current. Article 35 is about processing operations, and it allows one assessment for “a set of similar processing operations that present similar high risks”. So the unit is the use case and not the tool. Summarizing support tickets and screening job applicants with the same tool are 2 processing activities with 2 risk profiles. Article 35 also asks for a review when the risk changes, and a new model, new data or a new purpose are the changes that should trigger one. You should link each assessment from the register.

What matters most for each team

The frameworks apply to the whole organization, and each team needs something different from me in a typical organization. I think a lot of AI governance fails because everyone gets the same long policy document. We need to split it down and delegate responsibilities as applicable, and it helps having a single person responsible for specific tasks or outcomes, not an entire group of people.

Working with compliance over the years, whether AI or not, here are the four main internal teams/groups I would bring along at various altitudes across the AI adoption and compliance transformation.

Four cards side by side for the teams Adopters, Engineers, Operations and Business. Each card has a key takeaway, what the team needs from you and what the team owns. Adopters: make the approved tools the easiest ones to reach. They need a short list of approved tools for each type of data and answers about a new tool within days. They own what they send, checking AI output before it goes out, and asking before they use a new tool. Engineers: back every promise in the contract with a test in code. They need the table of which data may go into which kind of AI tool and the contract terms. They own a data flow diagram for each AI feature, an identity for each AI component, a log that can replay what the system did, and deletion that reaches indexes, caches and logs. Operations: handle an AI tool like any other system and vendor. They need the register of AI systems and to be asked before the first high-risk use. IT owns sign-on and admin settings, HR owns AI in hiring and evaluation and the training record, legal owns a DPIA for each use case and the vendor contracts, and security owns AI systems in the incident response plan. Business: name one owner and keep one register of AI systems. They need AI risk reported the way any other risk is reported and one true answer for customer questions about AI. They own a named accountable person, a one-page policy and a written risk appetite, evidence collected from before the audit period starts, and a rehearsed incident with an AI system in it.

Let’s break them down:

Adopters: For the people using AI in their work

  • A short yes-list instead of a long no-list. Which tools are approved, for which data classes, with the links to open them. If the approved tool is harder to reach than a browser tab, people use the browser tab, and a policy does not change that.
  • What the tool does with their data, in 3 sentences. Is it retained, is it used for training, and who inside the company can see the history. I think people make better decisions when they know this than when they have to guess.
  • AI literacy that is about their job. Article 4 asks for measures here, and I would not spend them on a course about transformers. The useful version shows what a hallucinated citation looks like in their field, what an instruction hidden in an email or a web page can make an assistant do, and when to verify before sending.
  • Clear ownership of output. The person who sends the document, the code or the email owns it, whichever tool drafted it. Writing that down settles most questions about accountability.
  • A fast way to ask. A question about a new tool that gets an answer within days keeps people inside the approved tools. If the answer takes a quarter, people stop asking.

Engineers: For the engineers building with AI

Most of what engineers need is in How I think and engineer around the frameworks. These are the parts I would add for the team that builds the feature:

  • One data flow diagram per feature. What leaves the boundary, to which endpoint, in which region, under which contract, and what comes back. I expect it to be the first artifact an auditor or a privacy officer asks for, and drawing it is how an unintended fallback to a consumer endpoint gets caught.
  • A test for the contract. Allow-listed endpoints, a pinned enterprise deployment, a pinned region and no silent fallback, each with a test that fails when it changes.
  • Output handling. Anything the model returns is validated against a schema before it reaches a privileged action, because raw model output is untrusted input. An agent that holds private data, reads untrusted content and can send data out has what Simon Willison calls the lethal trifecta, and taking away any one of the three stops that attack.
  • A replay that has been tested. If I cannot reconstruct what the system did on a given request, I do not have the control.
  • Deletion that reaches everywhere. Vector indexes, caches, logs and fine-tuned models. If an erasure request cannot be honored against one of them, that store needs a retention limit or a different design.
  • Supplier changes are our changes. A deprecated model, a new sub-processor or a changed retention term each goes back through the assessment.
  • IT owns the switches: single sign-on on every AI tool, the tenant-level admin controls the vendors provide, data loss prevention rules that cover pasting into a chat, device policy for local agents, and a procurement path for a new AI tool that completes in days. The AI tools go into the asset inventory and the access reviews like any other SaaS.
  • HR is closest to the high-risk tier. AI used for recruitment screening, performance evaluation, task allocation or monitoring is on the Annex III list, and from 2 December 2027 an employer has to inform workers’ representatives and the affected workers before using such a system. National rules on consulting works councils or unions can apply on top of that, so I would check them per country. HR is also where I would keep the record of the Article 4 literacy measures.
  • Legal and privacy own the DPIA per use case, the update to the records of processing, the vendor DPA and sub-processor review, the transfer mechanism, the retention schedule and the written position on Article 22. They also own the answer to “do you use AI on our data?”, which I expect in every customer security questionnaire.
  • Finance and procurement treat AI as a vendor category. Sub-processor review and DPA sign-off are part of onboarding, and consumer AI subscriptions paid with a corporate card are an early sign of tools nobody approved.
  • Security operations puts AI systems into the incident response plan. A prompt injection that moves personal data out is a personal data breach, and the 72-hour notification clock in Article 33 of the GDPR applies as it does to any other breach. Someone has to be on call for it. The register says which systems exist and the log says what they did.
  • Support and customer-facing teams need one true sentence about AI use that matches the trust center, the DPA and the product. If a customer gets 3 different answers to the same question, I would expect it to end up as an audit finding.

Business: People who need to understand the whole compliance picture

  • The register is the base for everything else. One list of AI systems, owned by a named person, feeding the inventory, the Statement of Applicability, the records of processing, the vendor list and the risk register. Without it, the scope of every other control is a guess.
  • The policy is one page and the controls do the work. The data classification table, the approved tools, the identity per component and the log are the controls. An acceptable use policy on its own is an instruction, and I do not count it as a control.
  • A named owner. One person is accountable for AI governance and reports it to leadership the way other risk is reported. I would not give this to a committee, because a committee adds waiting time to every approval.
  • A written risk appetite. Which uses are out, in plain words. For example: no automated decisions with legal effect on individuals, and no special category data to any external model. Whatever the lines are, they are easier to defend once they are written down.
  • An evidence stream that starts before the audit window. Type II means controls operating over a period. Designing the log, the register and the reviews in from the start is cheaper than reconstructing a year of evidence afterwards.
  • An answer for customer questionnaires. Enterprise buyers ask about AI in their security questionnaires. The answer has to be ready, true, and the same as what the DPA says.
  • An incident rehearsal. A personal data breach that involves an AI system has the same 72-hour clock as any other. I would run the tabletop exercise with a prompt injection scenario in it at least once.
  • Something to tell the market. Passing audits with the AI in scope is something buyers pay attention to. I would not build it for that reason, and I would still bring it up in the sales conversation.

Personal story time: I’ve been on both sides of the fence of “we need an audit yesterday” and “let’s plan ahead for the coming year”. A key takeaway, which I believe is obvious to most, is that the sooner you start planning and involving people for a compliance audit, the quicker you’ll achieve the desired outcomes. If you’re late to the game and get a request saying “We need to get ISO 27001 by [a date]”, it becomes significantly more complex to get it done. That said, I’ve been doing that and we’ve succeeded with that, too - just as we’ve done when doing audits ground-up with planning from day one. It will cost you more to get the audit evidence late, but sometimes you don’t have a choice. If I can leave you with a single recommendation here, it’s to involve someone from each group of the business and start discussing what your current and future audit requirements might look like, especially if you’ve adopted or will start adopting AI.

My checklist for AI adoption and compliance

If you are adopting AI under one or more of these frameworks, this is the checklist I would work from. The order is my suggestion for what to tackle first, and you should modify this to fit your organizational needs:

  1. Build the register. Every AI system, owner, purpose, data classes, vendor, deployment class, risk tier, assessment date.
  2. Write the data classification table against the deployment classes. Publish it as the policy.
  3. Put the approved tools behind single sign-on and make them easier to reach than the alternatives.
  4. Sign the DPAs, pin the endpoints in code, and test that the fallback to a consumer endpoint cannot happen.
  5. Give every AI component its own identity with the least access that works.
  6. Trim permissions at retrieval, validate outputs, and log everything as evidence with redaction before telemetry.
  7. Put prompts and model versions under change management with an evaluation set as the test.
  8. Do one DPIA per use case, write down the Article 22 line, and get HR and legal into the room before the first high-risk use.
  9. Train people on what goes wrong in their own job, keep the training record, and answer their questions in days.
  10. Rehearse an incident with an AI system in it, and make sure the customer-facing answer about AI matches the contract.

Final thoughts

In my view the frameworks do not block AI adoption. Adoption stalls when nobody can say which data is allowed in which tool, and the register and the classification table are how I answer that. Most of the rest is the compliance work we already do, applied to a new kind of system. The parts I treat as new are the data flow through the model and the pace at which vendors and regulators change things, and that is where I would put the extra attention. Keep your inventory, the answers to the questions, and risk register up to date, and you’ll be more prepared.

I am curious which framework gave you the most trouble once AI was in scope, and what your register looks like if you have one. Tell me on LinkedIn.