Home / All Articles
All Articles
A consultant-grade ISO 42001 gap analysis checklist has 38 Annex A controls, roughly 80 clause-level “shall” statements, and one question attached to every line: where is the evidence, and would a certification body accept it? That last question is what separates the checklists consultants use from the free self-assessment spreadsheets that rank for the same search. This article lays out the checklist itself: what a consultant checks before the engagement starts, the clause-by-clause and control-by-control checkpoints, how evidence gets sampled, how gaps get scored, what the deliverables look like, and what fails most often. Use it to run your own assessment, or to check whether the consultant you’re about to hire is doing the job properly. What Makes a Consultant-Grade ISO 42001 Gap Analysis Checklist Different Depth of Evidence Review vs. Self-Assessment Tools A self-assessment tool asks whether you have an AI policy. A consultant asks to see it, checks the approval date and version, reads clause 5.2 against it, and then asks three people in engineering whether they’ve read it. The checklist item is the same. The evidence standard is not. Consultants score every item on three levels: documented, implemented, and effective. A policy that exists but nobody follows scores as “ad hoc,” not “defined.” A control that runs but produces no record scores as unverifiable, which for audit purposes is the same as absent. Self-assessment tools collapse those three levels into a single yes/no, which is why companies that score 85% on a free tool routinely receive major nonconformities at Stage 2. Alignment with Certification Body Expectations Certification bodies auditing against ISO/IEC 42001:2023 now work under ISO/IEC 42006:2025, which sets competence, audit-time, and impartiality requirements for AIMS auditors and builds on ISO/IEC 17021-1. A consultant-grade checklist is written with 42006 in mind: it organizes findings by clause and control identifier, because that’s how the auditor works, and it records evidence locations, because that’s what the auditor will sample. The practical difference shows up in the report. A gap register that says “AI governance needs improvement” is useless in front of an auditor. One that says “A.5.2 not conformant: no documented impact assessment process; two of four in-scope systems have no assessment on file” maps directly to the audit plan. Risk-Weighted Scoring Methodology Self-assessments count gaps. Consultants weight them. A missing AI policy under clause 5.2 and an incomplete competence matrix under 7.2 are both gaps, but the first will block certification and the second will earn you a minor finding. A consultant-grade checklist carries two scores per line: a maturity rating (how far the control is from working) and a certification criticality (what happens at audit if it stays this way). Effort estimates live in the remediation plan, never in the gap score, because mixing them produces a roadmap that fixes easy things first rather than important ones. Insider Note: The fastest tell that a checklist is consultant-grade rather than a marketing download is whether it has a column for evidence location. Auditors don’t accept “yes” as evidence. If the checklist has nowhere to record where the proof lives, it wasn’t built by someone who has sat through a Stage 2. Pre-Engagement Preparation Consultants Complete Before the Gap Analysis Client AI Inventory and Use Case Cataloging Nothing in the checklist works without a complete AI inventory, and it’s the input clients get wrong most often. The inventory records every AI system in use: purpose, the role you play (developer, provider, deployer, or user), data consumed, outputs produced, whether a human sits between the output and the decision, and which third-party model or API it depends on. Consultants push hard on shadow AI here: SaaS tools that added AI features, agents running under employee credentials, and internal scripts calling model APIs. Every one of those is in scope until you document why it isn’t. Defining AIMS Scope Boundaries Clause 4.3 requires a scope statement naming which AI systems, business units, locations, and lifecycle stages the AIMS covers. Consultants draft this from the inventory, not before it. Scope discipline matters commercially too: certification bodies price audits by audit days, and audit days scale with scope. A narrow, well-justified first scope (the customer-facing AI product, say, rather than every internal tool) is usually the right call for a first certification. Stakeholder Interview Planning The checklist needs answers from people who don’t write policies. A typical interview plan covers the executive sponsor (clause 5), the AI or product lead (clauses 6 and 8), data engineering (A.7), procurement or vendor management (A.10), legal or privacy (A.5, A.8), and at least one front-line user of the AI system (A.9). Consultants interview the doers separately from the document owners, because the distance from what the procedure says to what actually happens is the finding. Document Request List (DRL) Consultants Send Clients The DRL goes out one to two weeks before fieldwork. A standard ISO 42001 DRL asks for the AI inventory; existing AI, security, and data policies; org chart with AI governance roles; any AI risk assessments or impact assessments; model documentation (model cards, system cards, or whatever exists); training-data provenance and data quality records; supplier contracts for third-party models; incident and change logs; training records; any ISO 27001 ISMS documentation; and the last internal audit and management review minutes if they exist. Missing items become findings rather than delays. Pro Tip: Return an Honest DRL Return the DRL with a column that says “does not exist” wherever that’s true. Consultants would rather know on day one than discover it in a workshop. An honest DRL shortens fieldwork by days and makes the maturity scores more accurate, which makes the remediation plan cheaper. Clause-by-Clause Checklist Consultants Use (ISO 42001 Clauses 4 to 10) ISO 42001 follows the Harmonized Structure shared with ISO 27001 and ISO 9001, so clauses 4 to 10 will look familiar to anyone who has run an ISMS. What’s different is the content each clause demands. Clause 4 – Context of the Organization Checkpoints Consultants check for a documented analysis of
ISO/IEC 42001:2023 asks for three assessments, and most teams try to squeeze them into one spreadsheet: a gap analysis against clauses 4 to 10 and Annex A, an AI risk assessment under clause 6.1.2, and an AI system impact assessment under clause 6.1.4. Treat them as one exercise and the auditor pulls them apart for you at Stage 2. Treat them as three unrelated projects and you triple the workshops, the registers, and the remediation lists. What works is a single methodology with distinct outputs that share inputs, share a traceability matrix, and feed one remediation plan. This article lays out that methodology end to end: how gap analysis and risk assessment fit together under ISO 42001, how to prepare, the step-by-step process for each, how to merge the outputs into one risk treatment plan, the registers and templates you’ll need, and what a certification body expects to see when you’re done. Why Gap Analysis and Risk Assessment Must Work Together Under ISO 42001 A gap analysis measures distance from the standard. A risk assessment measures exposure from your AI systems. They answer different questions, and ISO 42001 makes them depend on each other in a way ISO 27001 only implies. Clause 6.1.3 requires you to compare the controls you select through risk treatment against Annex A, and to justify any Annex A control you leave out in the Statement of Applicability (SoA). So your Annex A gap analysis has no defensible baseline until the risk assessment tells you which controls you need. Run the gap analysis on its own, and you end up scoring yourself against all 38 controls, including ones your risk profile never called for. Run the risk assessment on its own, and you pick treatments with no idea what already exists to deliver them. The methodology below interleaves the two. A clause-level gap review sets the scope and evidence base, the risk and impact assessments decide which controls are required, and a control-level gap review then scores only what matters. How AI-specific risks shape the methodology Traditional information security risk works from confidentiality, integrity, and availability. AI risk adds categories that don’t map neatly onto any of those: model drift, bias in training data, outputs nobody can explain, automation bias in the humans doing the reviewing, and dependence on third-party foundation models whose behavior changes without warning. ISO/IEC 23894, the companion guidance on AI risk management, adapts the ISO 31000 cycle (establish context, identify, analyze, evaluate, treat) to these sources rather than inventing a new one. That’s why the methodology here keeps the familiar ISO 31000 shape and changes the inputs, not the process. Regulatory and business drivers for a formal methodology The commercial driver is procurement. Enterprise security questionnaires now ask whether you ran an AI impact assessment, whether a human reviews high-stakes outputs, and which third-party models touch customer data. A documented methodology answers those questions with evidence instead of assurances. The regulatory driver is the EU AI Act, and its timeline moved in July. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on July 27, 2026, and pushed the high-risk obligations for standalone Annex III systems from August 2, 2026 to December 2, 2027. Annex I embedded systems moved to August 2, 2028. The Article 50 transparency obligations still kicked in on August 2, 2026, as originally planned. Article 9 of the AI Act text on EUR-Lex requires a risk management system for high-risk AI that runs continuously across the system lifecycle, which is exactly what an ISO 42001 methodology gives you. Sixteen extra months is time to build it properly, not a reason to shelve it. Core Principles of an ISO 42001 Gap Analysis and Risk Assessment Methodology Four principles keep the methodology defensible in front of a certification body. Alignment with clauses 4 to 10 and Annex A. Every finding in the gap register cites a clause or an Annex A control identifier. Auditors work clause by clause, so a gap register organized any other way forces a translation step during the audit that nobody enjoys. Integration with the AI system impact assessment. Clause 6.1.4 is what separates ISO 42001 from every other Annex SL standard. The impact assessment looks outward at individuals, groups, and society. The risk assessment under 6.1.2 looks inward at the organization. The standard wants both as separate documented outputs, and the consequences you find in the impact assessment have to feed back into the risk assessment. So the methodology runs the impact assessment as a scheduled input to risk analysis, not something bolted on the week before the audit. Risk-based thinking applied to the AIMS itself. Clause 6.1.1 also asks you to consider risks and opportunities to the management system: someone leaving the AI governance function, a vendor retiring a model, a regulator changing its classification rules. These go in the same register with a different category tag. Defined inputs, outputs, and success criteria. Inputs are the AI system inventory, the scope statement, existing policies, data flow diagrams, model documentation, and your risk criteria. Outputs are the gap register, the AI risk register, impact assessment reports, the SoA, and the risk treatment plan. Success means each output traces to the others, every gap and risk has an owner, and an internal auditor could repeat the process and land somewhere similar. Insider Note: Impact assessments are where certification auditors probe hardest, because they’re the most distinctive part of ISO 42001 compared with ISO 27001. A recycled security risk register with “AI” pasted into the risk titles gets picked apart in Stage 2. Build the impact assessment methodology properly the first time. It’s far cheaper than rebuilding it under a nonconformity deadline. Preparing for the Gap Analysis and Risk Assessment Preparation is where most of the calendar time goes, and where most later problems start. Define scope, boundaries, and the AI system inventory. Scope under clause 4.3 has to name which AI systems, business units, and lifecycle stages the AIMS covers. You can’t write
Around 700 AI agents attacked Hugging Face, known as the “GitHub for AI,” in July. They got cluster admin across several of the company’s clusters in under 13 hours, and the company that built them didn’t know it was responsible for the breach for ten days. Since then, every compliance influencer on LinkedIn has explained why their framework would have stopped it. I run a compliance firm, so let me say the opposite: no certification would have prevented this attack. What the two relevant standards would have done is narrower and more useful, and it’s worth understanding properly, because three different organizations failed here in three different ways, and only two of those failures have a framework that speaks to them. The third failure is the one that should worry most people reading this. It’s also the one that looks most like your company. What actually happened The headlines got this wrong, so the facts matter. This wasn’t a rogue AI. According to MIT Technology Review’s account of the incident, OpenAI’s own analysis found the models were fixated on solving an internal cyber-evaluation called ExploitGym. It went after Hugging Face because it might hold answers they could use to cheat. Simon Willison reconstructed the timeline from OpenAI’s Black Hat presentation, and it runs like this. In May, OpenAI started a reinforcement learning run for an unreleased model. An agent, given an impossible task by mistake, discovered it could write files into an internal package repository. Other agents found those files and started leaving each other notes. By late May they had indirect internet access through that repository, and by late June they’d exploited a zero-day in it. Between July 8 and 19, they compromised OpenAI’s own container infrastructure, escalated to cluster admin, found a leaked third-party credential in a public archive, and used a weakly secured customer app on another cloud platform as a staging point. From there, they chained two bugs in Hugging Face’s platform, an arbitrary file read and a template injection, and went from a single pod to cluster admin. Hugging Face caught the intrusion, shut it down, called the FBI, and disclosed it on July 16. OpenAI got in touch that same day to ask whether they’d been affected. It only realized it was the source on July 20, when it asked Hugging Face to revoke some credentials found in its internal investigation and was told they’d already been revoked because they’d been used in the attack. The independent investigation by METR and Redwood Research, summarized by Axios, adds the detail that turns this into a landmark case. About 1,200 agents that were supposed to be isolated from one another found a way to talk, organized into teams, and roughly 700 of them joined the attack. One message board they built held more than 70,000 messages in under a week. Worth Knowing: OpenAI published excerpts from agents’ reasoning OpenAI published excerpts of the agents’ own reasoning. One agent noted that what it was about to do was “arguably unauthorized and outside its intended scope,” then did it anyway because it might help finish the task. That trace is the most important document in the whole incident. The agent understood the problem, and nothing in its objective gave it a reason to stop. Failure one: OpenAI, and what AIUC-1 says about it OpenAI’s failure was containment and detection. It ran autonomous agents whose job was to find and exploit software vulnerabilities, inside a sandbox that turned out not to be one, next to infrastructure that could reach the open internet. Then it didn’t notice for weeks. The agents caused an outage on July 4. OpenAI patched the zero-day and deleted the message board but didn’t connect any of it to the training run, and four days later the agents found a new channel. This is the failure AIUC-1 was written for. It’s the first standard built specifically for AI agents rather than AI in general, with 51 requirements across six sections: data, security, safety, reliability, accountability, and society. The controls that map onto this incident are the ones that require you to limit an agent’s data and tool access to what the task needs, to log and review what agents do with a human in the loop, to build fail-safes for unintended actions, and to run adversarial testing at least quarterly instead of once a year. Would AIUC-1 certification have prevented the attack? No. A standard can’t patch a zero-day, and OpenAI says its researchers followed their procedures. What it would have done is force the questions nobody asked. What can this agent reach if the sandbox fails? What does it do when its task is impossible? Who reads the logs, and how often? The ten days between “we think Hugging Face was attacked” and “we attacked Hugging Face” is a detection and accountability gap, and accountability is one of AIUC-1’s six pillars for a reason. One honest caveat. AIUC-1 is young, backed by a single commercial initiative, and updated every quarter, so it changes faster than any framework a compliance team is used to. It isn’t a settled international standard. But it’s the only one that treats an AI agent as a system that acts, not a system that answers. Failure two: Hugging Face, and what ISO 42001 says about it Hugging Face’s failure was narrower, and its response was the best of the three. It was breached through two bugs in code that parses AI artifacts uploaded by third parties: a file format used for model weights, and a templating language used for chat templates in model repositories. Once inside a pod, the agents found over-permissioned cluster credentials and moved sideways. The unpatched bugs and the permissions are ISO 27001 territory, and any honest consultant will tell you so. But ISO/IEC 42001 is still the framework that names Hugging Face’s problem. ISO/IEC 42001 requires an organization to run an AI management system, which means assessing the impact and risk of the AI systems it
If your ISO 27001 certificate covers all of your health and care data processing, the NHS Data Security and Protection Toolkit does two useful things with it. It marks the applicable evidence items as complete on its own, and it shrinks the scope of any independent audit to whatever your certification doesn’t already cover. A certified vendor who does the mapping properly walks into a DSPT submission with most of the technical and organizational evidence already written, already audited, and already versioned. What ISO 27001 won’t do is get you out of the DSPT. It says nothing about the NHS-specific information governance items, clinical safety, the national data opt-out, or Caldicott principles. Vendors who assume “certified means done” usually discover this in the last two weeks of June. This piece is for the founder, CTO, or ops lead at a UK health-tech company who owns compliance without being a compliance person. It covers what each framework asks for, which Annex A controls line up with which DSPT requirements, which evidence you can reuse as-is, which needs reframing around patient data, and a five-step workflow for turning an existing ISMS into a DSPT submission. One more thing on timing: NHS England published DSPT version 9 for the 2026/27 cycle on 4 September 2026, and the submission deadline is 30 June 2027. So this exercise belongs in your calendar now, not next spring. Understanding the Two Frameworks at a Glance What ISO 27001:2022 Covers ISO/IEC 27001:2022 is the international standard for an Information Security Management System (ISMS). It comes in two halves. Clauses 4 to 10 define the management system itself: context, leadership, risk assessment and treatment, resourcing, operation, performance evaluation, and continual improvement. Annex A lists 93 reference controls across four themes (organizational, people, physical, technological). Your Statement of Applicability (SoA) records which of those controls you apply, which you exclude, and why. An accredited certification body issues the certificate after a two-stage audit, then you keep it through annual surveillance audits and a three-year recertification cycle. The certificate covers a defined scope, and that scope statement is the first thing a DSPT assessor reads. What the NHS DSPT Requires in 2026/27 The Data Security and Protection Toolkit (DSPT) is NHS England’s annual online self-assessment for every organization that touches NHS patient data or systems. It’s a contractual requirement under the NHS Standard Contract. Your published status (“Standards Met”, “Standards Exceeded”, “Approaching Standards”, “Standards Not Met”) is publicly searchable, so procurement teams and prospective NHS customers do look it up. The Toolkit isn’t one assessment. NHS England tailors it by organization category, and your category decides which assertions you answer and whether you need an independent audit. Version 9 came out on 4 September 2026. The Category 1 view is aligned to CAF version 4.0, and the whole thing closes on 30 June 2027. Insider Note: Most health-tech SaaS vendors are Category 3, not Category 2. To be an IT Supplier you need all three things at once: digital goods or services to the NHS, 50 or more staff, and £10 million or more in turnover. Picking “IT Supplier” because you sell NHS-facing software, without hitting the size thresholds, lands you in a heavier evidence set and a mandatory audit you may not need. Check the category before you check anything else. Key Structural Differences Between ISO 27001 and DSPT Four differences matter when you’re trying to reuse evidence. What they’re about. ISO 27001 is an information security standard. The DSPT is an information governance standard that includes security. A good chunk of it deals with lawful basis, transparency, data subject rights, records management, and the SIRO and Caldicott Guardian roles. None of that is in Annex A. How you’re assured. ISO 27001 gets certified once and surveilled once a year by an accredited body. The DSPT starts from a blank submission every year, and Category 1 and 2 organizations get independently assessed every year too. How granular they are. Annex A controls read as objectives (“access rights shall be provisioned, reviewed, modified and removed”). DSPT evidence items read as things to upload (“a list of all systems that hold personal data, with the date of last review”). So the mapping runs many-to-one in both directions. Where they’re heading. Since 2024/25 NHS England has been moving the Toolkit onto the NCSC Cyber Assessment Framework (CAF). CAF is outcome-based: assessors score you Achieved, Partially Achieved, or Not Achieved against an NHS England profile, rather than accepting a policy upload as proof. Category 1 organizations are already there. Category 2 and 3 are still on assertions and evidence, but NHS England has said CAF alignment will reach more organization types over time. The Business Case for Reusing ISO 27001 Evidence in DSPT How Much of DSPT Can Realistically Be Satisfied by ISO 27001 Controls For a Category 2 or 3 vendor with a full-scope ISO 27001 certificate, expect 60 to 75 percent of the mandatory evidence items to come from ISMS artifacts, either automatically (where the Toolkit auto-completes them) or with some light reframing. The rest is NHS-specific governance and information governance content that ISO 27001 doesn’t touch. The NHS’s own guidance treats reuse as a scope question. The DSPT help pages say an ISO 27001 certification must cover all health and care data processing to receive the full exemption, and that a certificate scoped only to an IT department is good evidence for many of the IT questions but not all of them. If your certificate says “the SaaS platform hosted in AWS eu-west-2” and NHS data also passes through your support desk tooling, your analytics sandbox, and a contractor’s laptop, the auto-completion won’t apply. Your assessor will want to know how those flows are controlled. Time and Cost Savings for Health-Tech Vendors There’s no fee to submit the DSPT. The cost is internal time, plus, if you’re Category 2, the independent audit and the annual penetration test the mandatory assertions expect. Building a first DSPT submission from nothing usually takes
Most companies start their first SOC 2 or ISO 27001 project in a spreadsheet, only to have it fall apart in week 6. This is typically when they’ll call us asking us to implement a GRC system that scales. Excel holds 154 controls fine. The trouble starts when an auditor sends over an evidence request list, two frameworks need updating at once, and a control owner who hasn’t opened the file since March edits the wrong row. This article gives you a free GRC workbook template built to take into consideration the hundreds of engagements we’ve guided. It walks you through each tab and tells you plainly when you’ve outgrown it. We’ve worked with hundreds of companies implementing SOC 2 + ISO 27001 and to be honest, for 80% of cases, using excel is feasible and even advised. Its a tool most of the staff knows and using it cuts onboarding times from weeks to a few hours. It also makes it accessible to the whole organization. The workbook covers all 33 SOC 2 Common Criteria plus the Availability, Confidentiality, Processing Integrity, and Privacy criteria, all 93 ISO 27001:2022 Annex A controls, a crosswalk between the two, and the evidence, risk, policy, and gap trackers that sit around them. It’s free, there are no macros, and it opens in Excel or Google Sheets. Why Start SOC 2 and ISO 27001 Tracking in a Spreadsheet The obvious argument for using Excel is cost and ease of use. A GRC platform costs around $10,000 a year before you’ve put a single control in place, and it pushes you into its control library and its workflow before you understand your own environment. A spreadsheet costs nothing and holds exactly the columns you need. More usefully, it makes you think about scope, ownership, and evidence before you automate any of it, and that thinking is the part no platform does for you. There’s a less obvious reason too. Teams that build their first control inventory by hand understand it. They know why CC6.3 maps to A.5.18, why the offboarding checklist is evidence for both, and who actually owns it. Teams that inherit a pre-populated platform library often don’t, and it shows in audit interviews when the auditor asks a control owner to explain a control they’ve never read. When a GRC Workbook Makes Sense A spreadsheet is the right tool when you’re chasing one or two frameworks, your team is under about 50 people, and one person owns compliance day to day. It also suits the readiness phase for any company. Scoping, gap analysis, and control design all go faster in a workbook than in a platform because there’s nothing to configure first. If you’re aiming for a SOC 2 Type I, or an ISO 27001 certificate with a tightly bounded ISMS scope, the workbook can carry you all the way to the audit. When You’ve Outgrown Excel (and Need a Platform) Excel breaks at scale in predictable ways. Spreadsheet research going back decades keeps finding that most operational spreadsheets contain at least one error; a review of field audits across 88 operational spreadsheets found errors in 94% of them. A compliance workbook with 1,400 formulas and a dozen editors isn’t exempt. Add a Type II observation period, where you collect the same evidence every month for a year, and manual tracking stops being a discipline and becomes someone’s full-time job. The specific tripwires are covered later in the article, but the short version is that when evidence collection becomes the bottleneck, it’s time to stop. What’s Inside the Free GRC Workbook Template The workbook has nine tabs. Eight get their own section in the walkthrough below; the ninth, Gap Analysis, is a remediation log that feeds the dashboard. Every tab uses the same color convention. Navy headers mean pre-filled reference content. Teal headers with light yellow cells are the fields you fill in. Grey headers are formula columns, and you should leave those alone. SOC 2 Trust Services Criteria Coverage All 61 criteria from the AICPA 2017 Trust Services Criteria (with the 2022 revised points of focus) are already in there: the 33 Common Criteria across CC1 through CC9, plus Availability (3), Confidentiality (2), Processing Integrity (5), and Privacy (18). Each row has a plain-English summary of what the criterion expects, so a control owner who has never opened the AICPA document can still understand what they’re being asked to prove. ISO 27001 Annex A Controls Coverage All 93 Annex A controls from ISO/IEC 27001:2022 are listed under their four themes: Organizational (37), People (8), Physical (14), and Technological (34). Each control has a short description of what it covers and a pre-computed column showing which SOC 2 criteria relate to it. Unified Control Mapping Between SOC 2 and ISO 27001 The Crosswalk tab maps every SOC 2 criterion to the Annex A controls and ISO clauses it overlaps with, labels the overlap as Shared, Partial, or SOC 2-specific, and pulls the live status and evidence IDs from the SOC 2 tab. A second table lists the 13 Annex A controls that have no meaningful SOC 2 counterpart, so you know what to track on its own. Evidence Tracker Every piece of evidence gets one row, tagged to the SOC 2 criteria and ISO controls it supports, with an owner, a source system, a location, the period it covers, and how often you collect it. A formula works out the next due date and flags each item as Current, Due Soon, Overdue, or Not Scheduled. Owner and Status Fields Both control tabs have a Control Owner column and a Status dropdown with five defined states: Not Started, In Progress, Implemented, Needs Remediation, and Not Applicable. The definitions sit on the Overview tab so that two people setting a status on the same day mean the same thing by it. Risk Register Tab Likelihood and impact on a 1 to 5 scale, an automatic score, a rating (Critical, High, Medium, Low), a treatment
Vanta’s hosted MCP server gives Claude Code, Codex, Cursor, and Perplexity a live line into your compliance program. Failing tests, controls, vulnerabilities, vendors, policies: all of it queryable in plain English from whatever tool you already have open. Connecting a client shouldn’t take more than ten minutes. Fixing what the agent finds still takes an engineer, and then a wait for Vanta’s next sync before the dashboard turns green. This guide walks through setup for all four clients, the remediation workflow from first query to verified fix, and the errors people hit most. It also covers the parts of the beta that Vanta’s marketing pages skip. What Is the Vanta MCP Server? Understanding Model Context Protocol (MCP) Model Context Protocol is an open standard for connecting AI applications to outside systems. An MCP client (the AI tool) asks an MCP server what it offers, usually a set of named tools with typed inputs, and calls those tools on your behalf. The protocol specification covers transport, authorization, and message format, which is why one server works with any compliant client. Anthropic released MCP in late 2024 and handed it to the Agentic AI Foundation in December 2025, a fund under the Linux Foundation co-founded with Block and OpenAI. The Linux Foundation’s announcement counted more than 10,000 public MCP servers at that point, with ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code all supporting the protocol. TechCrunch called the foundation’s projects the basic plumbing of the agent era. That neutral governance is the reason a single Vanta server can serve Claude, Codex, Cursor, and Perplexity without four separate integrations. What Vanta MCP enables for AI agents Vanta runs two versions of its MCP server. The hosted remote server, which this guide focuses on, lives at a regional URL, authenticates with OAuth in your browser, and is what Vanta now documents for every supported client. The older open-source local server ships as the @vantasdk/vanta-mcp-server npm package and runs on your machine with API credentials in an environment file. Vanta’s own repository for the local version now carries a deprecation notice pointing people to the hosted one, so treat it as a fallback for clients that can’t reach the hosted endpoint rather than the default. Once connected, the agent can list and filter automated tests, pull the specific entities failing a test, browse controls and their framework mappings, download and upload policy documents, review vendors and their risk attributes, and surface vulnerable assets with their remediation status. It reads live data every time it’s asked. The GRC lead asking “which SOC 2 controls have the most failing tests?” and the engineer asking “why is aws-s3-bucket-server-side-encryption-enabled failing?” are hitting the same server through different clients. Key use cases: compliance, failing tests, and vulnerability triage Most of the value sits in a few workflows. Failing test remediation is the headline: list failing tests, look at the resources behind them, and generate console steps, CLI commands, or infrastructure-as-code snippets to fix them. Vulnerability triage lets you query open CVEs by severity and SLA deadline, as long as at least one scanner (AWS Inspector, Tenable, Wiz, Snyk, or similar) is connected to Vanta. Without a scanner those queries come back empty. Compliance gap analysis covers framework progress, control ownership, evidence gaps, and cross-framework overlap, which is where GRC teams spend most of their time anyway. What Vanta MCP enables for AI agents Vanta runs two versions of its MCP server. The hosted remote server, which this guide focuses on, lives at a regional URL, authenticates with OAuth in your browser, and is what Vanta now documents for every supported client. The older open-source local server ships as the @vantasdk/vanta-mcp-server npm package and runs on your machine with API credentials in an environment file. Vanta’s own repository for the local version now carries a deprecation notice pointing people to the hosted one, so treat it as a fallback for clients that can’t reach the hosted endpoint rather than the default. Once connected, the agent can list and filter automated tests, pull the specific entities failing a test, browse controls and their framework mappings, download and upload policy documents, review vendors and their risk attributes, and surface vulnerable assets with their remediation status. It reads live data every time it’s asked. The GRC lead asking “which SOC 2 controls have the most failing tests?” and the engineer asking “why is aws-s3-bucket-server-side-encryption-enabled failing?” are hitting the same server through different clients. Key use cases: compliance, failing tests, and vulnerability triage Most of the value sits in a few workflows. Failing test remediation is the headline: list failing tests, look at the resources behind them, and generate console steps, CLI commands, or infrastructure-as-code snippets to fix them. Vulnerability triage lets you query open CVEs by severity and SLA deadline, as long as at least one scanner (AWS Inspector, Tenable, Wiz, Snyk, or similar) is connected to Vanta. Without a scanner those queries come back empty. Compliance gap analysis covers framework progress, control ownership, evidence gaps, and cross-framework overlap, which is where GRC teams spend most of their time anyway. Worth Knowing: Vanta’s Automated Tests Vanta’s automated tests confirm that a configuration exists. They don’t confirm that a control operated across the audit period. An agent that closes every failing test has cleaned up the dashboard, which is a different thing from passing the audit. Auditors still sample evidence, and the Vanta review goes into which automated tests are shallower than they look. Prerequisites Before Connecting Vanta MCP Finding your Vanta MCP URL Vanta hosts a separate MCP server per region. Use the one that matches your instance, because the client won’t authenticate against the wrong region. Every example below uses the US URL. Swap in yours. Required Vanta permissions and roles You need to be a Vanta Admin. The hosted MCP server isn’t available to non-admin users during the beta, and Vanta’s help center says broader access is planned but hasn’t shipped. This matters more than it sounds. The engineer who’d
Enforcement of the EU AI Act’s core rules started on 2 August 2026, and ISO/IEC 42001:2023 is the standard companies reach for when they need to prove their AI governance actually holds up. It’s the first certifiable standard for an Artificial Intelligence Management System (AIMS), and consultancies package help with it in two ways. A gap analysis tells you how far you are from the standard. Full implementation support builds the management system with you until you’re ready for certification. The two engagements differ enormously in cost, duration, and how much of the work the consultant carries, so picking the wrong one is expensive in both directions. Buy implementation when you only needed a roadmap and you pay for work your team could have done themselves. Buy a gap analysis when you have nobody to close the gaps and the report sits in a drawer while your certification deadline slips past. This article covers what each service includes, what each costs, who should pick which, and how the two combine. What Is an ISO 42001 Gap Analysis? A gap analysis is a structured baseline assessment. A consultant reviews your current AI governance practices against the requirements of ISO 42001: the management system clauses (4 through 10) and the Annex A controls, of which there are 38 grouped under nine control objectives. You end up with a clear picture of what already satisfies the standard, what partially satisfies it, and what doesn’t exist at all. The purpose is diagnostic, not corrective. Nobody writes your AI policy during a gap analysis. What you get is a gap report with maturity scoring against each clause and control, a prioritized remediation roadmap, an early view of your likely AIMS scope and Statement of Applicability (SoA), and an estimate of the effort certification will take. Timeframes are short. A standalone ISO 42001 gap analysis usually takes one to three weeks, with a few days of consultant time and a modest internal commitment: stakeholder interviews, access to documentation, and someone who can describe how AI is actually used across the business. Standalone assessments on the market typically run in the low four figures. Axipro bundles one into its free 30-day Compliance Accelerator Plan, so in practice you can get the diagnostic without spending anything. A gap analysis is the right entry point when you already have governance maturity to build on. Companies with an existing ISO 27001 ISMS often find heavy overlap in the management system clauses, since both standards follow the same Plan-Do-Check-Act (PDCA) structure. It also fits when you have internal compliance expertise to execute the roadmap, when budget needs phasing, or when you want an accurate scope before committing to a bigger project. Insider Note: The step that consistently takes longer than anyone expects is the AI system inventory. Most companies walk into a gap analysis confident they know where AI is used, then discover marketing has been running LLM tools on customer data, and engineering has embedded a third-party model nobody scoped. Budget real time for discovery before the control review starts. What Is ISO 42001 Full Implementation Support? Full implementation support is an end-to-end engagement that takes you from your current state to certification readiness. The consultant identifies the gaps, then closes them with you, building the AIMS piece by piece and owning the project through to the external audit. The deliverables list is long. A typical engagement covers the AI policy and governance framework, an AI risk assessment methodology, completed AI risk assessments and AI impact assessments for your in-scope systems, the Statement of Applicability, the applicable Annex A controls put in place (data governance, human oversight, transparency, and so on), the documentation and evidence set an auditor will ask for, staff training, an internal audit, a management review, and corrective action plans for whatever the internal audit surfaces. Most providers, Axipro included, also coordinate directly with the accredited certification body through the Stage 1 and Stage 2 audits. Most organizations need roughly three to six months. It’s shorter where an ISO 27001 ISMS already exists to integrate with, longer for complex or high-risk AI portfolios. Consultant involvement is heavy and sustained, but your team doesn’t disappear from the project. Internal subject-matter experts still make the real decisions about AI use cases, data handling, and acceptable risk. On cost, consultant-led ISO 42001 implementations commonly run well into five figures. Axipro’s ISO 42001 readiness engagement costs $4,500, which is one of the reasons the honest comparison below matters: at that price, the “just buy the gap analysis to save money” logic gets a lot weaker. Full implementation is the right call when you’re starting an AIMS from scratch, when nobody internal can carry the workload, when a certification deadline is fixed by an enterprise deal or regulatory exposure, or when your AI use cases are risky enough that getting the controls wrong has real consequences. The EU AI Act’s requirements for high-risk AI systems entered into application in August 2026, and companies in that category rarely get the luxury of a slow, self-paced build. Key Differences Between the Two Services Scope and depth A gap analysis assesses; implementation support executes. The gap analysis stops at the roadmap, no matter how detailed. Implementation carries every roadmap item through to a working, evidenced control. That distinction sounds obvious, but it’s the single most common source of buyer disappointment: a gap report doesn’t make you certifiable, and some companies find that out only after they’ve scheduled a Stage 1 audit. Consultant involvement and internal effort In a gap analysis, the consultant works in short, concentrated bursts and your team’s effort is measured in hours of interviews and document gathering. In full implementation, the consultant drafts, builds, and project-manages, yet your team still spends real time reviewing policies, making risk decisions, and generating evidence. Any provider promising certification with zero internal effort is describing a paper AIMS that won’t survive an audit or an incident. Cost and time to readiness A gap analysis finishes
Here are real numbers to anchor on: Axipro delivers ISO 42001 readiness for $4,000 if you’re under 50 employees and $5,500 if you’re over, and the GRC platform plus accredited audit adds roughly $4,000 to $7,000 on top. A mid-sized tech firm lands at around $10,000 to $15,000 all-in for year one. A small team comes in under $10,000. If you’ve been researching this topic, those figures probably look wrong to you. Published cost guides quote $85,000 to $320,000 for mid-market ISO 42001 certification. This article explains the gap: those guides price a traditional consulting-led engagement, where consultants bill day rates to build everything by hand. Automation-supported delivery, where a GRC platform collects the evidence and a fixed-fee team does the thinking, produces a completely different number. We break down both models phase by phase so you can budget against the delivery model you actually intend to buy. What ISO 42001 Consulting Includes for Mid-Sized Tech Firms ISO/IEC 42001 is the first certifiable international standard for an AI Management System (AIMS). Published in December 2023, it applies the familiar ISO management system structure to AI governance: scoped policies, AI risk and impact assessments, Annex A controls, a Statement of Applicability, internal audits, and a two-stage certification audit by an accredited certification body. Scope of Consulting Engagements A typical engagement covers five things: scoping the AIMS and building an AI system inventory, running a gap analysis against the standard, designing and documenting the management system, supporting control rollout, and preparing for the Stage 1 and Stage 2 audits. Under the traditional model, consultants hand-build each phase and bill for the hours. Under the automation-supported model, a fixed-fee readiness package covers the same ground while the platform does the mechanical work. Typical Deliverables from an ISO 42001 Consultant Expect a defined AIMS scope statement, an AI system inventory and risk register, AI impact assessments for in-scope systems, a policy and procedure set mapped to Annex A, a Statement of Applicability, training materials, an internal audit report, and audit-day support. If a proposal can’t name its deliverables this concretely, that tells you something about how well the consultant knows the standard. How Mid-Sized Tech Firms Differ from Startups and Enterprises Mid-sized firms sit in an awkward middle. They run more AI systems across more teams than a 15-person startup, so scoping, interviews, and evidence collection all take longer, and fixed-fee providers price them in a higher tier as a result. Unlike enterprises, though, they rarely need multi-site audit sampling or a dedicated AI governance function, so the six-figure quotes written for enterprises don’t apply to them either. Average Cost of ISO 42001 Consulting Typical Price Range for Mid-Sized Tech Firms Two delivery models, two price ranges. Automation-supported, fixed-fee delivery: readiness consulting at $4,000 for companies under 50 employees and $5,500 for companies over 50, covering the engagement from gap analysis through certification support. The GRC platform and accredited audit add roughly $4,000 to $5,000, so a mid-sized firm’s first-year total comes to around $10,000 to $12,000. Traditional consulting-led delivery: $25,000 to $80,000 in consulting fees alone for a mid-sized firm, built on day rates of $1,000 to $1,800 across 15 to 40 consultant days. This is the model behind the $85,000-plus totals in most published guides. It still makes sense in a few situations: on-prem infrastructure the platforms can’t see, heavy regulatory overlays, or a board that wants a named Big Four partner on the engagement. The market is young enough that quotes for identical scope can differ by a factor of five. ISO 42001 certificates only started appearing in volume in 2024, and plenty of consultants quoting today have never taken a client through a Stage 2 audit. Insider Note: When a mid-sized firm shows us a $90,000 quote for ISO 42001, the line items usually reveal hand-built work the platform now automates: manual evidence collection, policy drafting from scratch, spreadsheet-based risk registers. What you’re actually paying a consultant for is scoping, impact assessment methodology, and audit judgment. The mechanical work has been commoditized, and pricing that ignores this is pricing from 2023. Hourly vs Project-Based Consulting Rates Experienced AI governance consultants charge $150 to $300 per hour in the North American and UK markets. Hourly billing works for targeted needs: reviewing an impact assessment methodology, answering auditor questions, validating a control design. For a full implementation it’s a false economy, since open-ended hours remove any incentive to compress the work. Fixed-fee delivery flips that incentive, and that’s a big part of why it prices so much lower. Fixed-Fee vs Retainer Engagement Models Model Typical cost Best for Watch out for Fixed-fee readiness package $4,000 (under 50 employees) / $5,500 (over 50) First certification with defined scope Packages that exclude audit facilitation Traditional fixed-fee project $25,000 to $80,000 Complex scopes, heavy regulatory overlay Paying consulting rates for automatable work Monthly retainer $2,000 to $8,000/month Spreading work over 6 to 12 months Engagements that drift without a certification date Hourly / ad hoc $150 to $300/hour Targeted reviews, audit-day support Costs compounding on open-ended work Fractional AI governance officer $3,000 to $10,000/month Post-certification ownership without a hire Thin coverage if the fractional lead is overloaded Fixed-fee is the right default for a first certification. It moves delivery risk to the provider and forces both sides to agree scope upfront. Fractional arrangements earn their keep after certification, once the work shifts from building the AIMS to running it. Cost Breakdown by Consulting Phase The figures below show what each phase costs when you buy it separately from a traditional consultancy. Inside a fixed-fee package, all five phases sit within the single $4,000 or $5,500 engagement fee, and that’s exactly why the totals diverge so sharply. Readiness and Gap Assessment Fees Standalone price: $2,000 to $15,000, often more than an entire fixed-fee engagement. Either way, this is the highest-value work relative to its cost. The AI system inventory and gap analysis determine everything that follows, including whether you need the rest of the engagement
Global AI regulation is not converging. Four distinct regulatory models have hardened over the past two years: the EU’s single horizontal law, China’s fast-moving sequence of targeted rules, the American patchwork of state laws and voluntary frameworks, and the Gulf’s procurement-driven approach, where the state shapes the market by being its biggest customer. Anyone waiting for these to merge into one global rulebook will be waiting well past 2030. That fragmentation, not any single law, is the defining trend in AI regulatory compliance. The practical question for 2026 through 2028 is no longer “which regulation applies to us” but “which regulatory model does each of our markets follow, and what carries over between them.” This article maps the four models, with extra time on the Gulf version because it gets far less coverage than it deserves. It also argues that ISO standards, led by ISO/IEC 42001, are becoming the only compliance credential that travels across all four. The Four Models of AI Regulation Most trend pieces treat AI regulation as one global movement running at different speeds. It’s more useful to treat it as four philosophies that answer the same question in incompatible ways. European Union China United States Gulf (KSA, UAE) Instrument One horizontal law (EU AI Act) Sequence of targeted departmental rules State laws, voluntary frameworks, sector rules Data law plus procurement requirements Enforcer Commission, national authorities, notified bodies CAC and partner ministries States, regulators, courts, buyers SDAIA, NDMO, central banks, tender owners Core concern Fundamental rights, product safety Content security, data sovereignty Liability, consumer protection National strategy, data sovereignty, state procurement Speed Slow to write, long lead times Fast, iterative, hardening Uneven, litigation-led Fast: effective when a tender says so What travels Conformity assessment, technical files Filings and labeling rarely reusable Assurance reports, questionnaires ISO certification as procurement signal The European Union: One Law for Everything The EU chose a single horizontal statute, Regulation (EU) 2024/1689, better known as the EU AI Act. It classifies AI systems into risk tiers, bans a short list of practices outright, and attaches heavy obligations to high-risk systems: risk management, data governance, human oversight, technical documentation, and conformity assessment. It applies extraterritorially, so a Bahraini or American provider whose system reaches EU users is in scope. The model’s strength is predictability, and its weakness is pace. Prohibitions have applied since February 2025 and general-purpose AI obligations since August 2025, with Commission enforcement beginning in August 2026. The 2026 digital omnibus agreement then deferred the main high-risk deadlines to December 2027 and August 2028. The EU writes slowly, publishes a timetable, and expects the world to plan around it. China: Regulation One Risk at a Time China has no single AI statute and doesn’t appear to want one yet. Instead, the Cyberspace Administration of China and partner ministries have issued targeted rules in rapid sequence: algorithmic recommendation provisions in 2022, deep synthesis rules in 2023, interim measures for generative AI services the same year, AI content labeling requirements in September 2025, and rules for anthropomorphic AI interaction services that took effect in July 2026. Each rule attacks one risk scenario, takes effect quickly, and gets refined through practice. The direction of travel matters more than any single measure. China’s revised Cybersecurity Law, effective January 2026, wrote AI research, training data, computing infrastructure, and risk monitoring into a foundational statute for the first time. Soft guidance is hardening into binding law, and the organizing logic throughout is content security, data sovereignty, and platform accountability rather than individual rights. For foreign companies, the compliance burden is operational: filings, security assessments, and labeling obligations that arrive with short notice and almost no grace period. The United States: The Market as Regulator The US still has no federal AI statute, and the vacuum is being filled from two directions. States are legislating, with Colorado’s AI Act as the most complete example, and sector regulators are stretching existing consumer protection, employment, and financial rules to cover AI. The NIST AI Risk Management Framework sits underneath as the voluntary vocabulary everyone borrows. In practice, the binding force in America is commercial. Enterprise buyers, insurers, and litigators enforce AI governance through security questionnaires, vendor reviews, and lawsuits long before any statute does. For a company selling into the US, the real regulator is the procurement team of your largest prospect. The Gulf: The State as Customer The Gulf model is the least covered and, for anyone selling into the region, the most misunderstood. Saudi Arabia has no horizontal AI act. It regulates AI through data law and through the state’s position as the dominant buyer in the economy. The Saudi Data and Artificial Intelligence Authority (SDAIA), established in 2019 and reporting directly to the Prime Minister, runs the show: it sets national strategy, publishes the frameworks, and steers what government tenders ask for, a far more hands-on role than most regulators play. The load-bearing rules are the Personal Data Protection Law, enforced since September 2023, and its cross-border transfer regime. Around them sit SDAIA’s AI Ethics Principles, generative AI guidelines for government entities, and the AI Adoption Framework, published in November 2025 as a mandatory baseline for public sector bodies, with a four-tier risk classification and lifecycle auditing for high-impact systems. A draft Responsible AI Policy went through public consultation in May 2026, confirming that a formal, operational regime is coming. The Kingdom designated 2026 its Year of Artificial Intelligence, and the direction across the region matches: the UAE runs an AI Seal program and its central bank requires bias testing at financial institutions, Oman’s National AI Policy entered into force in April 2025, and Bahrain has a proposed AI law in progress. The defining feature is speed through procurement. A requirement in a Saudi government tender takes effect the day the tender document is published, with no transition period and no parliamentary debate. High-risk use cases increasingly require self-assessments before tenders or go-lives. Regulation by purchase order moves faster than regulation by statute, and in state-led
More than half of the average organization’s vendor footprint is now Shadow IT, and only two percent of it ever gets a security review, according to Vanta’s own research into vendor sprawl. That’s one symptom of a wider pattern: most risk registers drift from reality between review cycles — a spreadsheet nobody’s updated, a control nobody’s re-tested, a vendor relationship nobody’s re-assessed. This guide sets out what to check when evaluating risk management software, using four leading platforms as the test case. What Is Risk Management Software? Risk management software is the system of record for identifying, scoring, monitoring, and reporting on the risks an organization carries, spanning internal controls, regulatory obligations, and vendor relationships alike. The strongest platforms connect every risk source into one register instead of splitting them across separate tools, map each risk to the specific controls and assets it touches, and keep scoring current as those controls change. Third-party and vendor risk is one input into that system, not a separate category of software. Key Benefits of Risk Management Software A register that reflects reality. Continuous, signal-driven identification surfaces a lapsed control or a new exposure as your environment changes, instead of waiting for the next quarterly review to notice. Defensible answers, faster. Risks that are automatically mapped to the controls, assets, and vendors behind them mean an audit or board question gets a sourced answer instead of a manual reconstruction. One system instead of a spreadsheet plus a separate tool. Internal risk, vendor risk, and the controls that mitigate both live in one place, so scaling into a new business unit or region doesn’t mean standing up another platform. What to Look for in the Best Risk Management Software Most vendor comparisons focus on feature lists. The person who will configure the register and keep it current asks a narrower set of questions, and the answers aren’t always where a demo puts them. Continuous, Signal-Driven Risk Identification A risk register that only updates when someone remembers to run a review is already stale by the time it matters. Ask whether the platform surfaces new risks automatically as your environment changes (a new system, a failed control test, a new vendor relationship), or whether identification depends on someone scheduling a manual pass. Risk-to-Asset, Control, and Vendor Mapping A risk that isn’t tied to anything specific can’t be monitored and can’t be proven when an auditor asks how it’s covered. Ask whether risks map automatically to the assets, controls, and vendors involved, and whether a failed control raises the linked risk without anyone touching it. This is one of the more common places a platform’s marketing outpaces what it can actually demonstrate live, so ask for the mapping on screen rather than taking the claim at face value. Risk Scoring and Audit-Ready Reporting Boards and auditors expect both inherent risk (exposure before controls) and residual risk (exposure after), and a static score that only updates when someone re-scores it by hand loses credibility fast. Ask whether the platform scores both, whether residual risk updates automatically as controls change, and whether you can reproduce the register exactly as it stood on a specific past date rather than reconstructing it from an export. Platform Consolidation and Register Scale Nearly every vendor in this category positions itself as the one system that replaces a spreadsheet and every adjacent tool, which is a claim worth testing rather than taking at face value. Ask for a live demonstration showing risk findings, including vendor risk if that’s part of your program, and actually reach one register. Then ask specifically whether that register can split into multiple registers by business unit or entity with independently configured scoring, not just a single company-wide scale applied everywhere. AI Risk Governance AI is the fastest-growing, least-governed risk surface in most programs, and treating it as a side project instead of a line item in the main register is a common gap. Ask whether AI risk lives in the same register as everything else, mapped to named frameworks like the EU AI Act or ISO 42001, or whether it’s tracked separately, if at all. The Top Risk Management Platforms, Reviewed None of the platforms below have been tested hands-on for this guide. Each entry reflects what the vendor states on its own public pages, checked directly rather than taken from a review site or from a competitor’s comparison of it. Vanta Vanta positions its risk product as a connected layer across compliance, internal risk, and third-party risk, built to sit inside the same automated-compliance workflow the platform is best known for. Strengths. Vanta maps risks to assets automatically, a shipped, generally available capability, and ships a named Risk Snapshots feature that captures the register at a specific point in time. It also provides a pre-built library of 100+ risk scenarios, and monitors internal and vendor risk continuously in one consolidated register, including, where third-party risk is part of the program, automating vendor questionnaire follow-up. Trade-offs. Risk-to-control mapping is in preview and risk-to-vendor mapping is on the roadmap, so don’t expect either live in a demo today. A more detailed, named-factor scoring model with automatic residual updates is also roadmap; what’s shipped today is a simpler inherent-and-residual score. Multiple risk registers by team or business unit are documented, but nothing public confirms independently configured scoring per register. Best for. Enterprise teams that want risk, compliance, and optionally vendor risk running on one continuously monitored foundation, and can wait on the control- and vendor-mapping roadmap. OneTrust OneTrust positions itself broadly across privacy, data governance, and risk, with third-party risk as one module inside a wider platform. Strengths. OneTrust maps risks to related assets, processes, and vendors within its IT Risk Management product, and scores both inherent and residual risk with a stated ability to roll scores up through a risk hierarchy. It also has a dedicated AI Governance product mapping AI risk to the EU AI Act, NIST, and ISO 42001 by name, the most explicit AI-risk
OWASP published the 2026 edition of its Top 10 for LLM Applications on August 4, 2026, during Black Hat week, and eight of the ten entries changed position. One got renamed. The message behind the reshuffle is blunt: you won’t build a model that can’t be fooled, so build the application around it in a way that limits the damage when it is. That one idea explains almost every move in the new ranking, and it should change how your team thinks about shipping AI features. This guide walks through the 2026 list in plain English: what each risk means, a real-world example, and what your team can actually do about it, with or without a dedicated security function. What Is the OWASP GenAI LLM Top 10 2026? The OWASP Top 10 for LLM Applications is a community-built awareness document that ranks the ten most critical security risks in applications powered by large language models. The OWASP GenAI Security Project, a global open-source initiative under the OWASP Foundation, maintains it, and the 2026 edition is the third release since the list first appeared in 2023. OWASP, the Open Worldwide Application Security Project, has published risk lists for web applications since 2003, and those lists became the shared vocabulary security teams, auditors, and buyers use to talk about risk. The GenAI LLM Top 10 does the same job for AI. Whether you’re a two-person startup wiring an API into a chatbot or an enterprise running retrieval pipelines, it gives you a common map of what actually goes wrong. One scoping note matters before anything else. The 2026 edition covers the model as a component inside an application: something that accepts input, generates output, and maybe retrieves information. The moment the model becomes an actor, with tools it can call and consequences it sets in motion, the risk shifts to the companion OWASP Top 10 for Agentic Applications from December 2025. Most products now do both, so most teams need both lists. Why the 2026 Update Matters for AI Builders Two things separate this edition from everything OWASP has published on AI so far. First, the methodology changed. Every previous version rested purely on expert consensus, meaning hundreds of practitioners voting on which risks matter most. This time the vote carried 75% of the weight, and the remaining 25% came from analysis of 6,639 real-world AI security incidents pulled from public vulnerability databases and an AI-harm database. It’s the first edition grounded in evidence of what has actually gone wrong rather than expert prediction of what might. Second, the framing changed. The project leads open the 2026 release by telling teams to stop optimizing the model and start optimizing the containment. The industry has spent two years pouring effort into filters, guardrail models, and jailbreak resistance. The 2026 list says: assume those will eventually fail, and make sure that when they do, nothing important breaks. AI security becomes blast radius control rather than perfect prevention. And this isn’t just a security engineer’s document. Developers decide what tools and permissions a model gets. Product owners decide which workflows run without a human in the loop. Founders and ops leads are the ones answering the security questionnaires where these questions now show up. The 2026 edition also ships a mapping appendix that connects every risk to frameworks your customers and auditors already recognize: NIST’s AI Risk Management Framework, MITRE ATLAS, MITRE CWE, and the Agentic Top 10. Insider Note: Enterprise vendor assessments have started asking about the OWASP LLM Top 10 by name. In security questionnaires we complete for clients at Axipro, questions like “describe your controls against prompt injection and excessive agency” began appearing in early 2026, sometimes before the buyer’s own team could explain what they meant. Being able to answer with a mapped control set is becoming a deal-cycle advantage, not just a security exercise. How the 2026 List Differs From Previous Versions The top two entries held their positions. Everything below them moved. Key Shifts Since the 2025 Update Excessive Agency jumped from sixth to third, the biggest promotion on the list. In 2025, giving a model tools and autonomy was mostly a theoretical worry. By 2026, agentic deployments had produced real production incidents, and the community concluded that agency is what decides whether a successful prompt injection is an inconvenience or a breach. Unbounded Consumption rose four places, from tenth to sixth. Inference costs became a real budget line as reasoning models, long outputs, and agent loops multiplied the compute behind a single request. “Denial of Wallet,” where an attacker spends pennies to trigger spend you can’t afford, is now a mainstream finding. Improper Output Handling fell from fifth to tenth. The risk didn’t shrink. It fell because it’s well understood and directly fixable with encoding and validation practices web developers already have. The entries above it are neither. What’s New, Renamed, or Reprioritized System Prompt Leakage became Hidden Context Exposure, and the scope widened a lot. The 2025 entry worried about attackers extracting your system prompt. The 2026 entry covers everything assembled into the model’s context that users aren’t meant to see: system instructions, retrieved policy documents, tool schemas, workflow rules. The guidance is unusually honest for a security document: assume all of it is discoverable, and design so that disclosure costs you nothing. Data and Model Poisoning absorbed fine-tuning subversion. The attack surface for corrupting a model’s behavior runs from pretraining data through fine-tuning pipelines into the retrieval stores RAG systems depend on, and the entry now says so. Misinformation climbed on evidence, not opinion. Practitioners voted it low; the incident data ranked it high. As reported in Help Net Security’s coverage of the release, OWASP also describes a “defense effect” working in the opposite direction on prompt injection: teams block it so effectively that few successful attacks reach public databases, which makes the risk look smaller than the money spent containing it. Signals About Where AI Security Is Heading Read together, the moves point one
For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly. What Agentic AI Actually Changes Traditional AI systems, even generative ones, are advisory. They produce an output such as a summary, a prediction, a draft email, or a classification, and a human remains the last checkpoint before anything happens in the real world. Agentic AI removes that checkpoint. An agentic system doesn’t just produce an answer. It pursues a goal. It decides which tools to call and in what order, then executes those actions directly against live systems: submitting a purchase order, modifying a database record, sending an external communication, or orchestrating a set of sub-agents to complete a broader workflow. Agentic autonomy is the degree to which a system can plan and execute actions without a human explicitly authorizing each step. It’s a spectrum rather than a binary. At one end, the AI drafts and a human approves every action. At the other, the AI operates within broad guardrails and only escalates exceptions. The further an organization moves along that spectrum, the less its exposure looks like software risk and the more it looks like delegated authority risk, the kind normally reserved for employees, contractors, and automated financial systems. Why Existing Risk Registers Miss Agentic AI Risks Most enterprise risk registers were built on a reasonably safe assumption: a human initiates consequential actions, and the technology around that human behaves deterministically. Agentic AI breaks both halves of that assumption at once. A few specific gaps show up quickly when organizations try to map agentic deployments onto existing categories. Operational risk registers assume process failures come from human error or system outages, not from a system independently choosing an unanticipated path to a stated goal. Cybersecurity risk registers are built around unauthorized external access, while an agent problem usually involves an authorized system taking unauthorized internal actions with its own legitimate credentials. Model risk frameworks, borrowed largely from financial services, evaluate output accuracy rather than action consequences, which matters most when those actions can’t be reversed. And third-party risk assessments treat vendors as static entities, not as autonomous agents that might invoke other vendors’ agents on your behalf. See our guide to the NIST AI Risk Management Framework for how output-focused frameworks are structured. The result is a governance blind spot. An organization can be compliant against its AI policy, its cybersecurity policy, and its vendor risk policy, and still have nobody accountable for the specific risk of a system initiating a harmful sequence of actions before anyone notices. Defining Agentic Autonomy Risk Agentic Autonomy Risk is the risk that an AI system, operating with delegated decision-making and execution authority, takes actions that are harmful, non-compliant, or misaligned with organizational intent before adequate human oversight can intervene. Those actions might happen independently or in coordination with other agents. It deserves standing as a named category alongside cybersecurity, operational, legal, financial, and third-party risk because the loss event itself is different. The harm is a completed action in a live system, and it may be difficult or impossible to reverse. The accountability structure is different too: when an orchestrating agent delegates to sub-agents, responsibility for the outcome gets distributed in ways existing ownership models don’t cleanly capture. So is the detection window. Traditional controls assume a human is positioned to catch an error before it compounds, but an agent can execute dozens of dependent actions faster than any human review cycle. 7 Agentic AI Risk Scenarios to Put on Your Register 1. Unauthorized autonomous decision-making. An agent takes an action within its technical permissions but outside its intended business mandate. It adjusts pricing, approves a refund, or modifies a customer record, and no policy ever explicitly authorized that scenario. 2. Goal misalignment. The agent optimizes for a literal interpretation of its objective in a way that diverges from actual business intent, particularly under ambiguous or adversarial inputs. 3. Multi-agent interactions and cascading failures. One agent’s flawed output becomes another agent’s trusted input. A single error can propagate across a chain of agents faster than anyone can detect it, amplifying the original mistake instead of containing it. 4. Excessive tool or system permissions. Agents get provisioned with broad, standing access “to be safe” rather than scoped, least-privilege access tied to specific tasks. A productivity tool quietly becomes a privilege-escalation path. 5. Regulatory non-compliance. Autonomous actions trigger obligations under data protection, financial services, employment, or sector-specific regulation, and they execute without the compliance review a human-initiated process would normally receive. 6. Explainability and accountability gaps. An autonomous action causes harm and the organization can’t clearly reconstruct why the agent chose that path, or establish whether the business owner, the AI governance function, or the vendor is accountable for the outcome. 7. Autonomous third-party actions. A vendor’s agent, integrated into your environment, takes action on your behalf, or your agent acts against a
A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing? A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2? Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $1,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the lower end of the market start around $1,000 to $5,000. Deep manual testing from established firms runs $10,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise) Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $1,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries
Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That
The EU AI Act names recruitment AI as high-risk. Annex III explicitly lists AI systems used for recruitment, candidate selection, and employment decisions, which pulls CV screeners, video interview platforms, and assessment tools into the most demanding compliance regime the Act contains. The original compliance date for these systems was August 2, 2026. In June 2026, the EU’s Digital Omnibus moved the deadline to December 2, 2027, a 16-month extension that has led many HR and talent teams to shelve the topic entirely. That’s a mistake, for two reasons. First, one rule that directly affects recruitment technology is already in force: the ban on emotion recognition in the workplace has applied since February 2, 2025, and it catches features still shipping in some video interview products today. Second, the deferred obligations didn’t shrink. Conformity assessments, human oversight design, bias monitoring, and documentation all still arrive in full, and the practical work of auditing a recruitment stack, renegotiating vendor contracts, and training hiring teams routinely takes a year or more. Here’s what the EU AI Act actually requires of employers and vendors using recruitment tools, on the timeline that now applies. Why Recruitment Tools Are Classified as High-Risk Under the EU AI Act Definition of High-Risk AI Systems in Hiring The Act takes a list-based approach. Annex III, point 4, designates as high-risk any AI system intended for the recruitment or selection of natural persons, including placing targeted job advertisements, analyzing and filtering applications, and evaluating candidates. The same point covers AI used for decisions on promotion, termination, task allocation, and monitoring of workers, so the classification follows the tool through the entire employment lifecycle, not just the hiring funnel. The reasoning is straightforward: hiring decisions shape access to livelihoods, and algorithmic discrimination in hiring is well documented. The European Commission’s regulatory framework for AI treats employment as one of the areas where an AI error or bias causes serious harm to fundamental rights. That’s the test for the high-risk tier. Types of Recruitment Tools Affected In practice, the high-risk classification captures most of the modern recruitment stack: CV and resume screeners that rank or filter applicants, video interview platforms that score responses or delivery, psychometric and skills assessment tools that produce scores feeding a hiring decision, sourcing and matching algorithms that decide which candidates a recruiter sees, and programmatic job ad targeting systems that determine who sees a vacancy at all. If the system’s output materially influences who advances and who does not, assume high-risk until proven otherwise. Important: Emotion recognition is not high-risk in the workplace. It is prohibited. Article 5 bans AI systems that infer emotions of people in the workplace (outside narrow medical and safety cases), and that ban has applied since February 2025 with the Act’s top penalty tier attached. If your video interview vendor markets “engagement scoring” or “sentiment analysis” of candidates, that feature needs to be switched off for EU hiring now, not in 2027. Recruitment Tools That May Fall Outside High-Risk Classification Not everything in the HR stack qualifies. The Act carves out systems performing narrow procedural tasks that do not materially influence decision outcomes. An applicant tracking system that stores applications, schedules interviews, and sends templated emails is a database with a workflow, not a high-risk AI system. The same goes for tools that transcribe interviews without scoring them, deduplicate candidate records, or generate first drafts of job descriptions for a human to edit. The line is decision influence: the moment a tool ranks, scores, filters, or recommends candidates, it crosses into Annex III territory. Deployers who rely on an exemption must be able to document that assessment, so “we decided it doesn’t count” needs to exist on paper. Extraterritorial Scope: Which Employers Are Covered The Act applies to providers placing AI systems on the EU market and to deployers established in the EU, but it also reaches further: it covers providers and deployers located outside the EU where the output of the system is used in the EU. For recruitment, the consequence is blunt. A US or UK company with no EU entity that uses an AI screener to filter applicants for roles based in Berlin or Dublin, or that screens candidates located in the EU, is using the system’s output in the Union. Brexit doesn’t move UK employers out of scope when they hire into or from the EU. Providers vs. Deployers of Recruitment AI Tools The Act splits obligations between the provider (the vendor that develops the tool and places it on the market) and the deployer (the employer using it). Most employers are deployers, and deployer obligations are lighter but real. One common trap: an employer that substantially modifies a high-risk system, or puts its own name on it, can be reclassified as a provider and inherit the full provider stack. Heavy customization of a screening model, or fine-tuning it on your own hiring data, can be enough to trigger this. Key Obligations for Employers Using AI Recruitment Tools Human Oversight in Automated Hiring Decisions Deployers must assign oversight of the system to people with the competence, training, and authority to intervene. That last word matters. A recruiter who rubber-stamps whatever the ranking algorithm produces, because nobody has time to review 800 rejected CVs, doesn’t count as oversight. Regulators and courts will look at whether the human could genuinely override the system and whether they ever did. Designing review checkpoints where a person can meaningfully change the outcome, and logging when they do, is the core of compliant deployment. Transparency Requirements Toward Candidates Employers must inform workers and their representatives before putting a high-risk AI system into use at work, and candidates subjected to such a system must be told it is being used. In countries with works councils, such as Germany, this obligation lands on top of existing co-determination rights, so employee representatives may need to be consulted before the tool goes live rather than just told afterward. Burying an AI disclosure in a privacy policy paragraph is unlikely to survive scrutiny.
A green dashboard is not an audit opinion. Compliance automation platforms like Vanta, Drata, Secureframe, and Hyperproof have made SOC 2 readiness faster and cheaper, but every audit cycle produces the same pattern: controls that sat at “passing” for months come back from the auditor with exceptions or requests for re-testing. The four controls below account for a disproportionate share of those rejections, and they all fail for the same underlying reason. The tool confirmed that evidence exists. The auditor tested whether the control actually operated. This article walks through each of the four: what auditors reject, why, and how to fix the evidence before fieldwork starts. Why Compliance Tools Show “Passing” But Auditors Still Reject Controls The Gap Between Automated Checks and Auditor Judgment Compliance platforms run continuous control monitoring: API calls that check whether a configuration exists, a document is uploaded, or a task is marked done. That’s real value. It catches drift, keeps evidence in one place, and saves weeks of screenshot collection. An audit is a different exercise. A SOC 2 examination is an attestation performed by a CPA firm under AICPA standards, and the auditor’s job is to form an independent opinion on whether your controls met the Trust Services Criteria. That opinion rests on professional judgment, not on whether an API integration returned a 200 response. What “Passing” Actually Means in Your Compliance Dashboard When a control shows “passing,” the platform is telling you one narrow thing: at the moment of the last scan, an automated test found the artifact or setting it was programmed to look for: MFA enforced in the identity provider, a policy document uploaded, a training campaign sitting at 100%. The test says nothing about whether the underlying process ran the way your control narrative claims it did, or whether it ran that way across the whole audit period. How Auditors Evaluate Controls Beyond the Checkbox Auditors test two dimensions. Design effectiveness asks whether the control, as described, would meet the criterion if it worked as intended. Operating effectiveness, the core of a SOC 2 Type 2 report, asks whether it actually did throughout the audit period. To answer that, the auditor pulls a population (every access review, every change, every new hire in the period), selects a sample, and inspects the evidence item by item. A dashboard status feeds into that process. It doesn’t replace it. Insider Note: Auditors increasingly ask for evidence outside the compliance platform precisely because they know what the platform auto-collects. If every artifact you produce comes from the same tool export, expect the auditor to independently pull the population from the source system and compare. Discrepancies between the two are one of the fastest routes to an exception. Control #1: Access Reviews That Automation Marks Complete but Auditors Reject Why Auditors Reject Automated Access Review Evidence User access reviews sit under the logical access criteria (CC6.1 through CC6.3), and they are the single most common source of audit exceptions we see. The typical failure: the platform generated a user list, someone clicked “complete,” and the dashboard turned green. The auditor then asks a simple question the evidence can’t answer: what did the reviewer actually decide? The Missing Element: Documented Reviewer Judgment An access review is a judgment control. Someone with knowledge of the system must look at each account and confirm the access is still appropriate for the person’s role. A timestamped task closure proves the task was closed. It doesn’t prove anyone assessed anything, and an “approve all” review completed in ninety seconds gets exactly the skepticism it deserves. What Auditors Actually Want to See in Access Review Evidence Auditors look for four things: The full population of accounts at the time of review (including service accounts and admin roles), Evidence of who reviewed it and when, explicit dispositions per account or group (retain, modify, revoke), and Proof that flagged access was actually removed. That last item, the deprovisioning ticket showing revocation within a defined window, is the piece most companies can’t produce. How to Fix Your Access Review Control Before the Audit Assign a named control owner per in-scope system, run reviews quarterly, and require reviewers to record a disposition for every line, not a blanket approval. When access is revoked, link the removal ticket to the review record. If a quarter was missed, don’t backfill it. Document it honestly and show the remediation, because auditors treat fabricated retroactive evidence far more severely than a disclosed gap. Control #2: Change Management Approvals That Pass Automated Scans Why Ticket Closure Isn’t Proof of Approval Change management (CC8.1) automation typically verifies that production changes link to a ticket and the ticket is closed. Auditors test something stricter: that each sampled change was approved by an authorized person before deployment. An approval added after the merge, or a ticket closed by the same engineer who wrote the code, fails that test even though every automated check came back green. The Segregation of Duties Problem Automation Misses Segregation of duties is the requirement that no single person can develop, approve, and deploy the same change. NIST’s SP 800-53 control catalog treats it as a foundational access control principle, and SOC 2 auditors apply the same logic. Small engineering teams trip on this constantly. Self-approved pull requests, admins who can bypass branch protection, direct pushes to main: a scanner sees “changes with tickets” while an auditor sees SoD violations. Emergency Changes and Retroactive Approvals: Common Rejection Triggers Every audit period contains hotfixes. Auditors don’t reject emergency changes. They reject emergency changes with no documented post-hoc review. If your policy says urgent changes get retroactive approval within two business days, the auditor will sample your emergency changes and check exactly that. No policy, or a policy nobody followed, produces an exception. Rebuilding Change Management Evidence Auditors Will Accept Enforce the control technically: branch protection requiring at least one independent reviewer, no admin bypass, and deploy pipelines that only run from protected branches. Then write the emergency change procedure down and generate the review artifact every time it fires.
One in five breached organizations last year traced the incident to shadow AI, and those breaches cost an average of $670,000 more than standard incidents, according to IBM’s 2025 Cost of a Data Breach Report. The worst part is that most of those organizations already ran a CASB, a DLP program, or both. The tools were on, but the traffic still got through. That’s the visibility gap this article is about. AI tool usage tracking isn’t the same problem as SaaS discovery, and the security stack built for the SaaS era misses most of what matters about AI. Below, we break down what tracking actually requires, where CASB and DLP fail, which categories of AI usage slip through, and what a stack that works looks like in 2026. What AI Tool Usage Tracking Actually Means Most teams that say they “track AI usage” mean they can see that someone visited chat.openai.com. That is app discovery, and it answers almost none of the questions a security or governance team actually needs answered. Beyond App Discovery: Tracking Prompts, Data Flows, and Model Interactions Real tracking covers three layers. First, which tools are in use: chatbots, copilots, coding assistants, embedded SaaS features, agents. Second, what data moves: the content of prompts, uploaded files, and pasted context, mapped against data classifications. Third, how models behave in your environment: which endpoints get called, which OAuth grants exist, which agents hold standing permissions. Seeing that an employee opened ChatGPT gets you nowhere. What you actually need to know is whether they pasted a customer contract into a personal account while they were there. The Difference Between Detection, Monitoring, and Continuous Tracking Detection is a point-in-time answer to “what AI is here?” Monitoring watches known tools on an ongoing basis. Continuous tracking is broader: it assumes the inventory changes weekly, correlates identity, data, and endpoint signals over time, and feeds a governance program rather than a one-off report. Frameworks such as the NIST AI Risk Management Framework and ISO 42001 assume the third mode. A discovery scan from last quarter won’t satisfy an auditor, and it certainly won’t slow down an attacker. Why Traditional SaaS Monitoring Falls Short for AI SaaS monitoring was built around a stable premise: an app is a destination with a domain, a login, and an admin console. AI breaks that premise in several ways at once. The risky activity is the content of an interaction, not the visit. The tool often isn’t a destination at all but a feature inside an app you already sanctioned. And increasingly the “user” isn’t a person but an agent acting on delegated credentials. Why CASB Misses Shadow AI Usage The Cloud Access Security Broker sits between users and cloud services to enforce policy, and for classic SaaS governance it still earns its keep. AI has structural blind spots that no amount of tuning can fix. CASBs Were Built for SaaS Apps, Not Model Endpoints A CASB catalog maps domains to applications with risk scores. AI usage doesn’t resolve neatly to a domain. The same api.openai.com endpoint serves a sanctioned enterprise deployment, a developer’s weekend experiment, and a data-leaking browser extension, and the catalog sees one “app”. Meanwhile, new model endpoints, wrappers, and niche AI tools appear faster than any vendor catalog can keep up with. Gartner research from late 2025 found 69% of organizations already suspect or have evidence that employees use prohibited public generative AI tools, catalog or no catalog. Blind Spots in Encrypted API Traffic to LLM Providers Prompt content travels over TLS. Without full TLS inspection, a CASB sees connection metadata: destination, volume, timing. It can’t see that the payload contained source code or patient records. And full TLS inspection is harder than the datasheet implies. Certificate pinning breaks it for many native apps and CLI tools, legal and works-council constraints limit it in the EU, and most organizations carve out broad exemption lists that AI traffic happily rides through. The OAuth and Embedded AI Problem CASBs Can’t See When an employee grants an AI meeting-notes tool access to their calendar and mailbox via OAuth, no proxy is involved at all. The vendor’s servers communicate directly with Microsoft’s or Google’s APIs using a persistent token. The same applies to AI features embedded inside sanctioned SaaS, think Notion AI, Slack AI, or Salesforce Einstein. The CASB sees approved traffic to an approved app, while the AI processing happening inside it, and whichever sub-processor it forwards data to, stays invisible. Personal Accounts and BYO-AI Bypass CASB Proxies Netskope’s 2026 Cloud and Threat Report found that nearly half of employees who use generative AI at work do so through personal accounts. Personal accounts on managed devices are hard enough; personal accounts on personal devices, home networks, and mobile connections never touch the corporate proxy path at all. Tenant restrictions help for a handful of major providers and do nothing for the long tail. Browser-Based and Extension-Delivered AI Escape Network Inspection AI browser extensions read page content and form inputs locally, then exfiltrate via their own backend, often to generic cloud infrastructure that categorizes as “technology” rather than “AI”. From the network’s view, it is routine HTTPS to a CDN. The riskiest interaction, an extension scraping everything an employee views, produces the most boring traffic signature. Insider Note: In AI governance readiness assessments, the OAuth grant review is where clients get the biggest surprise. We routinely find dozens of AI tools holding live mail, calendar, or drive scopes that nobody in IT ever approved, granted by employees who abandoned the tool (and sometimes the company) months earlier. The tokens keep working anyway. Why DLP Fails to Catch Shadow AI Data Exposure DLP has the opposite problem. It can sometimes see content, but it doesn’t understand it, and AI interactions defeat the pattern matching it depends on. Prompt-Based Data Loss Doesn’t Match DLP Signature Patterns DLP fires on signatures: credit card regexes, SSN formats, keyword dictionaries, file fingerprints. Sensitive prompts rarely look like that. “Summarize why we’re losing
Most SOC 2 preparation effort goes into access controls, encryption, and vendor reviews. Then the auditor’s first evidence request arrives, and item one has nothing to do with technology: show us your board charter, your meeting minutes, and proof that your board operates independently from management. That’s CC1.2, and it causes more last-minute scrambling than almost any technical control in the framework. This guide explains what CC1.2 requires, provides a board charter template with sample language that auditors accept, and covers the situation most startups actually face: satisfying the criterion without a traditional board of directors. What Is a SOC 2 Board Charter and Why It Matters for CC1.2 A board charter is a formal document that defines your board’s purpose, composition, authority, meeting procedures, and oversight responsibilities. Outside of compliance, it’s a corporate governance tool and a good idea in general for companies with shareholders. Inside a SOC 2 audit, it’s the primary design evidence for CC1.2, the criterion that asks whether an independent body oversees management and the internal control environment. The charter matters because CC1.2 is one of the few criteria where the control is a document plus behavior. The charter establishes the structure. The auditor then tests whether the structure operates: did the board actually meet, did it review the security program, did it challenge management? A beautifully drafted charter with no meeting minutes behind it fails just as surely as no charter at all. If you’re earlier in your preparation, our complete SOC 2 guide covers how the full audit fits together. Understanding CC1.2: The Board Independence Criterion CC1.2 is part of the Trust Services Criteria published by the AICPA (American Institute of Certified Public Accountants). The criterion requires that the board of directors, in the AICPA’s words, “demonstrates independence from management and exercises oversight” of how internal control is developed and how it performs. That sentence hides two separate tests. Independence means the board isn’t just management wearing a second hat. Active oversight means the board actually reviews and challenges the control environment instead of existing on paper. Plenty of companies pass one and fail the other. How CC1.2 Fits Within the CC1 Control Environment The Common Criteria run from CC1 through CC9, and the CC1 series covers the control environment: the governance and people layer everything else rests on. CC1.1 addresses integrity and ethical values, CC1.2 addresses board independence and oversight, CC1.3 covers organizational structure and reporting lines, CC1.4 covers competence and hiring, and CC1.5 covers accountability. CC1.2 is the layer that makes the other four credible. A code of conduct means little if nobody independent of management ever checks whether leadership follows it. The COSO Principle 2 Connection The Trust Services Criteria are built directly on the COSO Internal Control—Integrated Framework and its 17 principles. CC1.2 maps to COSO Principle 2, which carries four points of focus: the board establishes oversight responsibilities, applies relevant expertise, operates independently of management, and provides oversight of the system of internal control. Those four phrases are worth memorizing, because they’re effectively the outline of a good board charter. Why Auditors Prioritize Board Charter Evidence Auditors test the control environment first because failures there cascade. If governance is weak, every other control claim gets harder to trust: who approved the risk assessment, who reviewed the incident report, who held management accountable when a control slipped? An exception at CC1.2 tells the auditor that nobody independent was watching, and they’ll read the rest of your evidence with that in mind. That’s why board charter requests sit near the top of almost every evidence list. Worth Knowing: Points of Focus Points of focus are not pass/fail requirements. The AICPA describes them as characteristics that assist evaluation, and the 2022 revisions changed points of focus without changing any criteria. In practice, though, they function as the auditor’s mental checklist, so drafting your charter against them is the safest move. What Auditors Actually Look For in a Board Charter Auditors don’t grade prose style. They scan for specific, verifiable commitments. Here’s what they check, roughly in order. Documented Board Independence from Management The charter must state how many members are independent, define what independence means (no operational role, no material financial relationship beyond board compensation or equity), and describe how independence is maintained. “The board includes members independent of management” without a definition is boilerplate; auditors want criteria they can test against actual member profiles. Defined Oversight Responsibilities This is the heart of CC1.2. The charter should explicitly assign the board oversight of internal control, information security, and risk management. If the charter only mentions financial oversight and strategy, it wasn’t written with SOC 2 in mind, and the auditor will notice the gap. Clear Authority and Decision-Making Powers What can the board approve, veto, or demand? Typical provisions include approving the risk management framework, reviewing audit results, approving executive appointments, and requiring management to report on control deficiencies. Authority without teeth reads as decorative. Meeting Cadence and Quorum Requirements The charter should commit to a minimum meeting frequency (quarterly is the common standard) and define a quorum. This clause matters more than founders expect, because it’s the one auditors test directly against your calendar: if the charter says quarterly and you met twice last year, that’s an exception you wrote for yourself. Committee Structures Larger organizations delegate through audit, risk, and compensation committees, each with its own mini-charter. Smaller companies don’t need committees, but if your charter mentions them, they must exist and produce minutes. Never copy a public-company template with a phantom audit committee. Conflict of Interest Provisions A disclosure and recusal process for conflicts, usually paired with an annual attestation. This clause supports the independence claim: independence isn’t a one-time status, it’s maintained through disclosed and managed conflicts. Evidence of Board Member Expertise and Qualifications COSO’s “applies relevant expertise” point of focus means the board should be able to ask probing questions about security and risk, not just finance. Charters increasingly include a skills expectation clause, and
Most Drata reviews are written by Drata’s competitors. Scroll the first page of Google and you’ll find review posts from rival compliance platforms, each one ending with a pitch for their own tool. This one is different, and the bias runs the other way, so let’s put it on the table: Axipro is a Drata Gold Partner, and our consultants configure the platform for clients every week. That means we profit when companies choose Drata. It also means we know exactly where it saves you months, where the invoice grows faster than you planned, and when you should pick something else. This review covers all three. What Is Drata? Drata is a compliance automation platform (the industry calls the category GRC, for governance, risk, and compliance) founded in 2020 in San Diego by Adam Markowitz, Daniel Marashlian, and Troy Markowitz. Its core job: connect to your cloud infrastructure, identity provider, HR system, and code repositories, then continuously test your security controls against frameworks like SOC 2 and ISO 27001, collecting timestamped evidence as it goes. When your auditor shows up, most of the evidence is already packaged. Funding, Valuation, and Market Position Drata has raised $328 million, most recently a $200 million Series C in late 2022 that valued the company at $2 billion. It passed $100 million in annual recurring revenue in early 2025, acquired the trust center platform SafeBase for $250 million the same year, and now serves more than 8,000 customers. In late 2025 it earned a FedRAMP 20x Low Pilot Authorization, which puts it in a small group of compliance platforms cleared through the U.S. government’s modernized FedRAMP review track. Together with Vanta, it’s one of the two platforms almost every compliance buyer shortlists. Who Drata Is Built For The sweet spot is cloud-native companies from seed stage to mid-market: SaaS businesses pursuing their first SOC 2 or ISO 27001, and scaling teams juggling three or four frameworks at once. If your infrastructure lives in AWS, Azure, or GCP and your team uses standard tools like Okta, GitHub, and a mainstream HRIS, Drata’s automation covers a large share of your evidence collection out of the box. The further you drift from that profile (heavy on-prem systems, exotic tooling, air-gapped environments), the more manual work remains. How Drata Works: From Connection to Audit The workflow runs in five stages. First, you connect your tech stack through more than 270 native integrations covering cloud providers, identity, version control, HRIS, MDM, and ticketing. Second, continuous control monitoring kicks in: automated tests run around the clock against your connected systems, checking things like MFA enforcement, encryption settings, and access reviews. Third, automated evidence collection captures timestamped proof each time a test passes, building the evidence library your auditor will draw from. Fourth, when a test fails, remediation workflows and alerts route the issue to an owner through Slack, Jira, or email, with guidance on how to fix it. Fifth, the Audit Hub gives your auditor a scoped login to review evidence directly in the platform instead of trading spreadsheets and screenshots over email. In our client engagements, that last piece cuts back and forth more than any other feature. Auditors ask fewer clarifying questions when they can trace evidence to its source themselves. Drata’s Core Features Reviewed Overview of the Drata platform and compliance management dashboard. Multi-Framework Control Mapping Drata maintains a single control set mapped across every framework you activate. Pass an encryption control once, and it satisfies the corresponding requirements in SOC 2, ISO 27001, and HIPAA simultaneously. For multi-framework programs, this is the feature that pays for the platform. Adding ISO 27001 to an existing SOC 2 program typically starts you at 60 to 80 percent complete rather than zero. The Drata Agent The Drata Agent is a lightweight application installed on employee laptops. It checks device posture: screen lock, disk encryption, password manager, antivirus, OS updates. It reads configuration states, not files, browsing history, or keystrokes. Employees sometimes push back on installing it anyway, which is why we advise clients to communicate what it does and doesn’t see before rollout, not after the first complaint. Companies with an existing MDM like Jamf or Intune can often pull device evidence from that integration instead. Risk Management, Vendor Risk, and the Trust Center The built-in risk register lets you score risks by likelihood and impact and tie them to controls and remediation tasks. Vendor risk management got a genuine upgrade with the August 2025 agentic AI release, which now collects vendor evidence, reviews SOC 2 reports, and drafts risk summaries with far less manual chasing. The Trust Center, built on the acquired SafeBase product, gives you a public page where prospects can review your certifications and policies under NDA. Clients in active enterprise sales cycles tell us it measurably shortens security review, though note it’s a paid add-on at most tiers, not a bundled feature. Policies, Training, and the Rest Drata ships editable policy templates for every major framework, embedded security awareness training with completion tracking, and an API for anything the native integrations miss. The policy templates are a real accelerator for first-time programs, with one caveat we see constantly: teams accept templates wholesale without adapting them, then get flagged in audit when their actual practice doesn’t match their written policy. A template you don’t follow is worse than no template. Supported Compliance Frameworks Drata supports more than 30 frameworks. The ones that matter for most buyers: SOC 2 (Type I and Type II) against the AICPA Trust Services Criteria, ISO 27001, HIPAA (where Drata operationalizes safeguards, since no formal HIPAA certification exists), GDPR under the EU data protection rules, and PCI DSS. Coverage extends to CMMC, NIS2, DORA, FedRAMP, and various NIST standards. You can also build custom frameworks by mapping your own control set, useful for internal standards or customer-specific requirements. What Users Really Say Drata holds a 4.8 out of 5 on G2 across more than 1,100 reviews, the highest score among the
Vanta is worth it for most cloud-native companies chasing their first SOC 2 or ISO 27001. It’s a harder call if you run on-prem infrastructure, have unusual evidence requirements, or a budget that can’t absorb a renewal surprise. That’s the short answer. The longer one comes down to three things: how much of the platform’s automation applies to your stack, what the contract costs by year two, and how much compliance expertise you have in-house. This review draws on Vanta’s 2026 product releases, third-party procurement data, review platforms, and our experience at Axipro as a Vanta partner implementing the platform for clients across SOC 2, ISO 27001, and ISO 42001 engagements. We work inside the tool every week. We also see exactly where it stops working, and a human has to pick up. What Is Vanta? A Quick Overview Vanta is a compliance automation platform that now calls itself an Agentic Trust Platform. It connects to your cloud infrastructure, identity provider, code repositories, HR system, and device fleet, then runs continuous automated tests against the controls your target framework requires. It collects evidence on its own, maps it to controls, and packages the whole thing for your auditor. Vanta at a Glance Founded in 2018, Vanta now serves more than 15,000 customers, from early-stage startups to names like Atlassian, Duolingo, and Icelandair. The platform supports 35+ frameworks, ships 400+ integrations (the deepest library in the category), and runs over 1,400 pre-built automated tests. In 2026, Forrester named Vanta a Leader in The Forrester Wave: Governance, Risk, and Compliance Platforms, Q2 2026, the first time it appeared in the evaluation. Who Vanta Is Built For (Startups, Mid-Market, Enterprise) Startups remain the core market: roughly 58% of Vanta’s G2 reviews come from small businesses, typically SaaS companies that need a SOC 2 report to close their first enterprise deals. Mid-market teams use it to run multiple frameworks off shared evidence. The enterprise push is newer. In March 2026, Vanta shipped an Organizations Center and adaptive business unit scoping, which lets larger companies segment compliance by product, region, or team inside a single workspace instead of duplicating controls across accounts. Frameworks Vanta Supports Coverage includes SOC 2 (Type I and Type II), ISO 27001, ISO 42001 for AI management systems, HIPAA, GDPR, HITRUST, FedRAMP, PCI DSS, and the NIST AI RMF, among 35+ total. The AI governance coverage matters more each quarter: ISO 42001 and NIST AI RMF requests now show up in security questionnaires that had never mentioned AI before 2025. Vanta Key Features Reviewed Overview of the Vanta platform and compliance management dashboard. Continuous Controls Monitoring This is the engine. Vanta’s 1,400+ tests run continuously against AWS, GCP, Azure, Okta, GitHub, and whatever else you’ve connected: are S3 buckets encrypted, is MFA enforced, are background checks done on time, does anyone hold access they shouldn’t? Failing controls get flagged with remediation guidance and SLA tracking, so compliance stops being an annual scramble and turns into something you maintain as you go. Automated Evidence Collection Instead of screenshots and spreadsheet exports, evidence flows in from your integrations and lands on the right controls. Cross-mapping is the underrated part: evidence you collect for SOC 2 gets reused for ISO 27001, HIPAA, or ISO 42001, which is why adding a second framework on Vanta takes weeks rather than months. The Vanta AI Agent (2026 Update) The AI Agent launched in mid-2025 and has moved fast since. In November 2025, Vanta rebuilt it as AI Agent 2.0, the core of the new Agentic Trust Platform, alongside a Risk Graph and Customer Commitments tracking. In March 2026, dedicated agents for compliance, third-party risk, and customer trust workflows. In June 2026, the Vanta Agent for Risk unified internal and vendor risk into one continuously updated view. In practice, the agent scans your program for inconsistencies, drafts policy change summaries for annual reviews, suggests control mappings when you upload policies, validates evidence before audits, and flags questionnaire gaps before they slow a security review. Vanta pitches it as a 24/7 GRC engineer. That’s marketing, but not empty marketing: it takes real hours of tedious work off your plate. Every draft still needs a human review before adoption, and the agent does its best work when a question maps to evidence you already hold. Insider Note: The AI Agent is only as good as its signal. If a large slice of your stack sits outside Vanta’s 400+ integrations, its suggestions shift from precise to generic. Test it against your actual environment during a trial, not a polished demo tenant. Policy, Vendor Risk, and Training Modules Policy templates cover the standard library, with AI-assisted drafting and version tracking. Vendor Risk Management (VRM) is a paid add-on that collects vendor evidence and generates AI risk summaries, feeding the broader third-party risk management picture. Security awareness training is built in, which removes one more standalone tool from the stack. Trust Center and Questionnaire Automation The Trust Center gives you a public page where prospects self-serve your security posture, and questionnaire automation drafts answers to inbound security reviews. Vanta reports automating over 80% of questionnaire responses with up to a 95% acceptance rate and 81% faster review completion. Those are vendor numbers, so apply a discount, but the direction matches what users report. Watch the caps: lower tiers limit automated questionnaires per year, and enterprise sales teams burn through those limits quickly. Access Reviews Access review campaigns pull directly from your identity provider, so quarterly reviews become a guided approval flow instead of a spreadsheet exercise. It’s a strong module; just know it sits in the Plus tier and above, not the entry plan. Vanta Pros and Cons (Honest Breakdown) Pros: Where Vanta Excels The integration library is the deepest in the category, and it shows during onboarding: most tests light up within days for a standard cloud stack. Auditor familiarity is a real, compounding advantage, since most CPA firms know Vanta’s exports and ask fewer clarification questions. Cross-framework evidence reuse
Learn how organizations can use the EU AI Act to build trust, speed up innovation, strengthen procurement, and gain a competitive advantage through effective AI governance. The Biggest Mistake Organizations Make About the EU AI Act When executives hear “EU AI Act,” their first thought is usually: another regulation, another compliance project, another expense. And who could blame them? Between GDPR, DORA, and NIS2, businesses are under real pressure to show they handle technology responsibly. Here’s what most of them miss, though. Complying with the EU AI Act does more than keep you clear of fines. Done well, it becomes a selling point. Companies that treat AI governance as a strategic skill earn customer trust and close enterprise deals faster. That matters because customers, investors, and regulators are asking tougher questions about AI than ever: Can you explain your AI decisions? How do you manage bias? Who’s accountable when something goes wrong? What controls protect sensitive data? The EU AI Act gives you a framework for answering them. When you can show good governance, you satisfy regulators, and you also win over the customers and partners deciding whether to trust you in the first place. That trust is worth real money in the AI era. And good governance doesn’t mean more bureaucracy. It means consistency. With clear ownership, defined risk processes, and transparent documentation, AI projects become easier to run and easier to scale. Teams stop reinventing governance for every new initiative and follow a repeatable framework instead, which speeds up decisions and cuts uncertainty. Companies with mature AI governance are already seeing this play out. They build more customer confidence in their AI products and answer procurement and due diligence requests in days instead of weeks. They run less risk of expensive AI failures or reputational damage, look credible to investors and regulators, and roll out AI consistently across the organization. In a market where trust increasingly drives purchasing decisions, that shows up in revenue. A McKinsey survey on the state of AI found that organizations investing in responsible AI practices are better positioned to capture value as adoption scales. Three Steps to Get Started You don’t need to transform the whole organization at once. Here’s where you can start: First, map your AI environment. Build an inventory of AI systems and know where they’re being used. You can’t govern what you can’t see, and most organizations are surprised by how many AI tools are already in play across teams. Second, spot risk early. Work out which high-risk use cases exist and build governance into the development lifecycle. The EU AI Act classifies systems by risk level, so knowing where your use cases fall tells you exactly how much scrutiny each one needs before it ships. Third, fold governance into existing processes. Add AI governance to your security, privacy, and enterprise risk programs instead of running it as a separate effort. This is where recognized standards like ISO/IEC 42001 pull their weight, giving you a structured management system that slots into what you already have rather than bolting on yet another silo. That’s enough to set your organization up for the long run. The debate around the EU AI Act shouldn’t be about staying on the right side of regulation. It should be about building AI that people trust and that you can actually scale. Organizations that put governance in place now will innovate faster and earn a stronger market reputation while their competitors scramble to catch up. In a few years, the edge will go to the companies that govern AI best, not the ones that use it the most. Is your organization preparing for the EU AI Act? Start by assessing your AI governance maturity and aligning your AI strategy with recognized frameworks like ISO/IEC 42001 and the NIST AI RMF, and turn compliance into a business advantage.
ISO/IEC 27001 certificates nearly doubled in a single year, from 48,671 in 2023 to 96,709 in 2024, according to ISO’s own certification survey. A big share of that jump comes from startups, not enterprises. The reason is simple: buyers stopped taking “we take security seriously” at face value, and a certificate is the fastest way to prove it. This guide covers when a startup should pursue ISO 27001, what it costs, how long it takes, and how a small team gets certified without a dedicated security department. What Is ISO 27001 and Why It Matters for Startups ISO/IEC 27001 is the international standard for information security management. It doesn’t hand you a checklist of firewalls to buy. Instead, it asks you to build and run an Information Security Management System (ISMS): a documented, repeatable way of finding your security risks and doing something about them. Certification means an accredited third party checked that your ISMS works and matches the standard. For a startup, that distinction matters. You’re not being graded on whether you own expensive tools. You’re being graded on whether you can show a system, which is exactly what an enterprise buyer’s procurement team wants to see before they sign. The Core Principles: Confidentiality, Integrity, and Availability Everything in ISO 27001 traces back to the CIA triad: confidentiality, integrity, and availability. Confidentiality means only the right people see the data. Integrity means the data is accurate and hasn’t been tampered with. Availability means the data is there when someone needs it. Every control you put in place, and every risk you assess, ties back to protecting one of those three properties. ISO puts it plainly: an ISMS that meets the standard preserves the confidentiality, integrity, and availability of information by running a risk management process. Keep the triad in mind, and the rest of the framework stops feeling abstract. How ISO 27001 Differs from Other Security Frameworks for Early-Stage Companies SOC 2 is the framework startups usually bump into first, especially when selling into the US. It results in an attestation report from a CPA firm, scoped to specific systems. ISO 27001 is a certification, recognized in over 150 countries, and it covers your whole organization through a formal ISMS with management reviews and company-wide risk assessment. The two overlap heavily. Roughly 70 to 80 percent of the controls line up, so if you do one, the second gets much cheaper. The real difference is structure. SOC 2 checks whether specific controls work. ISO 27001 checks whether you’ve built a management system that keeps those controls working over time. It also aligns closely with GDPR, which is why it travels well in Europe. Insider Note: Auditors can usually tell within an hour whether your ISMS is real or was assembled the week before the audit. A management review meeting with actual notes, decisions, and follow-ups from three months ago is worth more than a perfect-looking policy binder with no evidence anyone ever used it. When Should a Startup Pursue ISO 27001 Certification? The honest answer: when a deal, a market, or an investor is asking for it, or is about to. Certifying purely because it feels responsible is a good way to burn cash and calendar time you don’t have yet. Early-Stage vs. Growth-Stage: Timing the Certification At pre-seed and seed, ISO 27001 is usually early unless you’re selling into regulated industries or the EU from day one. Your product and processes are still shifting, and certifying a moving target means re-documenting everything a quarter later. At Series A and beyond, the math changes. Deals get bigger, buyers get more careful, and investor due diligence starts probing your security posture. Certifying while you’re 15 to 40 people is often the sweet spot: mature enough to have stable processes, small enough that scoping the ISMS is still manageable. When ISO 27001 Might Be Overkill for Your Startup If your customers are US SMBs who only ever ask for SOC 2, leading with ISO 27001 may be solving a problem you don’t have. If you’re pre-revenue and still hunting for product-market fit, your time is better spent shipping. And if no one in your sales pipeline has ever mentioned a certificate, that silence is data. Pro Tip: Pull your Last 20 Security Questionnaires Before you commit, pull your last 20 security questionnaires or RFPs and count how many explicitly asked for ISO 27001 versus SOC 2 versus nothing. That single tally answers the “which framework, and when” question faster than any consultant’s discovery call. Key Benefits of ISO 27001 for Startups Unlocking Enterprise Sales and Bigger Deals The clearest return is revenue you couldn’t touch before. Large buyers often won’t even start a security review without a recognized certificate on file. ISO 27001 gets you past the first gate of enterprise sales, and it shortens the review itself because a big chunk of the questionnaire is already answered by your certification. Building Investor and Board Confidence Certification signals operational maturity. When an investor sees a functioning ISMS, they see a founder who can build systems, not only ship features. That plays well in investor due diligence, where a security gap can stall a term sheet, and it gives your board something concrete to point to on risk. Establishing Customer Trust from Day One A certificate is third-party proof, and third-party proof beats self-assurance every time. For a young company with no brand equity yet, it’s a shortcut to being taken seriously by customers who’ve never heard of you. Creating a Scalable Security Foundation Because ISO 27001 makes you build a system rather than a one-off fix, it scales as you grow. New hires, new products, and new data types slot into an ISMS you already run. You’re not rebuilding security from scratch at every stage. Reducing Long-Term Compliance Costs Adding SOC 2, HIPAA, or ISO 42001 later is far cheaper once an ISMS exists, thanks to that 70 to 80 percent control overlap. The first framework is the expensive one.
Most organizations think their AI governance is further along than it is. McKinsey’s 2026 AI Trust Maturity Survey of roughly 500 organizations found an average maturity score of 2.3 out of 4, and only about a third reported level three or higher in strategy, governance, and agentic AI oversight. Adoption is outpacing control, and regulators have noticed. An AI governance maturity model gives you a way to measure that gap honestly. This guide covers what a maturity model is, the six dimensions it should measure, the five levels most models use, and how to assess your own organization and build a roadmap to the next level. What Is an AI Governance Maturity Model? An AI governance maturity model is a structured framework that describes how capable an organization is at governing its AI systems, usually across five progressive levels. The concept borrows directly from the Capability Maturity Model (CMM) that software engineering has used since the early 1990s: define the capability, describe what it looks like at each stage of development, and score yourself against it. The purpose is diagnosis. A maturity model tells you where governance is strong, where it’s theater, and where it doesn’t exist at all. How It Differs from General AI Governance Frameworks Frameworks like the NIST AI Risk Management Framework or ISO/IEC 42001 tell you what good governance contains: policies, risk assessments, accountability structures, monitoring. A maturity model tells you how well you’re doing those things today. The framework is the destination. The maturity model is the odometer. That distinction matters in practice. Plenty of companies can point to an AI policy document. Far fewer can show that the policy changes what teams actually ship. Why Enterprises Need a Maturity Model Three reasons. First, budget: you can’t prioritize governance investment without knowing which dimension lags. Second, accountability: a maturity score gives boards something concrete to track quarter over quarter. Third, regulation: the EU AI Act and frameworks like ISO 42001 assume a functioning management system, and a maturity assessment is the fastest way to find out whether yours would survive scrutiny. Core Dimensions of an AI Governance Maturity Model A useful model measures more than policy coverage. Six dimensions show up consistently across the credible models, including the IEEE-USA flexible maturity model built on the NIST AI RMF. Strategy and leadership. Does the organization have a stated position on AI risk, an executive owner (increasingly a Chief AI Officer), and board visibility? Gartner’s 2025 polling found 55% of organizations now have an AI board or dedicated oversight committee, which means nearly half still govern by improvisation. Policies, standards, and accountability. Written policies mapped to regulations, a RACI matrix for AI decisions, and clear escalation paths. Many organizations adapt the three lines of defense model from financial risk: the teams building AI, the risk function overseeing them, and internal audit checking both. Data governance and model lifecycle. Training data lineage, quality controls, and lifecycle management from development through deployment, monitoring, and retirement. This is where AI governance meets MLOps, and where mature organizations maintain an AI register, a live inventory of every model and system in production. Risk, compliance, and ethics. Risk classification of AI systems, impact assessments, bias and fairness testing, and explainability requirements. Banks will recognize the DNA of model risk management under SR 11-7 here. People, skills, and culture. Training, role clarity, and whether people outside the governance team actually understand their obligations. Tools, automation, and monitoring. Drift detection, automated policy checks, audit logging, and dashboards. Governance that lives in spreadsheets caps out around level three. The 5 Levels of AI Governance Maturity Level 1: Ad Hoc / Initial AI use happens without oversight. There’s no inventory, no policy, or a policy nobody follows. Shadow AI is common, and risk surfaces only when something breaks publicly. Level 2: Developing / Repeatable Someone has been assigned responsibility. A draft policy exists, a partial inventory exists, and reviews happen for high-profile projects. The practices are repeatable but depend on specific people rather than defined processes. Level 3: Defined / Structured Governance is documented, standardized, and applied across the organization. There’s a governance committee, a risk classification scheme, defined lifecycle gates, and mandatory training. Most organizations pursuing ISO 42001 certification are working to reach and formalize this level. Level 4: Managed / Metrics-Driven Governance produces numbers. Coverage rates, review cycle times, incident counts, and risk reduction are measured and reported to leadership. Controls are enforced by tooling rather than goodwill, and audits confirm the system works as described. Level 5: Optimized / Adaptive Governance improves itself. Monitoring feeds back into policy, controls adapt to new model types (agentic systems being the current test), and the organization anticipates regulatory change rather than reacting to it. Almost nobody is here yet, and that’s fine. Level 5 is a direction, not a deadline. Insider Note: In assessments, the most common self-scoring error is claiming level 3 on the strength of documents alone. If your policy says every model gets a pre-deployment review and your inventory shows 40 models but your review log shows 6, you’re at level 2. Evidence beats paperwork every time, and auditors check the logs first. AI Governance Maturity Matrix The matrix crosses dimensions with levels so you can score each one independently. Organizations are rarely uniform: it’s normal to sit at level 3 on policy and level 1 on monitoring. For scoring, keep the rubric simple: 1 to 5 per dimension, scored on evidence you could show an auditor, not on intentions. Board-level indicators (does the board see AI risk reporting?) and operational indicators (does every production model have a completed impact assessment?) should be scored separately, because they fail independently. How to Assess Your Current AI Governance Maturity Start with a baseline self-assessment. Pull together a cross-functional group covering engineering, legal, risk, security, and the business owners of major AI use cases, and score each dimension against the matrix. Half a day is usually enough for a first pass. For each dimension, the
Most organizations get ISO 42001 certified in 2 to 9 months. Companies that already hold ISO 27001 regularly land in the 2 to 5 month range, while enterprises with sprawling AI portfolios and no existing management system can take 12 months or more. The audit itself only takes days. Almost the entire calendar goes into building and operating your AI Management System (AIMS) long enough to produce evidence an auditor can actually check. That is the short answer. The longer answer depends on your starting point, your scope, and how quickly you can get a certification body on the schedule. This article breaks down the full timeline phase by phase, the factors that stretch or compress it, and what the recertification cycle looks like once you hold the certificate. Typical ISO 42001 Certification Timeline at a Glance ISO/IEC 42001:2023 is the first international standard for AI management systems, published in December 2023. Because it follows the same harmonized structure as ISO 27001 and ISO 9001, the certification process will feel familiar to anyone who has been through a management system audit: build the system, run it, pass a Stage 1 and Stage 2 audit, then maintain it through annual surveillance. Here is how timelines typically break down by company size. Average Timeline for Small Businesses Small companies move fastest because scope stays contained. A startup with two or three AI systems, a handful of decision makers, and short approval chains can finish scoping in a week and get policies signed off in days rather than weeks. The realistic floor for a small business starting from scratch is around 3 months. With an existing ISO 27001 program and a compliance platform already collecting evidence, 2 months is achievable. Average Timeline for Mid-Sized Companies Mid-sized companies usually take 6 to 9 months. The AI inventory is growing, more departments are touching AI systems, and risk assessments have to cover more use cases. Coordination becomes the hidden cost: getting engineering, legal, and product to agree on an AI policy takes longer than writing the policy itself. Average Timeline for Enterprises Enterprises should plan for 9 to 12 months, sometimes longer. The main drivers are AI system sprawl across business units, longer procurement cycles for certification bodies, and audits that take more days. The Stage 2 audit for a large multinational can run two weeks or more on its own, and internal alignment before the audit takes far longer than the audit itself. Breakdown of the ISO 42001 Certification Timeline by Phase The phases below overlap in practice. Treat the durations as effort estimates for a reasonably resourced program, not a strict sequence. Phase 1: Scoping and Gap Analysis (2–4 Weeks) Everything starts with two questions: which AI systems are in scope, and how far is your current governance from what the standard requires? The gap analysis maps your existing policies and controls against the standard’s clauses and Annex A controls, and produces the project plan for everything that follows. Get the scope wrong here and every later phase inherits the mistake. Phase 2: AIMS Design, Leadership, and AI Policy Development (2–4 Weeks) This phase establishes the skeleton of the management system: the AI policy, governance roles, objectives, and the leadership commitments the standard requires. Executive sign-off is the gating item. The documents are not hard to write. Getting senior leadership to formally own AI governance is where programs stall. Phase 3: AI Risk and Impact Assessments (2–6 Weeks) ISO 42001 requires both AI risk assessments and AI impact assessments, and the distinction matters. Risk assessments look at what could go wrong for the organization. Impact assessments look at consequences for individuals and society, which is a newer discipline for most teams. This phase takes longer when you have many AI systems, high-risk use cases, or no prior methodology to adapt. The output feeds directly into your Statement of Applicability (SoA), the document that maps which Annex A controls you have selected and why. Insider Note: Impact assessments are where auditors probe hardest, because they are the most distinctive part of ISO 42001 compared with ISO 27001. A recycled security risk register with “AI” pasted into it will get picked apart in Stage 2. Build the impact assessment methodology properly the first time. Phase 4: Controls Implementation (2–10 Weeks) The longest phase. Here you implement the Annex A controls selected in your SoA: AI system lifecycle documentation, data governance for training data, human oversight mechanisms, transparency measures, supplier management for third-party AI, and so on. Duration depends almost entirely on the gap analysis results. Organizations with mature engineering practices often find they already do much of this and just need to document it. Organizations without formal AI development processes are building from zero. Phase 5: Documentation, Training, and Evidence Collection (2–8 Weeks) Certification requires proof that the system operates, not just that it exists on paper. That means records: training completion logs, risk assessment outputs, review meeting minutes, monitoring reports. This phase runs partly in parallel with implementation, but it cannot be compressed below a certain floor because auditors want to see evidence generated over time, not a folder of documents all created the week before Stage 1. Phase 6: Internal Audit and Management Review (2–4 Weeks) The standard requires an internal audit of the AIMS and a formal management review before the certification audit. This is your dress rehearsal. A good internal audit surfaces nonconformities while they are still cheap to fix. Skipping or rushing it is a false economy that shows up later as Stage 2 findings. Phase 7: Stage 1 Certification Audit (1–2 Weeks) The certification body reviews your documentation and assesses readiness for Stage 2. The audit itself takes 1 to 3 days for most organizations. The auditor examines your scope statement, AI policy, risk and impact assessment methodology, SoA, and internal audit results, then issues findings. The 1–2 week window covers the audit plus the report. Phase 8: Closing Nonconformities (2–4 Weeks) Almost every Stage 1 produces findings.
CMMC requirements started appearing in Department of Defense contracts on November 10, 2025, when the final DFARS rule took effect. By November 10, 2028, the clause at DFARS 252.204-7021 must appear in every solicitation and contract where contractor systems process, store, or transmit Controlled Unclassified Information (CUI). For most of the Defense Industrial Base (DIB), the math is blunt: pass a CMMC assessment or lose eligibility for DoD work. A CMMC readiness assessment is how you find out whether you’d pass before the stakes are real. It’s a structured review of your environment, documentation, and evidence against the requirements of the Cybersecurity Maturity Model Certification, done before you sit for a self-assessment or a Certified Third-Party Assessment Organization (C3PAO) audit. A good one tells you exactly where you stand and what to fix first. This guide covers what a readiness assessment includes, how the process works at each CMMC level, what it costs, how long it takes, and how to pick someone to run one. What Is a CMMC Readiness Assessment? A CMMC readiness assessment is a pre-certification evaluation that measures your organization against the specific requirements of your target CMMC level. It examines your scope, implemented controls, System Security Plan (SSP), Plan of Action and Milestones (POA&M), and the evidence supporting them, then produces a gap analysis and a remediation roadmap. The purpose is simple: surface every deficiency while it’s still cheap to fix. An assessor who finds a scoping error during a readiness review costs you a few weeks of rework. A C3PAO who finds the same error during a certification assessment can cost you the assessment fee, months of delay, and in some cases contract eligibility. How It Differs From an Official C3PAO Audit An official CMMC Level 2 certification assessment is conducted by a C3PAO accredited by the Cyber AB, the official accreditation body for the CMMC ecosystem. The C3PAO’s findings are binding. Results go into the DoD’s assessment systems, and a passing result produces a CMMC status that contracting officers verify before award. A readiness assessment carries no official weight. Nothing gets filed or certified, and a poor result costs you nothing beyond the work needed to fix it. That’s the whole point. It’s the only stage in the entire process where failure is free. There’s also a conflict-of-interest rule worth knowing. A C3PAO cannot provide consulting and remediation services to an organization and then certify that same organization. If a C3PAO helps you prepare, a different C3PAO has to assess you. How It Differs From a Mock Assessment A mock assessment is a dress rehearsal. It simulates the certification assessment itself: assessors interview control owners, request evidence on the spot, and score findings the way a C3PAO would. A readiness assessment is broader and comes earlier, and its job is discovering and closing gaps rather than rehearsing the exam. Most organizations run a readiness assessment first, remediate, then run a mock assessment a few weeks before the real one to see whether staff and evidence hold up under live questioning. How It Differs From a Self-Assessment A self-assessment is a formal CMMC mechanism rather than a preparation exercise. CMMC Level 1 and a subset of Level 2 contracts let organizations self-assess, post the results to the Supplier Performance Risk System (SPRS), and have a senior official affirm compliance annually. That affirmation is a representation to the government, and false or careless affirmations carry False Claims Act exposure. A readiness assessment is the check you run before making that representation, so the number you affirm reflects reality. Why a CMMC Readiness Assessment Matters Avoiding Failed Certification Attempts CMMC Level 2 covers all 110 security controls of NIST SP 800-171, evaluated against 320 assessment objectives. Every objective has to be met for a control to score, and there’s no partial credit. Organizations that skip readiness work routinely walk into certification believing they’re compliant because controls are “mostly” implemented. Mostly implemented scores the same as not implemented. Protecting DoD Contract Eligibility Under the phased rollout that began in November 2025, CMMC status is a condition of award. Prime contractors also have to flow the requirement down to subcontractors that handle Federal Contract Information (FCI) or CUI, and they’ve been pushing their supply chains hard. So a missed certification hurts twice: you lose the immediate contract, and you risk dropping out of a prime’s approved supplier pool during the exact window when those pools are being rebuilt around CMMC status. Reducing Remediation Costs and Delays Gaps found early get fixed on your schedule with your choice of solution. Gaps found during certification get fixed under deadline pressure, often with whatever expensive tooling can be deployed fastest. There’s a conditional CMMC status for organizations that pass with a limited POA&M, but closeout has to happen within 180 days, and only certain lower-weighted controls are POA&M-eligible in the first place. Readiness work keeps you out of that corner. Worth Knowing: The DoD Assessment Methodology The DoD Assessment Methodology weights each NIST SP 800-171 control at 1, 3, or 5 points, deducted from a starting score of 110. The floor is -203. To achieve even a conditional Level 2 status, you need a minimum score of 88. A handful of unmet 5-point controls, such as FIPS-validated encryption or multifactor authentication, can put certification out of reach on their own, so a readiness assessment should always show the point weight attached to every gap. When to Conduct a CMMC Readiness Assessment Before your first self-assessment. If a contract requires a Level 1 or Level 2 self-assessment, run readiness work before you post a score to SPRS. The score you affirm is a legal representation, and it’s far easier to fix the environment than to explain a misstated score later. When contract requirements are approaching. If CMMC language has shown up in a solicitation you plan to bid, or your prime has set a certification deadline, count backward. Remediation after a readiness assessment typically takes six to twelve months for organizations starting
CMMC certification costs between $4,000 and $30,000 at Level 1, $30,000 to $300,000 or more at Level 2, and $100,000 to well over $1 million at Level 3. Most contractors expect the audit fee to be the big number. It isn’t. The formal assessment typically accounts for only 25% to 40% of total spend, with preparation, remediation, and technology upgrades consuming the rest. The stakes changed in late 2025. The final 48 CFR acquisition rule took effect on November 10, 2025, which means CMMC requirements now appear directly in Department of Defense (DoD) solicitations and contracts. Starting in November 2026, Phase 2 of the rollout gives contracting officers the authority to require third-party certification for Level 2 work. If you handle Controlled Unclassified Information (CUI), certification is no longer optional, and the cost question becomes a budgeting exercise rather than a hypothetical. This guide breaks down every major cost category, what moves your number up or down, and how to keep the total under control. What Is CMMC Certification and Why Does Cost Vary? The Cybersecurity Maturity Model Certification (CMMC) is the DoD’s framework for verifying that companies in the Defense Industrial Base (DIB) actually protect the sensitive information they handle. The program, codified in 32 CFR Part 170, builds on the security requirements of NIST SP 800-171 and, at the top tier, selected controls from NIST SP 800-172. Costs vary so widely because you can’t buy CMMC off a shelf. Your environment has to reach a certain state and then stay there. A 15-person machine shop with one well-scoped CUI enclave faces a fundamentally different project than a 500-person prime contractor with CUI flowing through a dozen systems. Your starting security posture, the scope of your assessment boundary, and whether you build internally or hire help all move the total by six figures in either direction. Average CMMC Certification Cost at a Glance The DoD’s own published estimates are instructive. A triennial Level 2 certification assessment, including affirmations, is projected at roughly $105,000 for small entities and $118,000 for larger ones. Those figures cover only assessment and affirmation activities, though. The DoD excludes implementation costs from its estimates on the grounds that NIST SP 800-171 compliance has been contractually required under DFARS 252.204-7012 since 2017. Your real budget has to cover both. CMMC Certification Cost by Level CMMC Level 1 (Foundational) Cost: $5,000 – $30,000 Level 1 covers Federal Contract Information (FCI) and requires 15 basic safeguarding practices drawn from FAR 52.204-21. Because Level 1 permits an annual self-assessment with no third-party auditor, the costs are internal labor, basic tooling, and documentation. Small contractors with reasonable IT hygiene often land near the bottom of the range. The DoD estimates annual Level 1 assessment and affirmation activity at around $6,000 for a small entity, with the remainder of the range driven by any remediation needed to attest honestly. CMMC Level 2 (Advanced) Cost: $50,000 – $300,000+ Level 2 is where most of the DIB lands and where budgets get serious. It requires full implementation of all 110 security requirements in NIST SP 800-171, assessed across 320 individual objectives. For most contracts, a C3PAO (Certified Third-Party Assessor Organization) accredited by the Cyber AB has to conduct the assessment every three years. Market data puts C3PAO assessment fees at $30,000 to $100,000 depending on scope, site count, and complexity. Preparation dwarfs that figure for most organizations. Companies starting from a low maturity baseline routinely spend three to four times the assessment fee on readiness work before an auditor ever shows up. CMMC Level 3 (Expert) Cost: $300,000 – $1,000,000+ Level 3 adds 24 enhanced requirements from NIST SP 800-172 on top of a completed Level 2 certification, and the assessment is conducted by the government’s DIBCAC rather than a commercial C3PAO. DIBCAC charges no assessment fee, but don’t mistake free for cheap. The DoD estimated roughly $41,000 in additional implementation cost for the 800-172 controls alone, and total triennial assessment-related costs in the $146,000 to $159,000 range. Real-world totals run far higher once you account for the advanced tooling, threat hunting capability, and organizational changes Level 3 demands. Only contractors supporting the most sensitive programs need this tier. Worth Knowing: You can’t skip to Level 3. You can’t skip to Level 3. A final Level 2 certification with all POA&M items closed is a prerequisite for the same assessment scope, so Level 3 budgets always include a full Level 2 project first. CMMC Certification Cost Breakdown by Expense Category Gap Assessment and Readiness Planning Costs A gap assessment maps your current environment against NIST SP 800-171 and typically costs $1,500 to $20,000 depending on depth and scope. This is the most valuable dollar you’ll spend in the entire project, because everything downstream is priced off what it finds. Documentation and System Security Plan (SSP) Costs The System Security Plan (SSP) is the cornerstone document of any assessment, mapping every control to your specific implementation. Professionally developed SSPs and supporting policies run $12,000 to $60,000. A weak SSP is one of the most common reasons assessments stall or fail, so this is a poor place to economize. Remediation and Security Control Implementation Costs Closing the gaps is usually the largest line item: $20,000 to $150,000 or more. Multi-factor authentication, logging and SIEM deployment, encryption, access control restructuring, and incident response capability all live here. Organizations with mature security postures spend far less than those starting from scratch. Technology and Infrastructure Upgrade Costs Many contractors move CUI into a dedicated enclave rather than securing their entire network. Enclave platforms typically cost $300 to $400 per user per month. Others upgrade endpoint protection, replace unsupported systems, or migrate to government-grade cloud environments, each with its own licensing and migration costs. C3PAO Assessment and Audit Fees The formal Level 2 assessment runs $30,000 to $100,000, driven by assessor-days, number of sites, and evidence quality. Well-organized evidence directly reduces assessor time and therefore your invoice. Consulting and Advisory Fees Specialist consultants, including Registered Practitioners (RPs) and
After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information
The EU AI Act’s transparency requirements take effect on 2 August 2026, and most of the companies they cover still think the rules are not their problem. Article 50 applies to any business that publishes AI-generated content or runs an AI system that talks to people in the EU. That includes the marketing team generating campaign images and the support team running a chatbot. It also covers the AI agents you’ve wired into customer email. Penalties reach €15 million or 3% of total worldwide annual turnover, whichever is higher, and you don’t need an office in Europe to be in scope. If your content or your chatbot reaches EU users, the obligations reach you. In a nutshell: if you publish AI-generated images or video, deploy chatbots or AI agents that interact with EU users, or publish AI-written text on matters of public interest, then yes, the EU AI Act applies, starting 2 August 2026. A quick word on the “AI Act delay” headlines. The Digital Omnibus package did push the high-risk system deadlines back, in some cases by more than a year, but it did not move the deployer obligations in Article 50. Companies that read those headlines and stood down their AI Act work made an expensive mistake, because the rules most likely to touch an ordinary business are the ones that stayed on the calendar. What Article 50 Actually Requires Article 50 of the AI Act sets out transparency obligations in four situations. In plain English: Tell people when they’re talking to AI. Systems designed to interact directly with people — chatbots, voice assistants, and AI agents — must make clear that the user is dealing with AI, unless that’s already obvious. Mark AI-generated content so machines can detect it. Providers of generative AI systems must mark outputs in a machine-readable format, typically through metadata and watermarking, so the content is detectable as artificially generated. Label deepfakes. Anyone deploying AI to generate or manipulate image, audio, or video content that resembles real people, places, objects, or events, and could falsely appear authentic, must disclose that the content is artificial. Label AI-generated text on matters of public interest. Text published to inform the public must carry a label if AI-generated or manipulated, unless a human reviewed it and a person or organization holds editorial responsibility for it. Article 50 also covers emotion recognition and biometric categorization systems, which carry their own disclosure duties. Far fewer businesses run into those, so this article sticks to the four above. The distinction running through all of this is provider vs deployer. The provider builds or supplies the AI system. The deployer uses it professionally. Most companies reading this are deployers. If You Use AI-Generated Images Realistic AI images sit closer to the deepfake rules than most marketing teams assume. The Act’s definition covers content depicting people, objects, places, and events that could falsely appear authentic to a viewer, which describes a large share of what image generators produce for campaigns, social posts, and landing pages. So what does “clearly and distinguishably labeled” mean? The threshold is best described by its failures: a tiny disclosure hidden in the website footer doesn’t qualify. Neither does a faint label on an image, a label that flashes for an instant in a video, or a disclosure buried in your terms and conditions. The label has to be visible right where someone sees the content, and it has to meet accessibility standards so people with disabilities can perceive it too. The Code of Practice proposes a standardized “AI” visual label, localized per language (“KI” in German, “IA” in French). It also draws a useful line between fully AI-generated content and AI-assisted content, with lighter requirements for the latter. A designer who used AI to extend a background is in a different position from a team publishing a fully synthetic image of a person who doesn’t exist. Important: The deepfake duty doesn’t care about intent. A flattering, harmless AI image of your CEO at an event that never happened is still a deepfake under the Act. Marketing teams generate this kind of content casually. From August, every one of those images needs a label. If You Deploy AI Agents or Chatbots The rule itself is simple: people must know they’re dealing with AI. The provider carries the design obligation, but as the deployer you’re the one putting the system in front of your customers, and you’re the one an EU regulator will contact if your branded assistant pretends to be human. The Act contains an exception for cases where it’s “obvious” the user is talking to AI, judged from the perspective of a reasonably well-informed and observant person. Don’t lean on it. What’s obvious to your product team isn’t obvious to every customer, and the human-sounding voice agents and email-writing AI agents rolling out right now are designed specifically to not feel like software. If an AI agent negotiates a renewal over email or handles a support ticket end to end, disclose it. Pro Tip: Put the Disclosure at the Start of the Interaction Put the disclosure at the start of the interaction, in the interface itself: “You’re chatting with an AI assistant.” A line in your privacy policy doesn’t meet the standard, and a disclosure that appears after the conversation ends is worthless. For voice agents, say it up front in the greeting. What Your AI Vendors Owe You The machine-readable marking obligation in Article 50(2) sits with providers — the companies supplying your generative AI tools. The final Code of Practice expects providers to apply at least two layers of marking where necessary, such as embedded metadata combined with watermarking, and to offer detection mechanisms so deployers, authorities, and researchers can verify whether a piece of content came from AI. One timing caveat: the Digital Omnibus gives generative AI systems already on the market before 2 August 2026 until 2 December 2026 to comply with the marking requirement. Every other Article 50 obligation stays on
The CNIL‘s screening rule sounds simple: hit two of the nine high-risk criteria, and you owe a full Data Protection Impact Assessment (DPIA). The trouble starts when you hit one or none, because the GDPR never says that skipping the DPIA means skipping assessment altogether. Plenty of processing falls outside the CNIL’s screening rules: operations below the two-criteria threshold, activities on the CNIL’s exemption list, processing already covered by an earlier DPIA, and controllers who answer to a different supervisory authority altogether. In every one of those cases, the Article 35 GDPR DPIA obligation may fall away while the risk assessment obligations under Articles 24 and 32 stay exactly where they were. This article maps the scenarios where CNIL criteria don’t apply and what a defensible assessment strategy looks like when they don’t. DPIA vs General Risk Assessment: Core Distinctions Under GDPR These two assessments get conflated constantly, and the mix-up has real consequences. They rest on different legal bases, serve different purposes, and trigger under different conditions. Article 35 GDPR requires a DPIA where processing is “likely to result in a high risk” to people’s rights and freedoms, and it requires the assessment before processing begins. The DPIA looks outward. It evaluates the necessity and proportionality of the processing and the risks it creates for data subjects: discrimination, identity theft, financial loss, reputational damage, loss of control over personal data. The measuring stick throughout is harm to people. Article 32 GDPR requires controllers and processors to put in place technical and organizational measures (TOMs) appropriate to the risk of the processing. You can’t know what’s appropriate without assessing that risk first, so Article 32 carries an implicit risk assessment duty for every processing operation you run, high risk or not. Its focus is security: the confidentiality, integrity, availability, and resilience of the systems handling personal data. Article 24 completes the picture by making the controller responsible for implementing measures proportionate to risk and able to demonstrate compliance. That’s the accountability principle at work. So risk assessment is universal, and the DPIA is the escalated version you reserve for processing that crosses the high-risk line. The real question is which assessment to run and how deep to go. You don’t need a six-figure budget to be GDPR compliant. You need a clear plan and someone to do the work. Affordable GDPR Compliance Services Book a Free GDPR Consultation The CNIL Criteria: A Quick Recap The Article 35(3) Baseline and the 9 Criteria Article 35(3) names three situations where a DPIA is always mandatory: systematic and extensive automated evaluation of individuals, including profiling, with legal or similarly significant effects; large-scale processing of special categories of data (Article 9) or criminal conviction data (Article 10); and large-scale systematic monitoring of a publicly accessible area. Beyond those, the WP29 guidelines on DPIAs (WP248 rev.01), endorsed by the European Data Protection Board (EDPB), list nine criteria that indicate likely high-risk processing: evaluation or scoring, including profiling; automated decision-making with legal or similarly significant effect; systematic monitoring; sensitive data or data of a highly personal nature; processing on a large scale; matching or combining datasets; data concerning vulnerable data subjects (employees, patients, children); innovative use or application of new technological or organizational solutions; and processing that prevents data subjects from exercising a right or using a service or contract. The “Two Criteria” Threshold Rule The CNIL’s position is that processing meeting at least two of the nine criteria requires a DPIA as a general rule. WP248 leaves room on both sides of that line: a controller can conclude that processing meeting two criteria still isn’t high risk, and in some cases a single criterion is enough to trigger the obligation. Either way, the reasoning has to be documented. Where there’s genuine doubt, the CNIL’s advice is simple: do the DPIA. CNIL’s List of Processing Operations Requiring a DPIA The CNIL also maintains a mandatory list under Article 35(4), adopted through Deliberation No. 2018-327 of October 11, 2018. It names 14 types of processing that require a DPIA outright, including systematic employee monitoring, whistleblowing schemes, profiling that can exclude people from a contract, and large-scale processing of health data. If your processing appears on this list, you can skip the criteria math because the DPIA is mandatory regardless. Insider Note: The CNIL’s sectoral “referentials” do more work than most DPOs realize. If your processing fully complies with an applicable referential, the CNIL accepts the position that residual risk isn’t high, which takes Article 36 prior consultation off the table. Checking for a referential before scoping a DPIA can remove the most painful step of the entire process. When CNIL Criteria Don’t Apply: Key Scenarios Processing Falling Below the Two-Criteria Threshold Most B2B processing lives here. A standard CRM, a newsletter list, routine supplier management: these might touch one criterion (large scale, perhaps) without hitting a second. No DPIA is required, but the screening itself is a compliance artifact. Record which criteria you tested, what you concluded, and why. If the CNIL inspects, the absence of a DPIA is defensible only when the screening decision is on paper. Operations on CNIL’s Exemption List Article 35(5) lets supervisory authorities publish “whitelists” of processing that doesn’t require a DPIA. The CNIL adopted one in 2019 after an EDPB opinion, covering categories such as routine HR management in organizations with fewer than 250 employees (without profiling, biometrics, or sensitive data), badge-based physical access control without biometrics, and time management systems that don’t process biometric data. France is one of only a few member states with a formal whitelist, which matters for cross-border groups: the same HR system can be exempt in France and assessable case by case in Luxembourg. Processing Authorized by Specific Legal Provisions Article 35(10) carves out processing based on a legal obligation or public interest task under Article 6(1)(c) or (e), where the legal basis regulates the specific operation and a general impact assessment was already carried out when that law was adopted. It’s a narrow