Home / Blog
Axipro Resource Hub
Latest Articles
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
Compliance Hubs
Discover key insights, educational articles, helpful guides and more.
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
Guides and Reports
SOC 2 Hub
All you need to know about SOC 2 compliance
In March 2026, a regional conflict in the Middle East did something that stress tests and tabletop exercises rarely manage to do: it took down cloud infrastructure across multiple availability zones at the same time, in the same region, without warning. AWS data centers in the UAE and Bahrain were impacted. Banking apps went offline. Payments failed. Delivery platforms stopped. And a significant portion of the affected organizations had done everything “right” by conventional standards — multi-AZ deployments, redundancy within the region, documented continuity plans. It wasn’t enough. This article breaks down what happened, what it revealed about how most organizations think about availability, and what a more resilient architecture actually looks like. If your systems run on cloud infrastructure — in any region — this case is worth understanding closely. What Happened: The March 2026 Incident Regional conflict in the Middle East caused physical and infrastructural disruption to AWS facilities across the UAE and Bahrain. Based on publicly reported information, the incident involved power outages affecting data center operations, physical damage to infrastructure facilities, connectivity loss across affected environments, and service degradation spanning multiple availability zones within the same region — simultaneously. That last point is the one that matters most. AWS designs its availability zones to be isolated from one another — separate power, cooling, and networking — so that a failure in one zone doesn’t cascade into another. Under normal failure conditions, that isolation holds. But this wasn’t a normal failure condition. It was a regional-scale disruption. The “rooms” were fine. The “building” was the problem. “Availability zones are designed to handle localized failures, not regional ones. This incident sits firmly in the second category.” The result was that organizations with multi-AZ architectures — which many rightly considered robust — still went down. There was no in-region fallback left to use. Business Impact: What Actually Went Offline The impact was not subtle. Banking platforms experienced downtime that prevented customers from accessing accounts or completing transactions. Payment processors were unable to process transactions. Mobility and delivery platforms halted operations entirely. Customer-facing applications became unavailable across the board. This wasn’t degraded performance or slower load times. It was a full loss of availability for any system that lived entirely within the affected region. The AWS Well-Architected Framework acknowledges that regional failures, while rare, are a defined risk category — and designing for them requires a fundamentally different approach than designing for AZ failures. Organizations with multi-region architectures kept operating. Everything else stopped. That single architectural decision — single-region versus multi-region — was the difference between availability and a complete outage. What Risks Actually Materialised This incident didn’t create new risks. It exposed ones that were already there, quietly embedded in architectural choices and compliance assumptions that had never been stress-tested at this scale. Regional Single Point of Failure The most common pattern among affected organizations: applications, databases, and backups all deployed within a single region. When that region became unavailable, there was no secondary environment to take over. No warm standby, no traffic rerouting, no automated failover. Just downtime. This is the architectural equivalent of backing up your data to a drive sitting next to your laptop. It works until it doesn’t. The Limits of Availability Zone Redundancy Availability zones are a powerful tool — but they’re a tool designed for a specific class of failure, and understanding that class matters. Think of an availability zone as a separate floor in a building. If one floor has a problem, you move to another floor. But if the entire building loses power — or becomes inaccessible — floor redundancy doesn’t help. You needed another building entirely. That’s what a region is. And this incident took down the building. Pro tip: When mapping your architecture against a business continuity plan, explicitly define your regional failure scenario. “What happens if this entire region becomes inaccessible for 24 hours?” is a question that exposes gaps that AZ-level planning will never catch. Infrastructure-Level Disruption Is Not Solvable at the Application Layer Power outages. Connectivity loss. Physical damage. These are not conditions that clever application architecture can work around if your infrastructure is entirely contained within the affected geography. No amount of microservices design, caching strategy, or auto-scaling helps when there’s no power reaching the data center. This is an important framing shift for engineering teams who own availability: some failure modes require infrastructure-layer responses, not code-layer ones. The Compliance Gap: Controls on Paper vs. Controls in Practice Perhaps the most uncomfortable implication of this incident. In many environments — particularly those undergoing ISO/IEC 27001:2022 certification or SOC 2 audits — availability controls are documented but don’t reflect the actual system architecture. Redundancy is listed as a control. It’s just redundancy within a single region, which, as this event demonstrated, is insufficient for regional-scale disruptions. The control passes an audit. It fails a real incident. This is the exact gap that compliance frameworks are designed to close — and that audit processes sometimes fail to catch. Cloud Hosting and SOC 2 Compliance Requirements Choosing AWS or Azure doesn’t hand you a SOC 2 compliance. It hands you a shared responsibility model, which means your provider secures the physical infrastructure and you secure everything running on top of it — including whether your architecture can actually deliver on your availability commitments. Auditors know this distinction well. When they evaluate your Availability criteria, they’re looking at your controls, not your provider’s SOC 2 report. What that means in practice: your recovery objectives need to be real numbers tied to a real architecture, not placeholders in a policy document. Your failover plan needs test records behind it. And your cloud provider should appear in your vendor risk register with an annual review of their own audit reports. A single-region deployment with no tested failover isn’t compliant in any meaningful sense. It’s a documentation exercise waiting to be disproved. The March 2026 incident made this concrete. Organizations that had documented availability controls but confined their entire infrastructure to
The “SSAE 18 vs SOC 2” debate typically surfaces when buyers, vendors, and even internal teams are all talking about the same general assurance problem, but using the wrong labels. A procurement team asks, “Do you have SSAE 18?” A founder says, “We’re going for SSAE 18 certification.” A customer security team asks for an “SSAE 18 SOC 2 report.” Everyone is circling the same planet, but not always landing on the right terminology. SSAE 18 and SOC 2 are not competing things. They are related, but they are not interchangeable. The AICPA defines SOC 2 as an examination and report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. SSAE 18, by contrast, is the attestation standard framework under which these kinds of engagements are performed. That distinction matters because buyers often ask for the wrong artifact. If you answer the wrong question, you can waste months preparing the wrong report. Quick Answer: SSAE 18 Is a Standard; SOC 2 Is a Report The simplest accurate explanation is this: SSAE 18 is the professional attestation standard; SOC 2 is the report deliverable. The standard tells the auditor how to perform the engagement. The report is what your customers actually read. The AICPA states that SSAE No. 18 was issued as part of its attestation clarity project, which clarified and recodified attestation standards. The same organization also explains that SOC reports are part of the AICPA’s broader SOC suite of services used to communicate controls at service organizations. So when someone says, “We need SSAE 18,” what they usually mean is one of two things: either they want a SOC 1 report for financial-reporting-related controls, or they want a SOC 2 report for security and broader system controls. How SSAE 18 Relates to SOC 1, SOC 2, and SOC 3 SOC 1 addresses controls at a service organization that are relevant to a user entity’s internal control over financial reporting. The AICPA positions SOC 1 specifically for management of user entities and their financial statement auditors. SOC 2 addresses controls relevant to the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. It is designed for customers and other specified users who need detailed information about system controls. SOC 3 covers the same trust services subject matter as SOC 2, but in a general-use format with less detail, so it can be freely distributed. (Think of it as the marketing-friendly version.) In plain English: SSAE 18 sits underneath the engagement methodology; SOC 1, SOC 2, and SOC 3 are the reporting formats and scopes that come out of it. What Is SSAE 18? SSAE 18 stands for Statement on Standards for Attestation Engagements No. 18. It is an AICPA-issued attestation standard used in examinations, reviews, and agreed-upon procedures for nonissuers. The AICPA describes SSAEs as applicable to the preparation and issuance of attestation reports for nonissuers, and specifically notes that SSAE No. 18 completed the attestation clarity project through clarification and recodification. Who Issues SSAE 18 and Who Performs the Engagement The AICPA Auditing Standards Board (ASB) issues SSAE standards. The actual engagement, however, is performed by an independent CPA firm or service auditor. That division of labor is important. Your company does not “self-issue” SSAE 18. A CPA firm performs an attestation engagement under that standard and then issues the related report. Insider Tip When a buyer asks whether you are “SSAE 18 certified,” they are using market shorthand, not technical language. The better response is: “We have a SOC 2 Type 2 report issued by an independent CPA firm under the applicable attestation standards.” What SSAE 18 Replaced (SSAE 16 / SAS 70 Context) Historically, the service-organization reporting world moved from SAS 70 to SSAE 16, and then to SSAE 18. The AICPA’s clarity and convergence work eliminated the old SAS 70 framing, established the SOC-branded reports, and recodified the underlying attestation standards into SSAE 18. The standard was introduced in 2016 and implemented in 2017 as part of this evolution. (For international context, SSAE 18’s closest equivalent is ISAE 3402, issued by the International Auditing and Assurance Standards Board.) That is why older buyers may still talk in legacy language. They remember SAS 70. Mid-generation buyers remember SSAE 16. Today’s market usually asks for SOC 1 or SOC 2, but sometimes with yesterday’s vocabulary still attached. Which Engagements Fall Under SSAE 18 Within the SOC context, SSAE 18 governs how the practitioner performs examinations that lead to reports such as SOC 1, SOC 2, and SOC 3. The AICPA’s SOC suite overview frames these offerings as assurance reports used to help assess and address outsourcing risk. What Is a SOC 2 Report? A SOC 2 report is an independent attestation report on controls at a service organization relevant to the Trust Services Criteria. The AICPA defines SOC 2 around the five criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 exists because businesses increasingly outsource critical systems to cloud and SaaS providers, and they want a way to evaluate whether those providers have appropriate controls in place. We’ve written an in-depth guide on what SOC 2 is, which you can read here. What SOC 2 Evaluates (Controls Aligned to Trust Services Criteria) SOC 2 evaluates whether the service organization’s system and controls are suitably designed—and, in a Type 2 engagement, whether they operated effectively over a review period—against the applicable TSC. Security is always part of SOC 2, while Availability, Processing Integrity, Confidentiality, and Privacy are included based on the nature of the service and customer commitments. If you’re unsure which criteria apply to your organization, a gap analysis is a smart first step. SSAE 18 vs SOC 2: Side-by-Side Comparison Category SSAE 18 SOC 2 What it is Attestation standard Report deliverable Issued by AICPA Auditing Standards Board Independent CPA firm (after the engagement) Primary purpose Governs how the engagement is performed Communicates results about controls relevant to TSC Scope Broad attestation framework Security and
Contrary to popular belief, SOC 2 does not mandate a strict list of cryptographic controls. Instead, it evaluates whether an organization has implemented appropriate encryption controls based on risk. That distinction matters: auditors care less about whether you check a specific box and more about whether your encryption strategy effectively protects sensitive data. This guide breaks down how encryption fits into SOC 2 compliance, where auditors look for it, and how to design encryption controls that hold up during a SOC 2 Type I or SOC 2 Type II audit. What “SOC 2 encryption requirements” really means The System and Organization Controls 2 (SOC 2) framework was created by the American Institute of Certified Public Accountants (AICPA) to help service organizations demonstrate that their systems are secure and trustworthy. SOC 2 assessments evaluate controls against the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. The AICPA’s 2017 Trust Services Criteria (updated with revised points of focus in 2022) is the document auditors reference when evaluating your controls. But here’s the key nuance: SOC 2 is a controls report, not a prescriptive encryption standard. Instead of dictating exact technologies, SOC 2 asks auditors to determine whether controls are appropriately designed and operating effectively to meet the Trust Services Criteria. This means encryption is often expected—especially for sensitive or regulated data—but it’s not universally “required” in every scenario. Scenario Encryption expectation Public marketing website TLS likely required Internal operational logs May depend on risk classification Customer database with PII Encryption almost always expected The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t, even if your encryption is technically sound, expect follow-up questions. How auditors evaluate “appropriate” encryption for your risk profile SOC 2 audits are risk-based. Auditors don’t walk in with a checklist of mandatory algorithms. Instead, they assess whether your encryption posture makes sense given the data you handle. They typically ask questions like: What types of data does the system process? How sensitive is that data? What threats could expose it? What encryption controls mitigate those risks? Organizations that process PII, financial records, or proprietary customer data will be expected to demonstrate stronger encryption controls than a company that only handles non-sensitive internal metrics. Evidence often includes encryption policies, architecture diagrams, key management procedures, configuration evidence from cloud services, and monitoring and audit logs. The point isn’t just having encryption—it’s having evidence that encryption is in place and working as described. If you’re working from a SOC 2 compliance checklist, make encryption evidence a line item, not an afterthought. For a SOC 2 Type I, auditors evaluate control design at a single point in time. They’re asking: “Are these controls designed in a way that should work?” For a SOC 2 Type II, auditors test whether encryption controls operated consistently over time, typically across a 6–12 month period. This is where SOC 2 Type II continuous monitoring becomes essential. It’s one thing to set up encryption correctly on a Tuesday—it’s another to prove it was running properly every day for the last nine months. The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t—even if your encryption is technically sound—expect follow-up questions. Criterion Role of encryption Key focus Security (mandatory) Primary TLS for network communication, secrets protection, key management, access control enforcement Confidentiality Primary Protecting sensitive data at rest (e.g., AES-256, TDE) and in transit Privacy Important Encrypting PII, credentials, and identity documents; works alongside retention and data minimization controls Availability Supporting Encrypted backups, secure recovery data Processing Integrity Supporting Tamper protection during data transmission and processing Security is the only mandatory criterion in every SOC 2 audit, but if you’ve included Confidentiality or Privacy in your scope, encryption becomes a central control,not a supporting one. For organizations weighing SOC 2 against other standards, our comparison of ISO 27001 vs SOC 2 can help clarify the differences. Encryption scope: what auditors will examine Auditors evaluate encryption within the boundaries you define. That means scoping decisions matter as much as the technical implementation. A mature SOC 2 environment classifies data into tiers,public, internal, confidential, and regulated,and applies encryption requirements accordingly. Customer data almost always receives the strictest protections, while internal operational metrics may be risk-based. If you haven’t built a formal data classification policy, expect auditors to flag that gap. Data type Encryption expectation Customer database Mandatory encryption Employee HR records Strong encryption Internal monitoring metrics Risk-based Two scoping pitfalls that auditors flag regularly: production data copied into staging or development environments without encryption (if real data is present, it needs production-grade protections), and unclear cloud shared responsibility. Cloud providers operate under shared responsibility models,infrastructure security may be the provider’s job, but data encryption configuration is almost always yours. Organizations using services like AWS KMS, Azure Key Vault, or Google Cloud KMS must demonstrate what the provider manages, what they manage, and how both are verified. Data in transit and at rest: what you need to encrypt In transit The industry standard is TLS 1.2 or TLS 1.3 for any data crossing a network boundary,external APIs, admin portals, and internal microservices where the risk justifies it. The rule is simple: if sensitive data moves between systems, it should be encrypted. Auditors increasingly ask about internal service-to-service traffic, not just external connections. Organizations using service mesh frameworks or zero-trust models are well positioned here. Don’t overlook remote access (VPNs, bastion hosts, zero-trust gateways), file transfers (SFTP over plain FTP), and certificate lifecycle management,an expired TLS certificate that causes an outage is both an availability problem and evidence that controls aren’t operating effectively. At rest Encryption at rest protects stored data from unauthorized access. The most
SOC 2 compliance can sometimes feel like a needlessly complex Pandora’s box of documentation. But it shouldn’t be. That’s why today, we’ll show you how to easily become compliant with our 12-step SOC 2 compliance checklist.In its simplest form, all the SOC 2 sections point to the same question: Can you prove your controls work? This SOC 2 Compliance Checklist guides you through the process from scoping through audit completion for both SOC 2 Type 1 and Type 2. It is practical, auditor-aligned, and written for teams that want clarity rather than theory. If you want the short version: SOC 2 is not about tools or paperwork. It is about repeatable processes, clear ownership, and evidence that stands up to scrutiny. What is a SOC 2 compliance checklist? A SOC 2 compliance checklist is a structured roadmap that maps your internal controls to the AICPA Trust Services Criteria and prepares your organization for a Type 1 or Type 2 audit. For a full breakdown of SOC 2 requirements, read our detailed SOC 2 guide. How to Use This SOC 2 Compliance Checklist Think of this checklist as a living roadmap, not a one-time document. You should revisit it at four points: before scoping, during readiness, throughout evidence collection, and after the audit for continuous compliance. Type 1 vs. Type 2: Which Checklist Items Change? The core checklist does not change dramatically between Type 1 and Type 2. What changes is time and proof. Type 1 evaluates whether controls are designed correctly at a specific point in time. Type 2 evaluates whether those same controls operated effectively over an observation period, usually 3, 6, or 12 months. This means evidence for Type 2 must show consistency, such as quarterly access reviews, repeated vulnerability scans, and incident response tests that actually occurred. Who Owns Each Workstream SOC 2 is cross-functional by design. Security may lead, but it cannot succeed alone. Engineering typically owns secure SDLC, change management, and logging. IT owns IAM, endpoints, and device management. Legal and HR contribute policies, onboarding controls, and training. GRC or compliance coordinates risk assessment, evidence, and auditor communication. The fastest SOC 2 projects have named control owners with deadlines, not shared responsibility. What “Audit-Ready” Really Means Being audit-ready does not mean “we think we are secure.” It means you can produce clear, dated, and traceable evidence that maps directly to the Trust Services Criteria. Auditors test design, then operation. They expect policies, tickets, screenshots, logs, and approvals. They also expect alignment. If your policy says quarterly, your evidence cannot show annual. The AICPA provides the underlying standard, supported by SSAE 18 and AT-C 205. Pre-Checklist: Confirm You Actually Need SOC 2 Not every company needs SOC 2 immediately. If your customers are SMBs, you may see lighter requirements. If you sell to enterprises, SOC 2 often becomes non-negotiable. Security questionnaires are the strongest signal. When prospects ask about penetration testing, access reviews, and incident response evidence, SOC 2 is usually the cleanest way to respond at scale. Alternatives like ISO 27001, PCI DSS, or HIPAA can be valid. But SOC 2 is uniquely customer-facing, especially in North America. ISO 27001 is excellent for global alignment, while SOC 2 maps directly to buyer trust. The 12-Step Checklist Step 1- Define Scope Scoping mistakes cause more SOC 2 delays than any missing control. Your scope must clearly define the services you provide, the systems that support them, and the access controls. Over-scoping increases cost and complexity. Under-scoping leads to auditor pushback. In-scope systems usually include production cloud environments, CI/CD pipelines, support tooling, and identity providers. In-scope people include employees and contractors with access to customer data. Third parties are addressed as Subservice organization, using either the Carve-out method or Inclusive method. Data classification and flows must identify PII, PHI, or payment data, and how it moves through systems. Action Plan for Scoping Define the Service Commitment List In-Scope Systems Identify In-Scope People Document Third Parties Map Data Flows Validate Scope with Leadership Step 2- Select the Trust Services Criteria All SOC 2 reports include Security (Common Criteria). The others are optional but must be justified. Availability focuses on uptime and disaster recovery. Confidentiality focuses on sensitive data protection. Processing Integrity focuses on system accuracy. Privacy applies when personal data obligations are central. Your report must document why each criterion is included or excluded. Auditors look closely at this rationale. Trust Service Criteria Action Plan Confirm Security (Mandatory) Assess Optional Criteria Document Inclusion Rationale Obtain Executive Sign-Off Step 3- Choose the Audit Path and Timeline Most teams benefit from a readiness assessment before audit. This is often referred to as a Readiness assessment or Gap analysis. Type 1 audits can be completed in weeks once controls are ready. Type 2 timelines depend on the observation period. Six months is the most common balance between speed and credibility. Define control owners early and create an evidence calendar. Late evidence is the enemy of clean audits. Audit Path and Timeline Action Plan Conduct Readiness or Gap Assessment Choose Audit Type Set Observation Period (Type 2) Assign Control Owners Build Evidence Calendar Step 4- Pick an Auditor and Define the Engagement Choose a CPA firm with real SOC 2 experience in your industry. Responsiveness matters more than brand name. Confirm standards, testing approach, sampling expectations, and how subservice organizations are treated. The engagement letter should clearly state scope, period, and deliverables. A clear PBC list process avoids confusion later. Action plan for finding an auditor. Shortlist CPA Firms Review Testing Approach Clarify Subservice Treatment Finalize Engagement Letter Request Preliminary PBC List Step 5- Perform a SOC 2 Gap Analysis Map existing controls to the Trust Services Criteria. Missing policies, undocumented processes, and inconsistent evidence usually surface here. Prioritize high-risk gaps first. Document known exceptions and compensating controls honestly. Auditors prefer transparency over perfection. Gap Analysis Action Plan: Map Controls to Criteria Identify Missing Controls Prioritize by Risk Document Compensating Controls Step 6- Build the Policy and Governance
Drata is a powerful tool. It can transform a slow, resource-draining activity into a value-added automated task. But in order for it to work, it needs to be set up properly. This guide explains how SOC 2 actually works inside Drata, what you need before you begin, and how to avoid the most common mistakes that slow teams down. It is written for founders, CISOs, compliance leads, and non-technical executives who want a semi-automated approach to compliance. Drata does not replace your SOC 2 program. It operationalizes it. The platform helps you manage controls, evidence, and monitoring, but decisions, ownership, and execution still matter. A successful Drata SOC 2 project follows a predictable flow: scoping, setup, automation, validation, and audit. Before You Start: What You Need to Run a SOC 2 Project in Drata Before logging into Drata, your organization needs to be aligned. 1- Decide your SOC 2 target: Type 1 vs. Type 2 and realistic timelines SOC 2 comes in two formats defined by the AICPA. SOC 2 Type I evaluates whether controls are designed correctly at a point in time.SOC 2 Type II evaluates whether those controls operate effectively over a period, usually three to twelve months. Report Type What It Evaluates Timeframe SOC 2 Type I Whether controls are designed appropriately Point in time SOC 2 Type II Whether controls operate effectively 3–12 months With Drata, many of our clients reach Type I readiness in 6 to 8 weeks if controls already exist. Type II timelines depend on the observation period, which can range from 3 months to up to a year. If you’re pursuing SOC 2 compliance due to a client’s request, he will till you which type he requires. If you’re proactively seeking SOC 2 compliance, then we recommend going for type 2 compliance. This allows you to cast a wider net of clients. A successful SOC 2 program follows a predictable lifecycle. While tools and timelines vary, the underlying phases are consistent across most organizations. Scoping: Define the system being audited, select Trust Services Criteria, set the audit period, and confirm the auditor. Good scoping reduces downstream complexity dramatically. Setup: Configure Drata, connect integrations, publish policies, and assign control ownership. This phase turns abstract requirements into operational structure. Automation: Enable continuous evidence collection across identity, infrastructure, code, ticketing, and endpoints. Automation replaces manual tracking, but only when integrations reflect reality. Validation: Run a readiness review. Confirm that controls are operating as described, evidence is complete, and timing aligns with the audit window. This is where most hidden risks surface. Audit: Auditors independently test controls and evidence. Clarifications and minor findings are normal. Clear responses and preparation determine how fast this phase moves. Continuous compliance: After the report is issued, controls continue operating. Monitoring, reviews, and periodic reassessment prevent drift and reduce effort in future audit cycles. 2- Select your Trust Services Criteria Every SOC 2 must include the Common Criteria for Security. Additional criteria are optional and must be justified. These include Availability, Confidentiality, Processing Integrity, and Privacy. The choice of additional criteria is driven by the service agreement with the customer, which may require specific criteria, or by the type of business pursuing SOC 2. If you’re a SaaS that handles a large amount of private financial data, it makes sense to pursue the confidentiality criteria, for example. Availability makes sense if you sell uptime guarantees or SLAs. Privacy should only be selected if you are prepared to meet the additional criteria around notice, consent, and data subject rights. 3- Gather prerequisites: Systems, Owners, and Access Drata works best when you already know what is in scope. This includes cloud infrastructure, identity providers, repositories, ticketing tools, and endpoints. You also need named control owners. Automation cannot replace accountability. 4- Choose or confirm an auditor early An external CPA firm ultimately issues the SOC 2 report. Confirm your auditor before proceeding with deep configuration to avoid mismatches in expectations, evidence formats, or control interpretations. Where Axipro Fits in a Drata-Led SOC 2 Program Drata is excellent at operationalizing SOC 2. It centralizes controls, automates evidence collection, and enforces timelines that matter to auditors. What it does not do is make judgment calls, resolve ambiguity, or design controls in context. That work still belongs to the experts. This is where Axipro fits. In practice, Axipro supports Drata-led SOC 2 programs in four critical areas: Scoping discipline Before configuration begins, Axipro helps validate system boundaries, Trust Services Criteria selection, and audit periods. This prevents over-scoping, which is one of the most common reasons SOC 2 projects slow down or fail testing later. Control ownership and execution clarity Drata can track controls, but it cannot assign accountability. Axipro works with teams to ensure every in-scope control has a clear owner, a realistic execution process, and an evidence strategy that will stand up to auditor scrutiny. Readiness validation before auditor access Many SOC 2 delays happen after auditors are invited. Axipro performs structured readiness reviews to catch weak evidence, misaligned controls, and timing gaps before fieldwork begins. This reduces follow-ups, exceptions, and rework. Audit navigation and exception handling During the audit, Axipro helps teams respond to auditor questions, document compensating controls, and resolve findings clearly. This keeps the audit moving and avoids creating long-term issues that resurface in future cycles. Drata provides the operating system. Axipro helps ensure the program running on top of it is coherent, defensible, and sustainable. Step 1: Scope Your SOC 2 Program in Drata Once your prep work is done, it’s time to open Drata and start the real implementation work. Scoping is the first and most important step. It defines what the auditor will test and, just as importantly, what they will ignore. Create the audit container In Drata, scope becomes “real” the moment you create the audit. Navigate to Audit Hub, then select Create Audit. Choose SOC 2 as the framework and define the audit period. This date range matters more than most teams realize. Drata
If your company sells software, handles customer data, or operates in the cloud, chances are you have already been asked for a SOC 2 report. Sometimes by a prospect, sometimes by a procurement team, sometimes by a very persistent security questionnaire that refuses to go away. And if you are early in your compliance journey, that request can feel confusing, intimidating, or even slightly unfair. What exactly is a SOC 2 report? What does it include? How does the process actually work? And do you really need one right now? This article answers those questions clearly, without legal jargon or unnecessary complexity. Whether you are a startup selling internationally or a SaaS company expanding into enterprise deals, this guide will give you the full picture on SOC 2 compliance. What does SOC 2 stand for? SOC 2 stands for System and Organization Controls 2. It is part of a broader family of SOC reports created to help organisations demonstrate how they manage and protect information. In a nutshell, its a voluntary framework that proves that a company stores and manages data in a safe way. The “2” matters because it distinguishes this report from others in the SOC framework: Report Type Primary Focus Typical Audience SOC 1 Controls relevant to financial reporting Auditors, finance teams, regulators SOC 2 Controls related to security, availability, processing integrity, confidentiality, and privacy Customers, partners, procurement teams SOC 3 High-level public summary of SOC 2 controls General public, marketing, prospects When customers ask for “SOC 2,” they are seeking evidence that your internal systems and processes are designed to protect their data consistently and measurably. And this can be evaluated through a SOC 2 report. SOC 2 vs SOC 1 vs SOC 3: what’s the difference? SOC reports serve different purposes, and choosing the wrong one can create unnecessary work. SOC 1 focuses exclusively on controls related to financial reporting. It is primarily relevant for service providers whose systems impact a customer’s financial statements, such as payroll processors or financial platforms. SOC 2 evaluates controls related to security, availability, processing integrity, confidentiality, and privacy. It is the most commonly requested report for SaaS companies, cloud providers, and B2B service organisations because it directly addresses data protection and operational risk. SOC 3 is a high-level, public summary of a SOC 2 report. It contains far less detail and is typically used for marketing or high-level assurance, not for procurement or vendor risk assessments. If customers, partners, or regulators need detailed evidence of how you protect data, SOC 2 is almost always the correct choice. https://www.youtube.com/watch?si=_Qmle4yusN2cMOJT&v=dueT49f5wNA&feature=youtu.be Benefits of SOC 2 Compliance- Why do Companies Pursue Compliance? Companies invest in SOC 2 compliance for the commercial and operational advantages it delivers. But besides that, being able to produce a SOC 2 report will allow to cast a wider net and work with customers that you would otherwise not be able to work with. Some examples: Cloud service providers, SaaS companies, and Data Centers looking to win big enterprise contracts: These businesses are often required to do Vendor Risk Assessment due to regulations such as GDPR, HIPAA, PCI DSS, SOX, and NYDFS. Companies in tightly regulated industries: Finance, healthcare, and technology are typically regulated by norms that required SOC 2 reports and Vendor Risk Assessment. Companies bidding for government contracts: While not always required, some government bodies will ask for an SOC 2 report or ISO 27001 certification to accept bids. SOC 2 reports are becoming widespread since they cascade down: Most SOC 2 compliant businesses will require vendors to produce a SOC 2 report, and not having an SOC 2 report will often make you lose a compliant client. Besides that, the most immediate benefit is trust. A SOC 2 report reduces friction during sales cycles by answering security questions upfront, rather than repeatedly through bespoke questionnaires. So even when its not strictly required, having a SOC 2 report will be beneficial. It also improves internal discipline. Preparing for SOC 2 forces teams to formalise access controls, incident response, change management, and monitoring processes that often exist informally. Finally, SOC 2 can be a growth enabler. Many enterprise buyers will not progress without it. Having a current report keeps deals moving and prevents compliance from becoming a last-minute blocker. A 2023 procurement study published by Wired noted that vendor security reviews are now standard even for contracts under six figures, reflecting how deeply embedded assurance expectations have become. Who typically needs SOC 2 compliance? SOC 2 is most often pursued by organisations that handle customer data on behalf of others, especially where trust and security influence buying decisions. This commonly includes: SaaS and cloud-based software companies Managed service providers, IT, and security firms Data platforms, infrastructure providers, and APIs Companies selling into regulated or enterprise markets Beyond industry, SOC 2 is often triggered by stage and scale. Startups moving upmarket, companies entering enterprise sales cycles, or vendors undergoing formal vendor risk assessments are frequently asked for a SOC 2 report before deals can progress. Even when not explicitly required, SOC 2 often becomes a commercial necessity. Customers increasingly expect structured, independent assurance that security controls are not improvised, but designed, documented, and consistently followed. What is a SOC 2 report? A SOC 2 report is an independent assurance report that evaluates how well an organisation protects customer data. It is issued by a licensed CPA firm and is based on the Trust Services Criteria (TSC) developed by the American Institute of Certified Public Accountants (AICPA). In simple terms, a SOC 2 report answers one core question: Can this company be trusted to handle sensitive information securely and responsibly? Unlike ISO standards, SOC 2 is not a “certification” in the traditional sense. There is no pass or fail badge. Instead, the report documents: Your control environment How controls are designed How they operate over time Any exceptions or gaps identified by the auditor The result is a detailed report that customers and partners use to assess your
ISO 27001 Hub
The latest resources and guides for ISO 27001 Certification
AI Hub
The latest insights into AI implementation and compliance