Home / All Articles
All Articles
Compliance software collects the evidence. A consultant builds the system that evidence is meant to prove. That’s the real difference in the ISO 27001 consultant vs software decision, and most teams only figure it out after they’ve bought one and realized they still need the other. Below, we compare what each route covers, where it breaks down, and what it costs you in time, money, and your team’s hours. Short version: software on its own works for a small group of companies. For most SaaS and tech scale-ups trying to get an enterprise deal over the line, consultant-led implementation on a compliance platform is the faster and safer path to a certificate. Quick Answer: Consultant, Software, or Both? Software-only works if you already have an in-house security lead who’s taken a company through ISO/IEC 27001 before and has the time to own the project. Consultant-only still makes sense if you run mostly on-premise or legacy systems that platforms barely integrate with. For everyone else, which means most cloud-native companies under a few hundred people, a hybrid works best: a platform to handle evidence and monitoring, and a consultant to build the management system and stand behind it in front of an auditor. Here’s why. What an ISO 27001 Consultant Handles ISO/IEC 27001:2022 is a management system standard. Clauses 4 to 10 cover how you run information security, and Annex A lists 93 controls you pick from based on risk. Almost none of it is box-ticking. Most of it comes down to judgment calls about your business, and that’s what you’re paying a consultant for. Scoping, Gap Analysis and Risk Assessment Scope is the first decision you make, and the most expensive one to get wrong. Go too wide and you’ll spend months on controls for systems no customer asks about. Go too narrow and the certificate won’t get through the procurement review it was supposed to pass. A consultant scopes around the deals you’re trying to close, runs a gap analysis, and builds a risk assessment based on your real assets and threats. That’s the document auditors dig into hardest. ISMS Documentation and Policy Writing The standard asks for a specific set of documents: the ISMS scope, information security policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, and evidence of competence, monitoring, internal audit, and management review. A consultant writes these around how your company works day to day, instead of how a template imagines it works. Auditors check whether you follow your own procedures, so a mismatch shows up fast. Internal Audit and Certification Audit Support You need an internal audit before certification, and Clause 9.2 says the auditor has to be objective and impartial. In a small company, the people who built the ISMS can’t credibly audit it, so most teams outsource it through ISO 27001 internal audit services. A good consultant also gets your team ready for the Stage 1 and Stage 2 audits, joins the conversations that matter, and handles corrective actions if the auditor raises nonconformities. What ISO 27001 Compliance Software Handles Compliance automation platforms, often called GRC platforms, have changed how cloud-native companies get certified. They’re very good at the repetitive, evidence-heavy side of the work. Automated Evidence Collection and Continuous Control Monitoring The platform plugs into your cloud provider, identity provider, code repos, HR system, and device management tools, then pulls evidence on its own. It’ll flag an unencrypted storage bucket, an ex-employee who still has access, or a laptop without disk encryption. For technical controls, that saves weeks of screenshots and spreadsheet tracking. Policy Templates and Annex A Control Mapping Most platforms come with a policy library and map each control to the ISO 27001 clauses and Annex A. You get a starting point and a clear view of which controls have evidence and which don’t. Auditor Access and Ongoing Compliance Tracking Auditors can log in and review evidence themselves, which cuts down fieldwork. After you’re certified, dashboards show when controls slip between surveillance audits, so you aren’t rebuilding evidence from scratch every year. Where Each Approach Falls Short Neither route covers everything by itself. The good news is that the ways each one fails are predictable, so you can plan around them. Limits of Compliance Automation Platforms A platform can tell you a control is failing. It can’t decide your scope, run your risk assessment, write a policy that matches your operations, convince your CTO to change the offboarding process, or explain to an auditor why you excluded a control from your Statement of Applicability. Templates can also make you feel further along than you are. A dashboard at 90% can hide an ISMS that won’t survive Stage 1, because the missing 10% is the management system itself. Insider Note: The Stage 1 problem we see most on software-only projects is a risk assessment copied straight from the platform’s default risk library. The risks are generic, the scores are almost identical, and nothing ties back to the company’s own assets. Auditors notice within minutes, and it weakens the Statement of Applicability that’s built on it. The other problem is ownership. Software assumes someone inside the company will drive the project. At most startups that’s a CTO or ops lead who already has a full-time job, and the subscription renews whether the work gets done or not. Limits of a Consultant-Only Approach A consultant working without automation spends billable days on things a platform does for free, like chasing screenshots, updating evidence trackers, and collecting the same proof again before every surveillance audit. You pay more and wait longer. You also end up with a program that’s only accurate on the day it’s handed over. Once the engagement ends, the evidence goes stale and year-two surveillance turns into a scramble. ISO 27001 Consultant vs Software: Side-by-Side Comparison Factor Consultant only Software only Hybrid (consultant + platform) Time to audit readiness 3 to 6+ months Highly variable; depends on internal expertise As little as 6 weeks for well-scoped
Uzbekistan regulates artificial intelligence through two documents. The first is Law ZRU-1115, signed on 21 January 2026. It amends existing legislation to define AI, stops anyone from basing decisions about people’s rights on AI output alone, and fines companies that process personal data unlawfully with AI. The second is the set of Ethical Rules approved by Order No. 3787, in force since 17 June 2026, which spell out what developers, implementers, and users actually have to do. Uzbekistan hasn’t passed a standalone AI act, and its rules don’t sort systems into risk tiers or require conformity assessments. The framework is short and blunt, and it’s already enforceable. Below we walk through what each document requires, who it applies to, how it stacks up against the EU AI Act, and what a company using AI in Uzbekistan should do next. Uzbekistan AI Regulation at a Glance (TL;DR) Instrument Date What it does Who it binds Law ZRU-1115 Signed 21 January 2026 Defines AI in law, sets general rules for AI-built information resources and systems, bans legally significant decisions based only on AI, adds fines for unlawful AI processing of personal data State bodies, organizations, website owners, anyone processing personal data with AI Order No. 3787 (Ethical Rules) Registered 14 March 2026, in force 17 June 2026 Sets eight mandatory ethical principles and lists rights and obligations for developers, implementers, and users Individuals and companies developing, implementing, or using AI in Uzbekistan Law No. 1125 (Personal Data amendments) Adopted 26 March 2026 Limits data localization to biometric, genetic, and local telecom user data, and allows cross-border transfers under conditions Personal data operators, including AI providers AI Strategy until 2030 (RP-358) 14 October 2024 Sets national targets for AI adoption, infrastructure, and skills Government bodies What Is Law ZRU-1115? The law’s official title is a mouthful: “On making additions and changes to certain legislative acts of the Republic of Uzbekistan in connection with the regulation of relations arising from the use of artificial intelligence.” Put simply, it’s an amending law. Instead of creating a new AI code, it writes AI into laws that were already on the books. When It Was Signed and When It Took Effect The Legislative Chamber of the Oliy Majlis adopted the bill on 12 August 2025, and the Senate approved it on 1 November 2025. President Shavkat Mirziyoyev signed it on 21 January 2026. You can read the official text in Lex.uz, Uzbekistan’s national legislation database. The law set out the principles and the penalties. The day-to-day detail arrived later with the Ethical Rules, which came into force on 17 June 2026. For compliance planning, treat mid-June 2026 as the point when the whole framework started applying. Why Uzbekistan Amended Existing Laws Instead of Passing a Standalone AI Act Uzbekistan wants more AI, not less. Its national strategy sets numeric targets for adoption, investment, and local computing capacity, and a heavy EU-style act would have worked against them. So lawmakers kept it light. They defined AI, drew two hard lines (human control over decisions that affect people’s rights, and protection of personal data), and left the Ministry of Digital Technologies to fill in the rest through secondary rules. Businesses get less legal certainty, and the government gets to move faster. Which Laws ZRU-1115 Changes For businesses, two amendments matter most. The Law “On Informatization” (ZRU-560-II, 2003) now contains a legal definition of AI, a new article on using AI in information resources and systems, duties for website owners, and updated powers for the ministry in charge. The Code on Administrative Liability now includes an offense for processing and spreading personal data unlawfully using AI. The Legal Definition of Artificial Intelligence in Uzbekistan Under the amended Law “On Informatization,” AI is a set of technological solutions that imitate human cognitive functions, including learning on their own and solving problems, and that produce results on specific tasks comparable to what a person could do. That’s deliberately broad. It covers generative AI, machine learning classifiers, recommendation engines, and most agentic systems. The Ethical Rules add a narrower term, the AI system: software built on AI that can find, collect, store, analyze, process, evaluate, and use data, and make decisions on its own based on that data. If your product makes a decision from data, or shapes one, assume it counts. Key Rules Introduced by Law ZRU-1115 General Principles for Using AI in Information Systems and Resources The new article in the Law “On Informatization” starts from harm. Information resources created with AI, and information systems running on AI, must not harm people’s life, health, freedom, honor, or dignity, or violate their other inalienable rights. The standard is short and open-ended. It gives regulators something to enforce against without saying in advance what counts as harm. Principle-based rules like this deserve to be taken seriously precisely because the edges are undefined. Human Oversight: No Decisions on Rights and Freedoms Based Solely on AI Most coverage leads with this provision, and it’s easy to see why. When someone makes a legally significant decision that affects human rights and freedoms, they can’t rely only on conclusions produced by AI systems or AI-built information resources. AI can feed into the decision, but a person has to make it. That applies to loan denials, benefit eligibility, hiring rejections, licensing outcomes, and disciplinary action. In each case, someone needs to look at the AI output and own the final call. Insider Note: In AI governance engagements, teams rarely struggle to show that a review step exists. What they struggle to show is that the reviewer could disagree, and sometimes did. If a human clicks “approve” on every AI recommendation and nobody ever records an override, auditors will see automation with a signature on top. Build the override path and log when people use it, starting on day one. Powers of the Authorized State Body (Ministry of Digital Technologies) ZRU-1115 makes the Ministry of Digital Technologies the authorized state body for AI. Among its new jobs, it’s
You can get a SaaS company ready for a SOC 2 audit in six weeks, but you’ll feel every one of them. Most published timelines say three to six months. For a company with no project owner, no identity provider, and nothing written down, that’s about right. A cloud-native startup that already has the basics in place and can protect some time is a different story, and it can fit the work into six hard weeks. This plan walks through that route one week at a time. Each week has an owner, an hour estimate, and a clear test for when it’s finished. The free Google Sheet version turns the plan into a tracker you can hand out to owners and update in your weekly standup. Before you start, know what you’re signing up for. At the end of week 6 you’ll be audit-ready, which isn’t the same as holding a Type II report. Nobody can get you a Type II in six weeks. This is also the do-it-yourself route, and it takes a lot of hours. We’ll show you where those hours go and what the faster option looks like. Is Six Weeks Realistic for Your Company? Six weeks works when most of the plumbing already exists and your job is to formalize it, fill the gaps, and prove it all works. It falls apart when you’re building the foundations and documenting them at the same time. Go through this table honestly before you promise a customer a date. Six weeks is realistic if… Plan for 10 to 16 weeks if… Your product runs on a major cloud provider You host on-premise or across several data centers You already use an identity provider with SSO Every tool has its own login and password You have fewer than about 50 employees You have multiple offices, subsidiaries, or products in scope One named person owns the project with 10 to 15 hours a week Compliance is “everyone’s job,” so in practice nobody owns it An engineer can give you 15 to 20 hours in weeks 3 and 4 Engineering is fully committed to a launch You only need the Security criteria You need Availability, Confidentiality, or Privacy on day one Landing mostly in the right-hand column doesn’t mean you should throw the plan out. Give each week two weeks instead of one and follow the same order. What “SOC 2 Ready” Means at the End of Week 6 SOC 2 doesn’t give you a certificate. An independent CPA firm examines your controls against the AICPA Trust Services Criteria and writes a report, and which of the two report types you go for decides what you can show a buyer after week 6. A Type I report checks whether your controls are designed properly on a single date. Once you’re ready, a Type I audit can start almost right away. A Type II report checks whether those controls kept working over an observation period of at least three months, and usually six to twelve. Most enterprise procurement teams want Type II in the end. Being “ready” at the end of this plan means your in-scope controls are in place, you can pull evidence for any of them on request, and your auditor is booked. From there you either start a Type I audit or open your Type II observation window. Plenty of buyers will sign with a Type I report plus a letter from your auditor saying the Type II period is underway. Important: The Type II clock doesn’t start until your controls are running. If readiness slips by a week, your Type II report slips by a week too. Founders who tell a prospect “we’ll have SOC 2 in Q3” often forget this and end up renegotiating the deal. Before Week 1: Four Decisions to Make First Settle these before the clock starts. If you change any of them halfway through, you’ll redo work. Scope. Decide which systems, teams, and data the report covers. For most SaaS companies that’s the production environment, the code repository, the identity provider, customer data stores, and any support tools that touch customer data. Corporate systems that never see customer data can usually stay out. Trust Services Criteria. Security (also called the Common Criteria) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Report type. Pick Type I if a deal is blocked right now and the buyer will accept it. If there’s no deadline, go straight to Type II. You’ll need it eventually, and skipping Type I saves you an audit fee. Owner and tooling. Name one person who’s accountable for the plan, and decide where your controls and evidence will live. The tooling choice gets its own section below. Pro Tip: Adding Criteria Only add optional criteria when a customer contract or security questionnaire asks for them. Each one brings more controls to set up and more evidence to collect, and you can widen the scope in next year’s audit. Spreadsheet or Compliance Software: Choosing Your Tracking Tool Every SOC 2 program needs a system of record, meaning one place where each control, its owner, its status, and its evidence live. You can run it yourself in a spreadsheet or a GRC platform, or have a consultant implement it for you. The right choice depends mostly on which report you’re after and how much of your team’s time you can spare. A spreadsheet is free and familiar. It also makes you understand your own environment before you automate any of it. For a Type I, or for a small team with a tight scope, a well-built spreadsheet can take you all the way to the audit. Axipro’s free GRC workbook for SOC 2 and ISO 27001 covers all 33 SOC 2 Common Criteria plus the optional criteria, with evidence, risk, policy, and gap trackers built in. It has no macros and opens straight in Google Sheets or Excel. A GRC platform connects to your cloud, identity provider, code repository, and HR system.
Most SaaS companies that want someone to handle SOC 2 or ISO 27001 for them end up with the same four names on the shortlist: Axipro, Cognisys, Eden Data, and Workstreet. Their published timelines to audit readiness run from under six weeks to twelve months, and pricing differs by a factor of three or more. When an enterprise deal is waiting on a report, that spread can decide whether the deal closes this quarter or next. We should say upfront that we’re Axipro, so we have a horse in this race. We built this comparison from feedback from our clients, each firm’s public website, partner directory listings, and marketplace pages. We also wrote it to be useful even if you hire someone else, and we say so where a competitor is the better fit. There’s one more piece of context. Since the Delve allegations broke in March 2026, buyers have treated the phrase “fast compliance” with suspicion, and they’re right to. So this article answers two questions: who gets you audit-ready fastest, and how you can tell real speed from a rubber stamp. Quick Verdict: Which Compliance Partner Fits Which Company Axipro is our pick for most companies, and the rest of this article shows the reasoning. It gets you audit-ready in under six weeks for a fixed published fee that’s typically about half of competitors’. You also get guaranteed certification on the Achievement Plan, top-tier status with Drata plus a Vanta partnership, and regional frameworks the other three don’t list. Cognisys is the second strongest choice for UK companies that are committed to Vanta and want penetration testing from the same in-house team. Eden Data suits US companies that want a US-based, ex-Big 4 team on a monthly subscription and can live with a longer runway. Axipro vs Cognisys vs Eden Data vs Workstreet at a Glance (Comparison Table) Axipro Cognisys Eden Data Workstreet Base Entities in Bahrain, UK, and US; team distributed across three continents Leeds and London, UK Austin, Texas San Francisco, California GRC platforms Drata (Elite Partner), Vanta, and 10+ others Vanta-centered Drata, Vanta, and others Vanta-centered Published readiness timeline Under 6 weeks 4 to 6 weeks on its DTA program, with prerequisites 3 to 12 months No standing figure published Pricing model Fixed fee per framework, published Quote on request Subscription from $5,000 per month Custom quote Certification guarantee Yes, on the Achievement Plan None published that we found None published that we found None published that we found Penetration testing Yes, with a CREST Pathway+ registered partner In-house Add-on Yes Standout frameworks SOC 2, ISO 27001, NCA ECC, SAMA CSF, ISO 42001, EU AI Act Cyber Essentials Plus, NIS2, DORA HITRUST, FedRAMP, CMMC FedRAMP, CMMC, NIST 800-53 Best for Speed and budget, any region UK companies on Vanta US buyers who want a subscription US startups on Vanta What a Compliance Readiness Partner Does That Your GRC Platform Doesn’t A GRC platform such as Drata or Vanta connects to your cloud, identity, and HR systems and collects evidence automatically. It’ll tell you that 14 laptops lack disk encryption. It won’t encrypt them or write the policy that requires it. It also won’t decide whether the contractor laptops are in scope, or sit in the auditor walkthrough and explain your change management process. That’s the work a readiness partner sells. The partner scopes the audit, writes policies that match how the company really operates, puts the missing controls in place, runs the risk assessment and internal audit, and manages the auditor until the report lands. Companies that buy a platform and skip the partner usually find this out around month three. By then the dashboard is stuck at 60 percent and the engineer who owns it has stopped answering compliance tickets. Platform, Readiness Partner, Auditor: Who Owns Which Part of the Audit Three parties are involved, and each has its own job. The platform collects and monitors evidence. The readiness partner builds the program and gets you to the point where an audit will succeed. The auditor is an independent CPA firm for SOC 2, or an accredited certification body for ISO 27001, and only the auditor forms the opinion. The AICPA’s SOC 2 guidance treats that independence as the whole point of the attestation. The Delve story shows what happens when those jobs collapse into one. In March 2026, an anonymous group of former customers accused the compliance startup of generating fabricated evidence and pre-written auditor conclusions, then routing clients to audit firms that signed whatever arrived. Their analysis of leaked files found that 493 of 494 SOC 2 reports shared near-identical text, down to the same grammatical error. Delve has denied the claims and says independent auditors issue all final opinions. We covered the details in our piece on what the Delve compliance leak means for SOC 2 certification. It wasn’t the first time, either. In 2024 the SEC shut down audit firm BF Borgers for fabricating audit documentation behind more than 1,500 filings, in what its enforcement director called a “sham audit mill.” That was a financial audit and Delve’s were security audits, but the failure was the same: someone signed a report with no work behind it. Important: None of the four firms in this comparison has been implicated in any of this. All four are human-led readiness firms that hand the final opinion to independent auditors. We bring up the scandals because they changed what buyers should ask, and we don’t mean it as a dig at competitors. How We Compared the Four Partners We scored each firm on eight criteria that a founder or CTO would care about with a deal on the line. Every data point comes from material the firms publish themselves. Where a firm publishes nothing, we say so and don’t guess. Time to Audit-Ready Audit-ready means an auditor could start fieldwork tomorrow and you’d pass. Your policies are approved, your controls are running, evidence is flowing, and the risk assessment and internal audit are
Hardly any startup starts a compliance program because it wants one. It usually starts the week an enterprise buyer sends over a 200-question security questionnaire, the deal stalls, and it turns out nobody on a team of 20 engineers knows what a Statement of Applicability is. Managed cybersecurity compliance means handing that problem to an outside team. They scope the framework, put the controls in place, write the policies, run the GRC platform, and deal with the auditor until you have a report or certificate in hand. Below: what a managed service should include, how it’s different from buying software or hiring an MSSP, what it costs, how long it takes, and how to tell a good provider from a bad one. What Is Managed Cybersecurity Compliance? Managed cybersecurity compliance is an outsourced service in which a provider designs, implements, and maintains your compliance program against one or more frameworks, such as SOC 2, ISO 27001, HIPAA, or GDPR. You stay accountable for your own security, but the provider does the work that gets you audit-ready and keeps you there. You’ll also see it sold as Compliance as a Service. Managed Compliance vs. Compliance Automation Software Alone A GRC platform automates evidence collection and monitors your cloud accounts, identity provider, and devices for control failures. It doesn’t decide your audit scope, write a risk assessment that reflects your business, fix the failing controls, or answer the auditor’s follow-up questions. Somebody still has to own all of that, and in most startups it lands on the CTO by default. With a managed service, it lands on the provider. Managed Compliance vs. Managed Security Services (MSSP) An MSSP runs security operations: monitoring, detection, incident response, often through a Security Operations Center. A managed compliance provider runs the governance side: controls, policies, evidence, audits. There’s overlap, since every framework asks for monitoring and incident response. But an MSSP contract won’t get you a SOC 2 report, and a compliance engagement won’t watch your logs at 3 a.m. unless the scope says so. Where a vCISO or CISO-as-a-Service Fits In A virtual CISO is part-time security leadership. They set direction, make the risk calls, and take the awkward calls with a customer’s security team. Many managed services add a vCISO after certification, because somebody has to chair management reviews and sign off on risk treatment once the project team has gone. If a provider’s offer ends the day the certificate arrives, ask who plays that role in year two. GRC platform alone MSSP Managed compliance Primary output Dashboards and automated evidence Threat monitoring and response Audit report or certification Who implements controls Your team Your team (security tooling only) Provider, with your engineers Policies and risk assessment Templates Not included Written for your business Auditor coordination Not included Not included Included Internal time required High Medium Low Why Startups Outsource Cybersecurity Compliance No In-House Security or GRC Headcount Most startups don’t hire a security person until somewhere around 50 to 75 employees, and a GRC specialist comes later than that. Bigger companies have the same problem. The 2025 ISC2 Cybersecurity Workforce Study found that 59% of security teams report critical or significant skills gaps, up from 44% a year earlier, and a third of respondents said their organizations can’t afford to staff security adequately. A Series A company is competing for the same people with a smaller budget. Enterprise Deals Blocked by Security Questionnaires Revenue is the usual trigger. A prospect’s procurement team asks for a SOC 2 Type II report or an ISO 27001 certificate, and the deal sits there until you produce one. Every week you spend working out compliance from scratch is another week the contract stays unsigned. Investor and Due Diligence Expectations Security now comes up in most due diligence processes, especially for companies that hold customer data, health data, or payments. A current report or certificate answers most of those questions in a single document, which a half-finished controls spreadsheet won’t. The Hidden Cost of Engineer-Led, DIY Compliance DIY compliance looks cheap because the cost is buried in engineering time. A senior engineer who spends a quarter configuring a GRC platform and chasing screenshots isn’t shipping product that quarter. The work also tends to stall around 70%. By then the easy integrations are connected, and what’s left is a pile of judgment calls nobody on the team has made before. Insider Note: The controls startups fail most often are rarely technical. They’re process controls that need a paper trail. Think quarterly access reviews that never happened, a former contractor who still has repository access, or vendor reviews that exist only as a sentence in a policy. A platform will flag all of these, but someone still has to go and do them. What a Managed Compliance Service Includes Scope varies a lot between providers, so compare offers line by line. A complete service covers everything below. Framework Scoping and Gap Assessment The provider confirms which framework you need, what is in scope (products, environments, teams, locations), and where you stand against the requirements today. Most of the savings in a compliance project come from good scoping. A narrow scope you can defend to an auditor means fewer controls to run and a smaller audit fee. Risk Assessment and Risk Treatment Both SOC 2 and ISO 27001 require a documented risk assessment. The provider runs it with your leadership, writes down the risks that matter to your business, and agrees a treatment plan with you. For ISO 27001 this feeds the Statement of Applicability, which is the first document an auditor reads. Policy and Procedure Development Expect a set of 15 to 25 policies covering access control, change management, incident response, vendor management, business continuity, and acceptable use. What matters is whether the policies describe what your company really does. Auditors check practice against policy, so a template promising weekly vulnerability scans you don’t run will turn into a finding. Compliance Platform Setup and Control Implementation The provider
ISO published ISO 9001:2026 on September 16, 2026, and the 2015 edition is now formally withdrawn. If you hold a certificate, the good news is that the structure and the process approach are the same, and the list of new requirements is short. Top management now has to promote a quality culture and ethical behavior. Risks and opportunities get handled separately, change management carries more weight, and the 2024 climate change amendment sits inside the core text. That’s most of it. Below, we go through each change clause by clause, cover what stayed where it was, set out the transition timeline, and list the work a certified company has to do before the deadline. Key Takeaways ISO 9001:2026 is the sixth edition of the standard and replaces ISO 9001:2015. Most of the new text is guidance, and only a small part of it adds requirements. The changes that carry audit weight are in Clause 5.1 (quality culture and ethical behavior), Clause 6.1 (risks and opportunities addressed separately), and Clause 6.3 (planning of changes). ISO 9001:2015 certificates stay valid during the transition period, which is expected to run for three years, until around September 2029. Your certification body confirms the exact date. Certification bodies need their own accreditation to the new edition before they can issue 2026 certificates, so nobody has to panic this quarter. A healthy 2015 system needs a gap analysis, some document updates, and better leadership evidence. You won’t have to rebuild it. ISO 9001:2026 Is Now Published: Where the Revision Stands On September 16, 2026, ISO announced the publication of ISO 9001:2026. ISO describes the edition as a set of targeted updates that make the standard clearer and easier to use, built on the framework more than one million organizations already work with. The official ISO 9001:2026 standard page is live. ISO’s page for ISO 9001:2015 now marks that edition as withdrawn and tells certified organizations to speak to their certification body about transition arrangements. It took longer to get here than planned. ISO’s quality committee first voted to leave the 2015 edition alone, then changed its mind in August 2023 after wider consultation. The Draft International Standard followed in August 2025, the final draft went to ballot in spring 2026, and publication hit the September target. Two companion documents came out earlier in the year. ISO 9000:2026, the fundamentals and vocabulary standard, was published in May 2026, and ISO 19011:2026, the auditing guideline, was updated around the same time. If your internal audit procedure cites either one by year, add it to the update list. Why ISO 9001:2015 Was Revised Eleven years is a long time for a management standard. Since 2015, supply chains have become more fragile, remote, and hybrid work has changed how processes run, and customers ask harder questions about ethics and data integrity than they used to. ISO reviews its standards on a regular cycle, and in 2023 the consensus was that a revision would be worth the effort. According to ISO/TC 176/SC 2, the subcommittee responsible for ISO 9001, 81 experts from 46 countries and liaison bodies took part. The result is still conservative, and that was a choice. A standard with a million-plus users can’t afford a rewrite every decade, so the committee went for clarification. ISO 9001:2026 vs ISO 9001:2015: Summary of Changes Area ISO 9001:2015 ISO 9001:2026 Structure Annex SL high-level structure, Clauses 4 to 10 Same clause layout, updated to the latest Harmonized Structure Clause 3, terms Points entirely to ISO 9000 Includes a limited set of core terms; ISO 9000:2026 remains the normative reference Climate change Added by Amendment 1 in 2024 Built into Clauses 4.1 and 4.2 Leadership (5.1) Commitment to the QMS and customer focus Adds promotion of quality culture and ethical behavior Risks and opportunities (6.1) Addressed together Addressed separately, with distinct actions for each Planning of changes (6.3) Brief requirement Reinforced to protect intended results Annex A Short clarification of structure and terms Expanded guidance on the intent of requirements, informative only Annex B Listed other ISO/TC 176 standards Removed; references moved to Annex A and the committee website Key Changes in ISO 9001:2026, Clause by Clause Clause 3: Core Terms Now Sit Inside the Standard The 2015 edition sent readers to ISO 9000 for every definition. The 2026 edition brings a limited number of core management system terms into Clause 3 itself, and ISO 9000:2026 remains the normative reference for the full vocabulary. There’s nothing to set up here. Just check that your quality manual and procedures don’t cite definitions by their old source or year. Clause 4: The Climate Change Amendment Is Now Core Text In February 2024, ISO amended every major management system standard. Organizations had to determine whether climate change is a relevant issue (4.1) and whether interested parties have related requirements (4.2). That amendment took effect immediately, with no transition period, and ISO 9001:2026 folds the same text into the body of the standard. If you handled the amendment properly in 2024, you have nothing new to do. If you wrote “not applicable” on a sticky note, go back to it, because auditors will now read this as a standing requirement. Not relevant is a perfectly acceptable conclusion for many businesses, as long as there’s a reason written down behind it. Clause 5.1: Quality Culture and Ethical Behavior Become Leadership Duties This is the change everyone is talking about, and it’s the hardest one to evidence. Top management now has to show leadership by promoting a quality culture and ethical behavior. The same themes turn up in the requirements for awareness (7.3) and the environment for the operation of processes (7.1.4). You don’t need a culture program for this, and you don’t strictly need a new code of conduct, although one helps. What the auditor wants is for top management to show what they do day to day. Management review minutes where quality problems get discussed without blame are good evidence. So is a working route
An AI agent reads a customer record, decides a refund is warranted, and calls the payments API. The trail it leaves looks nothing like a human doing the same job. The log says a user logged in, a service account made three API calls, and the transaction cleared. It doesn’t say why the agent decided on a refund, what it read first, which model version did the reasoning, or who gave the agent permission to act in the first place. That missing “why” is the whole audit problem. This article covers what ISO/IEC 42001:2023 and the SOC 2 Trust Services Criteria expect from AI agent audit logs, where the two overlap, the fields a log needs to satisfy both, how long to keep records, what you shouldn’t record, and how to package it all for an auditor. It’s written for the CTO, platform lead, or founder who owns compliance for a product that now ships with autonomous agents and needs a certification and a Type II report without running two separate logging programs. The Compliance Gap: Traditional Application Logs vs. AI Agent Audit Logs Why Standard Logs Fall Short for Autonomous Agents Application logs were built for deterministic software. Same input, same state, same output, so recording the input, the state change, and the result is enough to reconstruct what happened. A SOC 2 auditor sampling access logs can trace a database write back to a login, a role, and a change ticket without much effort. Agents break that chain in a few places. They usually run under a shared service account or a borrowed OAuth token, so the log pins the action to a machine identity with no link to the human who set the task. The action itself was picked at runtime by a model rather than fixed in code, so there’s no source line to point at. The same prompt can produce a different tool call tomorrow, so a single sampled log entry proves almost nothing about how the system behaves in general. The Shift from Deterministic State Logging to Intent and Reasoning Capture Traditional logs answer “what changed.” Agent audit logs also have to answer “what was the agent trying to do, what did it consider, and what held it back.” That means capturing the task as delegated, the context the model was handed, the reasoning or planning steps it produced, the tools it picked and the arguments it passed, and every point where a guardrail stepped in. The unit of audit moves from the event to the decision, and each decision needs enough surrounding context that a reviewer can judge whether it was reasonable. Unique Audit Challenges of Non-Deterministic AI Behavior Non-determinism is the part auditors struggle with most. In a normal control test, the auditor re-performs the control and expects the same result. Re-run the same input through an agent and you may get a different path. The practical answer is to stop trying to prove that any single output was correct and instead prove that every output was recorded, attributed, bounded by policy, and reviewable. Logs show that the management system works. They don’t show the model is infallible, and nobody expects them to. ISO 42001 accepts this framing outright. SOC 2 auditors are still catching up, and you’ll spend some time educating them. Insider Note: Auditors don’t expect you to explain the model’s weights. They expect you to show that when the agent did something unexpected, you could find it, see what it read, see what it did, and see who was accountable. Frame every logging decision around that reconstruction test. What ISO 42001 Requires for AI Agent Audit Logs ISO/IEC 42001:2023 is the certifiable standard for an AI Management System (AIMS). It follows the same Plan-Do-Check-Act structure as ISO 27001 and comes with 38 Annex A controls. The phrase “audit log” barely appears in it, but logging obligations run through the main clauses and at least three Annex A areas. Our ISO 42001 certification services map these to your existing controls where possible. Clause 8: Operational Logging and Documentation Requirements Clause 8 asks you to plan, run, and control the processes needed to meet your AI requirements, and to keep documented information showing those processes ran as planned. For an agent in production, the process is the runtime behavior, so documented evidence means logs of the agent operating, not a procedure document on its own. Clause 8.4 adds an AI system impact assessment whose results you have to retain. When an agent’s scope or toolset changes, the record of that change and the updated assessment are both Clause 8 evidence. Clause 9: Performance Evaluation and Evidence of Monitoring Clause 9.1 asks you to decide what to monitor and measure, how, and when, and to keep evidence of the results. An auditor will want the monitoring you defined for each agent (error rates, guardrail block rates, tool-call anomalies, how often humans override) and the records showing you reviewed it. Clause 9.2 internal audit and 9.3 management review both feed off those records. Without operational logs, there’s nothing to measure, and Clause 9 falls over. Annex A.6: AI System Lifecycle Logging Obligations Annex A.6 is where logging gets explicit. A.6.2.8, AI system recording of event logs, requires you to decide at which phases of the AI system lifecycle event logging is switched on, and the Annex B guidance ties this to traceability and anomaly detection. A.6.2.6, AI system operation and monitoring, requires ongoing monitoring in operation, including AI-specific threats like data poisoning and model theft. Read together, they mean logging can’t start at go-live. Design decisions, validation runs, deployment configs, and production behavior all need a record. Annex A.9: Logging Requirements for AI System Operation Annex A.9 covers responsible use: processes for responsible use (A.9.2), objectives for it (A.9.3), and intended use (A.9.4). The logging consequence is that you need to show the agent stayed inside its intended use. That takes logs of the tasks it was given, the actions it took,
Most people asking this question fall into one of two camps. Either they already hold ISO 27001 and just shipped an AI feature, or they run an AI-native company and an enterprise buyer has asked for “your AI governance certification.” The answer is the same for both camps: ISO 27001 secures your information and ISO 42001 governs your AI. Neither certificate covers the other. If AI is part of what you sell or how you make decisions, you’ll need both. If it’s just a productivity tool humming away in the background, ISO 27001 on its own is still fine. Below: what each standard governs, where they overlap, what your existing ISMS doesn’t say about AI, how to decide, and how to run both as one management system rather than two. The Short Answer: When You Need Both (and When You Don’t) You need both when AI is part of your product or part of a decision that affects people, and a customer, regulator, or board could reasonably ask how you govern it. That covers most SaaS companies with a generative feature, every AI-native vendor, and any firm using AI to screen candidates, score credit, or make health or safety calls. ISO 27001 alone is enough when your AI use is internal and low-stakes. Coding assistants, drafting tools, a chatbot answering FAQs from public docs. Your ISMS already covers the data those tools see, and nobody is asking you for an AI management system. ISO 42001 on its own is a rare choice, and usually a bad one. The standard assumes there’s a working security baseline underneath it. An AI governance certificate sitting on top of an unaudited security program raises more questions than it answers, so ISO 27001 comes first or at the same time. What ISO 27001 Covers vs What ISO 42001 Covers ISO 27001: Information Security Management System (ISMS) ISO/IEC 27001:2022 sets out the requirements for an Information Security Management System. The thing being protected is information. The risk being managed is losing its confidentiality, integrity, or availability. Annex A lists 93 controls across organizational, people, physical, and technological themes, and you explain which ones apply in a Statement of Applicability. The certificate tells customers you protect the data they systematically hand you. ISO 42001: AI Management System (AIMS) ISO/IEC 42001:2023 sets out the requirements for an Artificial Intelligence Management System. It’s the first certifiable standard for how an organization develops, provides, or uses AI. The thing being governed is the AI system across its whole lifecycle, and the risks go well past security: harm to people, bias, opacity, and a lack of human oversight. Annex A lists 38 controls under nine objectives, covering AI policy, impact assessment, lifecycle management, data governance, and third-party relationships. The certificate tells customers you can explain what your AI does, who’s accountable for it, and how you stop it from doing damage. ISO 42001 vs ISO 27001: The Key Differences ISO 27001:2022 ISO 42001:2023 What it governs Information assets and the systems that process them AI systems across their lifecycle, whether built, bought, or used Core risk question Can this data be stolen, altered, or made unavailable? Can this AI system harm people, mislead them, or operate without accountability? Annex A controls 93 security controls in 4 themes 38 AI controls across 9 objectives Key assessment Information security risk assessment AI risk assessment plus AI system impact assessment Typical requester Every enterprise security review AI-focused questionnaires, regulated buyers, boards, EU AI Act mapping Maturity Established since 2005, revised 2022 First edition, December 2023; auditors accredited under ISO/IEC 42006 Scope: Information Assets vs AI Systems ISO 27001 draws its boundary around information and the infrastructure that handles it. ISO 42001 draws its boundary around AI systems and their use cases: a recommendation engine, a customer-facing agent, a hiring model, a third-party LLM embedded in your product. The same company can hold both certificates with different scopes. On a first certification cycle the AI scope is usually the narrower one. Risks Managed: Security Risk vs AI Impact and Ethical Risk An ISMS asks what happens if an attacker gets in. An AIMS also asks what happens when the system works exactly as designed and still produces a biased shortlist, a made-up policy answer, or a decision nobody can explain to the person it affected. Clause 6.1.4 of ISO 42001 requires an AI system impact assessment that looks at consequences for individuals and society. ISO 27001 has nothing like it. Controls: Annex A Security Controls vs Annex A AI Controls Roughly a third of ISO 42001’s Annex A maps onto something in ISO 27001. Supplier controls (A.10), data classification and handling (A.7), and roles and responsibilities (A.3) reuse work you’ve already done. The impact assessment group (A.5), most of the lifecycle group (A.6), and the transparency obligations to interested parties (A.8) have no ISO 27001 equivalent, and that’s where most of the new effort goes. Who Asks for Each Certificate Procurement teams ask for ISO 27001 or SOC 2 by default. ISO 42001 comes up when a buyer’s vendor questionnaire has grown an AI section: does a human review high-stakes outputs, do you track which third-party models touch customer data, have you run an impact assessment? A 42001 certificate answers most of that before the security call even starts. Boards and regulators in the EU and the Gulf are the other main source of demand. Worth Knowing: Both standards use ISO’s Harmonized Structure Both standards use ISO’s Harmonized Structure, so clauses 4 through 10 (context, leadership, planning, support, operation, performance evaluation, improvement) share the same numbering and mostly the same wording. An auditor moving between them sees the same management-system skeleton with a different set of risks and controls hung on it. Where ISO 42001 and ISO 27001 Overlap The Shared Harmonized Structure (Clauses 4 to 10) The management-system machinery carries over almost untouched. Document control, competence records, the internal audit program, management review, corrective action, and the way you plan for risks
The EU buys more from Türkiye than anyone else. According to the European Commission’s trade profile for Türkiye, about 41% of Turkish goods exports went to the EU in 2024, and the share keeps climbing. Nearly every company behind those shipments holds some EU personal data: a buyer’s name in the CRM, a webshop account, a logistics contact, a support ticket. That data puts the exporter inside the GDPR, and a KVKK compliance file won’t answer the questions an EU customer’s procurement team is going to ask. KVKK and GDPR look alike, and the 2024 amendments brought them closer. They’re still two laws with two regulators, two sets of paperwork and very different fine ceilings. This article walks through the eight places where a KVKK-compliant Turkish exporter falls short of GDPR, covers both directions of data flow, and ends with a roadmap that reflects how long this stuff actually takes. Why KVKK Compliance Doesn’t Make a Turkish Exporter GDPR-Ready Law No. 6698 was written to line Türkiye up with the EU’s 1995 Data Protection Directive. It came into force in April 2016, a few weeks before the EU adopted the GDPR. That timing explains most of what follows. KVKK inherited the Directive’s structure and then developed on its own track under the Personal Data Protection Board, while the GDPR added accountability tools, extraterritorial reach and turnover-based fines that the Directive never had. So a Turkish company can be fully KVKK compliant, registered in VERBİS, privacy notices in place, and still have no records of processing, no DPIA method, no EU representative, and no answer for an EU customer asking which Article 46 mechanism covers the data they’re about to send to Istanbul. When GDPR Applies to a Turkish Company Article 3(2) of the GDPR catches companies with no EU establishment in two situations: offering goods or services to people in the EU, and monitoring their behavior. The European Data Protection Board’s guidelines on territorial scope treat euro pricing, shipping to EU addresses, EU-language storefronts and EU-targeted marketing as “offering.” Analytics, retargeting pixels and personalization count as “monitoring.” There’s a third route that’s easy to miss. A Turkish software house or contract manufacturer that processes EU personal data for an EU customer is a processor under Article 28. The customer will want a data processing agreement, security commitments and help meeting its own GDPR obligations, even if the Turkish company never markets to the EU at all. Important: Selling only B2B to EU companies doesn’t get you out of this. Business contacts are data subjects. The names, emails and phone numbers of a German buyer’s purchasing staff are personal data under both laws, and the exporter is the controller of them. KVKK vs GDPR at a Glance Obligation KVKK (Law No. 6698, as amended 2024) GDPR (Regulation (EU) 2016/679) Default legal basis Explicit consent, with listed exceptions including legitimate interest Six equal lawful bases; consent is one of them Registry Mandatory VERBİS registration for most controllers No public registry; internal Article 30 records Impact assessment No statutory DPIA Mandatory DPIA for high-risk processing DPO Not required Required in defined cases (Article 37) Representative abroad Foreign controllers appoint a Türkiye representative Non-EU controllers appoint an EU representative (Article 27) Data portability Not granted Granted (Article 20) Breach notice Board within 72 hours Supervisory authority within 72 hours Transfers Adequacy, Turkish standard contracts, BCRs; 5-business-day filing Adequacy, EU SCCs, BCRs; transfer impact assessment Maximum fine ₺17,092,242 in 2026 €20 million or 4% of global turnover Gap 1: Lawful Bases and Consent KVKK’s Article 5 puts explicit consent at the top and lists everything else as an exception. Turkish privacy notices reflect that, and most of them lean on consent for almost everything. The GDPR treats consent as one option among six, and in practice it’s the weakest one for core business processing. Regulators expect contract performance for order fulfillment, legal obligation for tax records, and legitimate interest for fraud prevention and B2B marketing. Consent also has a cost that exporters don’t always price in. Under Article 7 it has to be as easy to withdraw as it was to give, and once it’s withdrawn the processing has to stop. An exporter that collects EU customer data “with consent” and then keeps invoicing records for ten years has written a contradiction into its own notice. Law No. 7499 closed one part of this gap in 2024. Health and sexual-life data lost their special carve-out and the list of grounds for processing sensitive data got longer, so KVKK Article 6 now tracks GDPR Article 9 fairly closely. An exporter’s KVKK approach to sensitive data can be reused for GDPR with light editing. Cookies are another point of convergence. The Board’s cookie guidance already asks for opt-in consent for anything beyond strictly necessary cookies, a reject button as visible as the accept one, and no pre-ticked boxes. A banner built to that standard will pass with most EU supervisory authorities too. Gap 2: Accountability Documentation KVKK asks controllers to register in VERBİS, the public Data Controllers’ Registry, and to keep a processing inventory behind that registration. The GDPR has no registry. What it has instead is Article 30: an internal record of processing activities that a supervisory authority can demand at any time, covering purposes, data categories, recipients, transfers, retention periods, and security measures. The VERBİS inventory gets you roughly 70% of the way to an Article 30 record. What’s usually missing is the lawful basis for each purpose (VERBİS doesn’t push for it at the same level of detail), the transfer mechanism per recipient, and the Article 28 processor list. The bigger gap is the Data Protection Impact Assessment. KVKK has nothing like it. GDPR Article 35 makes a DPIA mandatory before high-risk processing starts, and an EU customer may ask to see one before signing. Building the method takes a few weeks. Retrofitting DPIAs onto processing that’s already live takes longer, and it tends to turn up things nobody wanted to find. Insider
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