Home / All Articles
All Articles
One in five organizations has already suffered a breach traced back to shadow AI. Meanwhile, 63% of breached organizations either have no AI governance policy at all or are still drafting one. Below is a complete, copy-ready shadow AI policy template with twelve sections, plus guidance on adapting it for your company size, your industry, and the regulatory frameworks you answer to. The template assumes one hard truth up front: your employees are already using unapproved AI tools. A policy that pretends adoption hasn’t started yet fails on day one, so this one starts from the assumption that it has. What Is a Shadow AI Policy? A shadow AI policy is a formal document that defines how your organization discovers, evaluates, approves, and governs AI tools that employees adopt outside official IT channels. The term borrows from shadow IT, the older problem of unsanctioned software and hardware, but the AI version carries sharper risks: data pasted into a public model may be retained, used for training, or exposed in ways the organization can’t reverse. The policy does three jobs: it separates approved use from unapproved use, gives employees a fast and visible way to request new tools so the sanctioned route beats the workaround, and spells out what happens when someone crosses the line, including how the organization detects it and responds. Shadow AI Policy vs. General AI Acceptable Use Policy Many organizations already have an AI acceptable use policy (AUP) and assume it covers shadow AI. It usually doesn’t. An AUP tells employees how to behave inside approved tools. A shadow AI policy governs the tools themselves: which ones exist in your environment, which ones are allowed, and what happens with the rest. You need both. The AUP handles conduct; the shadow AI policy handles inventory and control. If you only have room for one document, fold the AUP’s data-handling rules into Section 6 of the template below. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Strengthen Your Business Continuity Strategy Schedule A Consultation The Shadow AI Policy Template (Download Link and Copy-Ready Sections) We’ve created a compliance safe template for Shadow AI Policy, use the link below to create a copy and customize for your company: Download The Shadow AI Policy Template → Copy the sections below into your policy management system and replace the bracketed placeholders. The language is plain on purpose. Legalese gets skimmed. Section 1: Purpose and Scope This policy governs the acquisition, approval, and use of artificial intelligence tools, features, and services at [Company]. It applies to all employees, contractors, interns, and third parties with access to [Company] systems or data. It covers standalone AI applications, AI features embedded in existing software, browser extensions, AI agents, APIs, and personal AI accounts used for work purposes, on both corporate and personal devices. The purpose of this policy is to enable productive AI use while protecting [Company] data, customers, and legal obligations. This policy does not prohibit AI. It prohibits ungoverned AI. That last sentence matters. Employees read the purpose statement first, and it decides whether they see the policy as an enabler or a blocker. Section 2: Definitions and Terminology Shadow AI: any AI tool, feature, agent, or service used for work purposes without formal approval under this policy. Approved AI Tool: an AI tool listed in the Approved AI Tools Registry (Section 4) and used under a [Company]-managed account. Personal AI Account: an account on any AI service registered to a personal email address or paid for personally. AI Feature: AI functionality embedded within otherwise approved software (e.g., an AI assistant added to a project management tool), which requires separate evaluation. Sensitive Data: data classified as [Confidential] or [Restricted] under [Company]‘s data classification policy, including the prohibited data classes in Section 6. Define “AI feature” explicitly. Vendors now ship AI additions into already-approved SaaS products every month, and without this definition, those features inherit approval they never earned. Section 3: Roles and Responsibilities The CISO (or designated security lead) owns this policy, maintains the Approved AI Tools Registry, and runs the approval workflow. Department heads ensure their teams know the policy and surface tool requests rather than suppressing them. Legal and Compliance review tools that touch regulated data or fall under the EU AI Act, GDPR, HIPAA, or client contractual restrictions. IT operates detection and monitoring controls (Section 9). Every employee is responsible for using only approved tools for work, reporting unapproved AI use they discover, and requesting new tools through the workflow in Section 7 rather than adopting them directly. Insider Note: In organizations under roughly 200 people, the “CISO” in this section is often the same overworked IT lead who manages laptops. Name a real person, not a title that doesn’t exist yet. A policy that assigns duties to a phantom role is unenforceable, and auditors notice. Section 4: Approved AI Tools Registry [Company] maintains a registry of approved AI tools at [location/URL]. For each tool, the registry records: tool name and vendor, approved use cases, prohibited use cases, permitted data classes, account type (enterprise/team/individual), data retention and training settings, risk tier (Section 5), approval date, and next review date. Only tools listed in the registry may be used for work. Tools not listed are unapproved by default. The registry is reviewed [quarterly]. Keep the registry somewhere employees actually look, such as your intranet homepage or IT help center, not buried in a GRC platform they can’t access. An invisible registry recreates the problem the policy exists to fix. Section 5: Risk Tier Classification (Low, Medium, High) Each tool in the registry is assigned a risk tier. Low: the tool processes only public or internal non-sensitive data, runs under an enterprise agreement with training opt-out, and produces output that a human reviews before use. Approval by IT Security alone. Medium: the tool processes internal business data or connects to [Company] systems via API or integration. Approval by IT Security plus the data owner. High: the
Legacy threat modeling frameworks such as STRIDE were designed for software that behaves the same way over and over again. Agentic AI does no such thing. It can rewrite its own plan mid-task, call external tools, negotiate with other agents, and produce a different output from identical input. MAESTRO exists because none of the legacy threat modeling frameworks were built to handle that. MAESTRO stands for Multi-Agent Environment, Security, Threat, Risk, and Outcome. It is a seven-layer threat modeling framework created specifically for agentic AI systems, and it has become the closest thing the industry has to a standard method for reasoning about agent security. Understanding MAESTRO in the Context of Agentic AI What MAESTRO Stands For Each word in the acronym carries meaning. Multi-Agent Environment signals that the framework models entire ecosystems of interacting agents, not a single model behind an API. Security, Threat, Risk covers the core discipline: identifying attack surfaces, cataloging threats, and assessing likelihood and impact. Outcome is the part most frameworks skip. MAESTRO asks what an attack actually produces in the real world, because an autonomous agent with tool access turns a compromised prompt into a compromised action. The Origin of MAESTRO (Cloud Security Alliance) The Cloud Security Alliance published MAESTRO in February 2025. Its creator is Ken Huang, Co-Chair of the CSA AI Safety Working Groups and CEO of DistributedApps.ai. The CSA has since applied the framework publicly to real systems, including OpenAI’s Responses API and Google’s A2A protocol, which gives practitioners worked examples rather than just theory. The framework is openly published, and the CSA maintains an official companion tool, the MAESTRO Threat Analyzer, on GitHub. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule Free Assessment Why Traditional Frameworks Fall Short for Agentic AI STRIDE, PASTA, LINDDUN, and OCTAVE all share a founding assumption: the system under analysis follows predictable logic with clearly defined boundaries. You draw the data flow diagram, mark the trust boundaries, and enumerate threats against components that behave deterministically. Agentic AI breaks every part of that assumption. Unique Security Challenges of Autonomous Agents Agents introduce three properties that legacy models cannot express. Non-determinism means the same input can produce different behavior, so you cannot enumerate execution paths in advance. Autonomy means the agent makes decisions and takes actions without a human approving each step, which collapses the usual assumption that a person sits between intent and execution. And in multi-agent systems there is often no stable trust boundary: agents delegate to other agents, consume tool outputs from external servers via protocols like the Model Context Protocol (MCP), and update their own memory and goals at runtime. The Gap Between Legacy Frameworks and Agent-Based Systems The practical consequence is coverage gaps. STRIDE has no category for goal manipulation, where an attacker gradually steers what an agent is trying to achieve. PASTA assumes attacker objectives and data flows are fixed, which fails for systems that learn and adapt during operation. LINDDUN addresses privacy but says nothing about agent collusion or memory poisoning. A threat model built purely on these frameworks will pass review and still miss the attacks that matter most in an agentic deployment. How MAESTRO Addresses Agentic-Specific Risks MAESTRO does not discard the older frameworks. It extends them with a layered reference architecture, an AI-specific threat catalog for each layer, and, critically, explicit analysis of how threats propagate between layers. That cross-layer lens is the framework’s real contribution, because most serious agentic incidents are chains: poisoned data influences a model, the model misleads an agent, and the agent takes an unauthorized action three layers away from where the attack started. The Seven Layers of the MAESTRO Framework MAESTRO decomposes any agentic system into seven layers, each with its own threat landscape. Layer 1: Foundation Models The core LLMs or other models the agents reason with. Threats here include adversarial examples, model extraction, backdoored weights, and jailbreaks that bypass safety training. If the model is a third-party API, supply chain risk lives at this layer too. Layer 2: Data Operations Everything the agent ingests, stores, and retrieves: training data, RAG pipelines, vector databases, and agent memory. Data poisoning and memory tampering are the signature threats at this layer, and they are especially dangerous because a poisoned memory persists across sessions and keeps shaping future decisions long after the initial attack. Layer 3: Agent Frameworks The orchestration software that turns a model into an agent: LangChain, CrewAI, AutoGen, custom planners, and tool-calling logic. Threats include prompt injection through tool outputs, insecure tool definitions, and manipulation of the planning loop itself. Layer 4: Deployment Infrastructure The servers, containers, and cloud services the agents run on. The CSA’s threat catalog here reads like traditional cloud security with an agentic twist: compromised container images carrying malicious agent code, Kubernetes orchestration attacks, denial of service against agent runtimes, and tampering with Infrastructure-as-Code templates that provision agent resources. Layer 5: Evaluation and Observability The systems that monitor, evaluate, and debug agent behavior. This layer is often forgotten, and attackers know it. The CSA specifically flags poisoning observability data: manipulating the telemetry fed to monitoring systems so that incidents stay hidden from security teams while malicious activity continues. Layer 6: Security and Compliance MAESTRO treats this as a vertical layer that cuts across all others: identity and access management, guardrails, policy enforcement, and compliance controls. Threats include permission escalation, guardrail bypass, and compromise of the security agents themselves in architectures where AI enforces policy on other AI. Layer 7: Agent Ecosystem The environment where agents interact with users, other agents, and marketplaces. This is where the genuinely novel threats live: agent impersonation, misleading agent capability cards, tool squatting, and collusion between agents to achieve outcomes no single agent was authorized to pursue. Insider Note: In real assessments, Layers 5 and 6 expose the maturity gap fastest. Most teams’ shipping agents can describe their model and their orchestration framework in detail, then
AXIPRO STUDY New Study: Europe is hiring AI builders faster than AI governance professionals Axipro analyzed 3,519 AI-related job postings across eight EU countries. For every professional hired to keep AI lawful, safe and accountable, nearly seven were hired to build more of it, and the gap is widest exactly where you’d least expect. Take EU AI ACT READINESS QUIZZ 16 AI Builders : 1 AI Governors Sweden — Europe’s widest AI governance gap 3,519 Job Postings Analyzed 8 EU Countries 2 Role Categories: Builders vs Governors July 2026 Date of Job Postings Analyzed The findings Finding 1: Sweden hires 16 AI builders for every 1 person to govern them Throughout our data-set we found the same pattern across all eight countries: the more a nation hires to build AI, the less it hires to govern it. France runs eleven builders to every governor. Even Ireland, the most balanced in Europe, looks responsible mainly because the US tech giants headquartered there import global-governance discipline under overlapping DORA and AI Act pressure. 3.5→16 builders hired per governor, Europe’s most balanced country to its least. Ireland 3.5 Germany 5.7 Spain 6.0 Italy 7.1 Netherlands 7.2 Belgium 7.9 France 11.4 Sweden 16:1 0 4 8 12 16 Builders hired per AI governor Source: Axipro, 2026 Sweden has one of the strongest engineering cultures in Europe. It also carries the widest governance gap we measured: sixteen AI builders hired for every person hired to govern them. France sits close behind at eleven to one. The most balanced country, Ireland at 3.5 to one, looks responsible for a reason that has little to do with virtue. The US tech giants headquartered in Dublin import global governance discipline, and they do it under the combined weight of the AI Act and DORA, the EU financial-sector resilience regime in force since January 2025. Engineering strength does nothing to close a governance gap, and it may widen it. A country that ships AI faster produces more systems that fall under the Act’s scope and, on this evidence, fewer people positioned to document, monitor, and defend them. Being good at building AI offers no protection against governing it badly. The countries most confident in their technical talent are running the largest deficit against the law. Explore AI governance hiring by country Click any country to see how many AI builders it hires for every governance professional, and where it ranks against the rest of Europe. Germany — 5.7 builders per governorDE France — 11.4 builders per governorFR Spain — 6.0 builders per governorES Italy — 7.1 builders per governorIT Netherlands — 7.2 builders per governorNL Belgium — 7.9 builders per governorBE Ireland — 3.5 builders per governorIE Sweden — 16 builders per governorSE 3.5 — balanced 16 — widest gap Source: Axipro, 2026 Sweden 16builders for every governance professional Rank 1 of 8 · 20 governance roles vs 319 builder roles posted Only 30% of the AI governance roles name the AI Act Share this Embed this map Copy & paste — links back to Axipro Copy embed code Branded, one paste, backlink included. × Share this country insight Share this AI governance gap X / Twitter LinkedIn Facebook WhatsApp Bluesky Email Copy link Choose a platform or copy the link. A view of the same country-level dataset behind the interactive map: governance roles, builder roles, builder-to-governance ratio, and the share of governance postings that name the EU AI Act. AI governance jobs Europe statistics by country: governance roles, builder roles, builder-to-governance ratio and AI Act mention percentage. Country Governance roles Builder roles Builder-to-governance ratio AI Act mention % Sweden 20 319 16.0:1 30.0% France 39 443 11.4:1 38.5% Belgium 38 299 7.9:1 39.5% Netherlands 61 439 7.2:1 31.1% Italy 40 284 7.1:1 45.0% Spain 64 384 6.0:1 28.1% Germany 88 501 5.7:1 27.3% Ireland 96 335 3.5:1 14.6% Source: Axipro analysis of AI builder, governance and compliance job postings across eight European countries. “AI Act mention %” is the share of governance postings that explicitly name the EU AI Act. Finding 2: The law nobody names. Most AI governance jobs still do not mention the EU AI Act Europe spent years drafting the AI Act. It cleared the European Parliament, survived the Digital Omnibus revisions, and now carries penalties that reach €35 million or 7% of global turnover for the most serious breaches, a ceiling that makes GDPR fines look modest. Yet fewer than three in ten of the governance roles created to handle it actually name the law in the job description. Among builder roles, the figure collapses to one in twenty-five. More than 7 in 10 Governance job descriptions do not mention the EU AI Act. This number rises to 9 in 10 for all AI job descriptions. Despite hiring for governance, risk, privacy, and compliance roles, most employers are not yet translating the EU AI Act into explicit job requirements. That disconnect should stop you. The people being hired to make Europe compliant are, for the most part, not being hired against the Act by name. They are titled around adjacent ideas: risk, ethics, model validation, data protection. Some of that work will map onto the Act’s requirements. Much of it will not, because a role written without the regulation in view rarely produces the conformity assessments, technical documentation, and human-oversight structures the Act specifically demands. Readiness is even thinner than the headcount suggests. Simply counting governance hires overstates how many people are actually working the law. What job descriptions actually name The EU AI Act is visible in governance roles — but still absent from most job ads. Across the laws and frameworks most relevant to AI governance hiring, the EU AI Act appears in fewer than three in ten governance postings, and only 4% of builder postings. Law or framework Governance roles naming it Builder roles naming it All roles naming it Governance mentions EU AI Act 28.5% 4.0% 7.6% 127 GDPR 26.9% 5.7% 9.6% 120 ISO 27001 11.4% 1.3% 2.8% 51
78% of organizations have no formal policies for creating or removing AI agent identities, according to a 2026 report from the Cloud Security Alliance and Oasis Security. The same research found that 92% are not confident that their legacy identity and access management tools can handle the risks agents introduce. Those two numbers describe the problem in full: enterprises are deploying autonomous software that reads email, queries databases, and triggers actions across production systems, and most of them cannot say who authorized it, what it can touch, or how they would prove any of that to an auditor. This is not a future problem. Agents are already operating inside regulated environments governed by the GDPR, HIPAA, SOX, and the EU AI Act. Every access decision an agent makes is a compliance event, whether or not anyone is logging it. This article covers what regulators actually expect, where traditional IAM falls short, and how to build an access framework for AI agents that survives an audit. Understanding the Compliance Landscape for AI Agents Key Regulations Impacting AI Agent Access No regulation says “AI agent” and then hands you a checklist. Instead, agents inherit obligations from every framework that governs the data and systems they touch. Under the GDPR, an agent processing personal data triggers the full set of principles in Article 5: lawfulness, purpose limitation, data minimization, and accountability. If an agent makes decisions that produce legal or similarly significant effects on individuals, Article 22 restrictions on automated decision-making apply as well. HIPAA requires covered entities to implement access controls, audit controls, and integrity protections for electronic protected health information under the Security Rule, and an agent with access to ePHI is subject to the same technical safeguards as a human workforce member. SOX demands that access to financial reporting systems be controlled, segregated, and reviewable, which becomes genuinely difficult when an autonomous agent can touch the general ledger. The EU AI Act adds an AI-specific layer, and its timeline is widely misunderstood. Following the Digital Omnibus agreement, obligations for standalone high-risk systems under Annex III were deferred to December 2, 2027. But the Article 50 transparency obligations still apply from August 2, 2026, meaning agents that interact with people in the EU must disclose their artificial nature on the original schedule. Treating the Omnibus as a blanket delay is one of the most common compliance mistakes being made right now. Important: The Digital Omnibus deferred the high-risk regime, not the whole Act. If an AI agent interacts with users in the EU, the August 2, 2026, transparency requirements were not moved, and the AI Office’s enforcement powers go live on the same date. Do not stand down 2026 workstreams based on headlines about the 2027 deferral. How AI Agents Create New Compliance Risks Agents break the assumptions most compliance programs are built on. A human user requests access, receives a role, and behaves within a predictable envelope. An agent reasons about its own goals, chains tool calls across systems, and can attempt actions its designers never anticipated. It operates at machine speed and machine volume, so a misconfigured permission produces thousands of non-compliant data touches before anyone notices. And because agents frequently run on shared service accounts or borrowed OAuth tokens, attribution collapses: the audit log says the CRM was queried, but not by whom, for what purpose, or under whose authority. The Gap Between Traditional IAM Compliance and Agentic AI Traditional IAM assumes identities are stable, access needs are predictable, and behavior maps to a job description. None of that holds for agents. A 2026 Cloud Security Alliance survey found that 68% of organizations cannot reliably distinguish AI agent activity from human activity in their logs. For a compliance function, that is disqualifying. If you cannot separate agent actions from human actions, you cannot certify access, demonstrate segregation of duties, or respond to a data subject access request with confidence. Core Compliance Requirements for AI Agent Access Auditability and Traceability of Agent Actions Every major framework converges on the same demand: show your work. For agents, a login timestamp is not enough. A defensible audit trail captures the full chain of custody for each action: which agent acted, which human or process delegated the authority, which tool or API was invoked, which data was accessed, and what the outcome was. Gartner’s 2026 Market Guide for what it calls “guardian agents” describes exactly this pattern of recording agent-to-tool-to-target chains for compliance reporting and incident response. Data Protection and Privacy Obligations Agents must operate inside the same data protection perimeter as everything else. That means Data Loss Prevention (DLP) controls apply to agent outputs, not just human uploads. It means an agent’s access to personal data needs a lawful basis, documented before deployment, not reverse-engineered after. And it means retention rules follow the data into whatever context window, vector store, or scratchpad the agent moves it into. Separation of Duties in Autonomous Systems Separation of duties exists so that no single actor can both commit and conceal an error or a fraud. A single agent granted permissions across procurement, approval, and payment reconstitutes exactly the toxic combination SOX controls were designed to prevent, except now it executes at machine speed. The control translates directly: no agent should hold permission sets that a human in the same process would be prohibited from combining, and multi-agent workflows need the same conflict analysis as human role assignments. Consent, Purpose Limitation, and Data Minimization Purpose limitation is the principle that agents most naturally violate. An agent given broad access “to be helpful” will use data collected for one purpose to accomplish another, because nothing in its architecture knows the difference. Compliance-ready agent access means scoping data access to the declared purpose of the task and enforcing that scope technically rather than hoping the system prompt holds. Insider Note: In practice, the purpose limitation failures we see are rarely dramatic. They look like a support agent enriching a ticket with data pulled from the sales
SOC 2 is not a certification, and no auditor will ever hand you a SOC 2 certificate. What you receive at the end of the audit is an attestation report: a detailed document, often 60 to 100 pages long, in which a licensed CPA firm expresses a professional opinion on your controls. That distinction sounds like pedantry until a prospect’s security team asks to see your “certificate” and you have nothing that looks like one. This article explains exactly what a SOC 2 report is, what it contains, how it differs from an ISO 27001 certificate, and how to talk about your SOC 2 status without misrepresenting it. Is SOC 2 a Certification or a Report? The Common Misconception About “SOC 2 Certification” Search volume tells the story: far more people look for “SOC 2 certification” than for “SOC 2 attestation,” and sales teams, procurement questionnaires, and even some auditors use the certification shorthand daily. The misconception is understandable. Every other major framework in the compliance stack, from ISO 27001 to PCI DSS, ends in something that looks like a pass. SOC 2 does not work that way, and treating it as if it does leads to awkward conversations during vendor due diligence. Why SOC 2 Is Technically an Attestation, Not a Certification A certification is a binary judgment issued by an accredited body: you meet the standard, or you do not. SOC 2 sits under the AICPA’s attestation standards, primarily SSAE 18 and its later amendments (SSAE 21 updated the relevant examination sections), specifically AT-C section 105 and AT-C section 205. Under those standards, an independent service auditor examines your controls and reports an opinion on them. Nobody “passes.” The auditor attests to what they found, in writing, with evidence. The output is a report, and the report is the entire deliverable. Understanding the SOC 2 Attestation Model What Is an Attestation Engagement? An attestation engagement is a formal examination in which a practitioner evaluates subject matter prepared by another party against defined criteria, then issues a written conclusion. In SOC 2, the subject matter is your system and its controls, the criteria are the AICPA’s Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy), and the party preparing the subject matter is you, the service organization. Security is the only mandatory category; the other four are scoped in based on your service commitments. The Role of the AICPA and Licensed CPA Firms The AICPA (American Institute of Certified Public Accountants) owns the SOC framework and the attestation standards behind it, but it does not perform audits and does not issue anything to your company. Only a licensed CPA firm can conduct a SOC 2 examination and sign the resulting opinion. That licensing requirement is the quality mechanism: the firm’s professional liability, independence rules, and peer review obligations stand behind the report. In practice, this means the assurance you get is only as strong as the auditor’s reputation and independence posture, which is why enterprise buyers often look at who signed the report almost as carefully as they look at what it says. How Attestation Differs from Certification and Accreditation The three terms describe different assurance models. Certification means an accredited certification body confirms conformity with a standard and issues a certificate, as happens with ISO 27001. Accreditation is one level up: it is the process by which national bodies, such as those coordinated through the International Accreditation Forum, authorize those certification bodies to certify in the first place. Attestation involves no certificate and no accreditation chain. A CPA firm examines evidence and expresses an opinion under professional standards. The credibility comes from the auditor’s license and independence, not from a badge. What You Actually Receive After a SOC 2 Audit The SOC 2 Attestation Report Explained The deliverable is a confidential, restricted-use document addressed to your management and intended for your customers, their auditors, and other informed parties. It is dense by design. A prospect’s risk team reads it to understand what your system does, which controls you operate, how the auditor tested them, and what the auditor found. It replaces a certificate with something far more useful: evidence. Key Components of the Final Report Independent service auditor’s opinion. The first section, usually two to three pages, states the auditor’s formal conclusion on whether your system description is fairly presented and whether your controls were suitably designed (and, for Type 2, operating effectively). This is the section report readers check first. Management’s assertion. A signed statement in which your leadership formally asserts that the system description is accurate and that controls meet the applicable criteria. SSAE 18 made this management assertion a mandatory element, which means responsibility for the description sits with you, not the auditor. System description. The longest narrative section was prepared by management against the AICPA’s SOC 2 description criteria. It covers the services provided, infrastructure, software, people, data, processes, subservice organizations, and complementary user entity controls. Trust Services Criteria and controls tested. A mapping of each in-scope criterion to the specific controls you operate. This is where scoping decisions become visible: a report covering Security only looks very different from one covering all five categories. Results of testing. For Type 2 reports, a control-by-control table showing the tests the auditor performed and the results, including any exceptions. Sophisticated readers spend most of their time here, because exceptions and the auditor’s response to them reveal more than the opinion page does. What a SOC 2 Report Is NOT (No Certificate, No Logo, No Pass/Fail Badge) There is no official SOC 2 certificate, no numbered credential, and no register of “certified” companies you can be listed in. The AICPA licenses a standard SOC logo that service organizations may display for a limited time after report issuance, but the logo confirms only that an examination took place. It says nothing about the opinion inside. Anyone selling you a “SOC 2 certificate” as a standalone artifact is selling something the framework does not produce. Important: If
The full SIG content library contains 1,936 questions. SIG Lite asks 128 of them. That difference is the entire point: most vendor relationships do not justify a multi-week questionnaire exchange, and SIG Lite exists so risk teams can run standardized due diligence on lower-risk vendors without burning analyst hours or vendor goodwill. What Is SIG Lite? SIG Lite is the streamlined version of the Standardized Information Gathering (SIG) questionnaire, the most widely used third-party risk assessment instrument in the industry. It condenses the full SIG question set into a short, high-level assessment of a vendor’s information security, privacy, and resilience controls. It is a self-assessment, not an audit: the vendor answers, the assessor evaluates, and the completed questionnaire becomes evidence of due diligence in a third-party risk management (TPRM) program. Purpose of the SIG Lite Questionnaire The purpose is speed with consistency. SIG Lite gives an outsourcing organization a broad understanding of a third party’s internal control environment using a standardized question set, so answers are comparable across an entire vendor portfolio. It works either as a complete assessment for low-risk vendors or as a preliminary screen that decides whether a deeper review is warranted. Because every vendor answers the same questions, risk teams can rank, tier, and triage instead of interpreting fifty differently formatted responses. Who Created and Maintains SIG Lite? SIG Lite is owned and maintained by Shared Assessments, a member-driven standards organization formed in 2005 when the Big Four accounting firms and six global banks set out to fix the inefficiency of every company writing its own vendor questionnaire. The SIG is developed through a formal governance process that draws on practitioner feedback and tracks evolving regulations and standards, which is a large part of why it has held its position as the de facto industry template. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule Free Assessment What’s Included in the SIG Lite Questionnaire? Number of Questions and Structure The 2025 release of SIG Lite contains 128 questions. The exact count shifts slightly with each annual update (recent versions have ranged from roughly 126 to 133), so always confirm the version you are working with. Questions are predominantly yes/no with room for comments and references to supporting evidence, and each question maps back to the SIG content library and to external frameworks. SIG Lite ships as a single-worksheet questionnaire, which keeps completion and review manageable. Risk Domains Covered in SIG Lite SIG Lite draws its questions from the same 21 risk domains that structure the entire SIG, grouped into four control areas: Governance and Risk Management, Information Protection, IT Operations and Business Resilience, and Security Incident and Threat Management. In practice, that means high-level coverage of access control, information security policy, data privacy, cloud security, business continuity, incident response, supply chain risk, human resources security, compliance management, and ESG, among others. The breadth is the same as SIG Core; the depth per domain is what gets trimmed. Format and Delivery (Spreadsheet and Toolkit) Historically, the SIG has been delivered as an Excel workbook generated by the SIG Manager, the macro-driven engine inside the SIG Questionnaire Toolkit that lets assessors scope, generate, store, and compare questionnaires. That is changing. In March 2026, Shared Assessments launched SIG EV (Evolution), a browser-based platform that moves questionnaire creation, distribution, comparison, and grading to the cloud while preserving the same content and methodology. Vendors can still respond in Excel, and assessors can upload completed files, so the transition does not break existing workflows. Worth Knowing: SIG Questions & Permissions SIG questions cannot be edited without written permission from Shared Assessments, but assessors can add up to 100 custom questions to a scoped questionnaire. That is usually enough headroom to cover industry-specific requirements without abandoning the standard. When Should You Use SIG Lite? Ideal Vendor Risk Scenarios SIG Lite fits three situations well. First, vendors with no access to sensitive data or critical systems, where a full assessment would be disproportionate. Second, large vendor portfolios, where sending 600-plus questions to every supplier would stall onboarding across the board. Third, early-stage evaluation, where you need enough signal to decide whether a relationship is worth deeper diligence. Low-Risk vs. High-Risk Vendor Assessments The dividing line is data and criticality. A marketing tool that touches no customer records, a facilities contractor, or a niche SaaS product with read-only access to public data can all be assessed adequately with SIG Lite. A payroll processor, a cloud provider hosting production data, or any vendor storing regulated information under HIPAA, PCI DSS, GDPR, or GLBA should get SIG Core. Using Lite on a high-risk vendor is a documented gap waiting to be found in your next audit. Initial vs. In-Depth Risk Screening Many mature programs use SIG Lite as a gate rather than a destination. The Lite response feeds an initial risk score; vendors that trip defined thresholds (a missing incident response plan, no encryption at rest, no independent certification) graduate to SIG Core or a targeted domain-level assessment. This two-stage pattern keeps effort proportional to risk and gives vendors a lighter first touch. SIG Lite vs. SIG Core: Key Differences Both questionnaires come from the same content library and cover the same 21 risk domains. The differences are scope, depth, and effort. Question Count and Scope SIG Lite’s 128 questions sit at the top of the control hierarchy: does a policy exist, is a program in place, and is there independent validation? SIG Core’s 627 questions descend into how each control actually operates. Beyond both sits the full SIG Detail library of 1,936 questions, which assessors use to build custom scopes by regulation, domain, or control family. Depth of Assessment A SIG Lite answer tells you a vendor has an access control program. A SIG Core response tells you how privileged accounts are reviewed, how quickly access is revoked at termination, and how authentication is enforced across environments. If your obligation is
In 2018, a cyberattack on SingHealth exposed the records of 1.5 million patients, including the Prime Minister. The Personal Data Protection Commission (PDPC) handed down S$1 million in combined penalties, and that decision still sits on its public enforcement page today. The Personal Data Protection Act (PDPA) has sharper teeth than it did a few years ago. Since October 2022, the PDPC can impose financial penalties of up to 10% of an organisation’s annual turnover in Singapore, or S$1 million, whichever is higher. Breach notification is now mandatory. And a hard deadline is approaching: from 1 January 2027, using NRIC numbers for authentication becomes an enforcement target. A checklist is how you turn all of that into something you can actually execute against, rather than a legal document you skim once and forget. What Is the PDPA Compliance Checklist? A PDPA compliance checklist translates the law’s 11 data protection obligations into concrete, verifiable actions. The obligations themselves are principles: Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Protection, Retention Limitation, Transfer Limitation, Data Breach Notification, Accountability, and Data Portability (legislated in 2020 but not yet in force). A principle tells you what good looks like. A checklist tells you whether you have done it. The distinction matters because the PDPC does not accept good intentions as a defense. When it investigates, it looks for documented policies, a named Data Protection Officer (DPO), evidence of consent, and a breach plan that existed before the breach. The checklist is what produces that evidence trail. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule Free Assessment Who Needs to Follow the PDPA Compliance Checklist in Singapore Every private sector organisation that collects, uses, or discloses personal data in Singapore falls under the PDPA. That covers sole proprietorships, partnerships, companies, and foreign entities with Singapore operations. Headcount is irrelevant. A five-person startup carries the same obligations as a multinational, and the PDPC has shown it will penalize small and mid-sized businesses, not only household names. Physical presence is not the trigger either. If your processing touches individuals in Singapore, the Act can reach you even without a local office. Public sector agencies sit under separate legislation, but the private sector rules administered by the PDPC, which operates under the Info-communications Media Development Authority (IMDA), apply broadly. One useful carve-out: business contact information used purely for business purposes is largely exempt from the consent rules. Worth Knowing: PDPA Roles Explained The PDPA distinguishes an organisation from a data intermediary, a party that processes data on another’s behalf. Intermediaries carry a narrower but real set of duties, mainly protection and retention. If you outsource payroll, hosting, or email marketing, you are the organisation and your vendor is the intermediary, and the contract between you needs to say so explicitly. PDPA Compliance Checklist: Step-by-Step Guide The 15 steps below move roughly in the order you should tackle them, from governance foundations through operational controls to ongoing assurance. Treat them as a sequence, not a menu. Step 1: Appoint a Data Protection Officer (DPO) The PDPA requires every organisation to designate at least one individual responsible for compliance, and to make that person’s business contact details available to the public. You do not have to hire a specialist. In smaller firms, an existing employee can hold the DPO role alongside other duties. What matters is that the role is named, resourced, and reachable, because the DPO is who the PDPC and affected individuals contact first. Publish the contact details on your website and inside your privacy notice. Step 2: Map and Inventory Personal Data You cannot protect data you cannot see. Build a data inventory that records what personal data you hold, where it lives, which systems and people can access it, why you collected it, and how long you keep it. This map is the single most useful artifact in your entire program. It feeds your privacy notice, your retention schedule, your breach assessments, and your vendor reviews. Most compliance failures trace back to a blind spot, a spreadsheet of customer records nobody remembered, or a legacy database still holding data long past its purpose. Step 3: Establish Lawful Basis and Obtain Valid Consent Under the Consent Obligation, you generally need an individual’s consent before you collect, use, or disclose their personal data, and that consent must be tied to a specific, notified purpose. The 2020 amendments added flexibility: deemed consent covers scenarios like contractual necessity, and the legitimate interests exception lets you process data where the benefit outweighs any adverse effect, provided you document the assessment. You cannot make consent to unrelated data uses a condition of providing a service. Important: Bundled consent is a common enforcement trigger. A single checkbox that forces a customer to agree to marketing in order to complete a purchase is not valid consent for the marketing. Separate the purposes, and let people say yes to one without being forced into the other. Step 4: Draft and Publish a Compliant Privacy Notice Your privacy notice is the public expression of how you handle personal data. It should state what you collect, the purposes you collect it for, who you share it with, how long you retain it, and how individuals can contact your DPO or exercise their access and correction rights. Write it in plain language. A notice dense enough to deter reading does not satisfy the spirit of the Notification Obligation, and regulators notice the difference. Step 5: Implement the Notification of Purpose Requirement The Notification Obligation and the Purpose Limitation Obligation work as a pair. You must inform individuals of the purpose before or at the point of collection, and you must then confine your use of the data to that purpose. Practically, that means a clear notice at every collection point: sign-up forms, website pop-ups, contact forms, event registrations. Selling a customer list you gathered for order fulfillment is precisely the kind of
ISO 42001 is the first international standard an organization can be certified against for how it builds, provides, and runs artificial intelligence. It was published in December 2023 by ISO and IEC, and it defines an AI Management System (AIMS) that an accredited auditor can actually inspect. That single fact reshaped the compliance conversation for anyone shipping AI products. A SOC 2 report tells a buyer your data handling is sound. It says nothing about whether your models are governed, your training data is documented, or your automated decisions can be explained. Enterprise procurement teams figured this out fast. AI-specific questionnaires now show up in deals that used to close on a SOC 2 report alone, and buyers increasingly want a recognized certification behind the answers. ISO 42001 is becoming that certification, and Vanta is the platform many AI companies reach for to get there without building a governance program from nothing. What Is ISO 42001 and Why It Matters for AI Companies ISO 42001 at a glance: the first AI management system standard ISO/IEC 42001:2023 specifies the requirements for establishing, maintaining, and continually improving an AIMS. It follows the same Harmonized Structure as ISO 27001 and ISO 9001, so the backbone is familiar: context, leadership, planning, support, operation, performance evaluation, and improvement. The difference sits in the annexes. Annex A defines roughly 38 AI-specific controls across nine areas, covering AI policy, internal roles, resources, impact assessments, lifecycle processes, data management, information for interested parties, use of AI systems, and third-party relationships. Annex B gives implementation guidance, and Annex C lists organizational objectives and risk sources. What makes the standard distinct is that it addresses problems that generic management systems never had to. Model outputs are probabilistic. Training data governance is messy. Automated decisions are hard to explain. Risk does not sit still; it shifts every time a model is retrained or a vendor pushes an update. Who in the AI ecosystem needs ISO 42001 The standard applies across the AI value chain. Providers that build and sell AI systems, developers that create models or components, and deployers that integrate AI into their own products or operations all fall within scope. A Series B startup shipping a generative feature, an enterprise embedding AI in hiring workflows, and a public agency using AI for citizen services can each build an AIMS against the same clauses. For AI-native companies, the pull is commercial before it is regulatory. Certification is turning into a procurement filter. When a large customer’s security review asks how you govern model risk, “we have SOC 2” is no longer a complete answer. How ISO 42001 fits alongside SOC 2, ISO 27001, and the EU AI Act These frameworks are not competitors. They stack. ISO 27001 secures your information. SOC 2 proves your controls to customers. The EU AI Act is binding law with penalties. NIST AI RMF is voluntary guidance. ISO 42001 is the connective tissue that puts an auditable management system around AI specifically. Insider Note: The reason ISO 42001 sells itself in enterprise deals is that it fills a gap SOC 2 was never designed to cover. SOC 2 examines security, availability, and confidentiality. It does not ask whether you ran an AI impact assessment, whether a human reviews high-stakes model outputs, or whether you track which third-party models touch customer data. Buyers now write those exact questions into vendor questionnaires, and a 42001 certificate answers most of them before the call even starts. Need help implementing ISO 42001 in Vanta? Axipro can guide you from setup to certification readiness. Schedule Free Assessment The Unique AI Compliance Challenges Vanta Solves Managing AI-specific risks across models, data, and vendors Traditional GRC tooling was built for static controls. AI risk is not static. A model that passed review at launch can drift, a new data source can introduce bias, and a fine-tune can reclassify your legal obligations overnight. Vanta’s value for AI companies is treating these as continuous, monitored controls rather than one-time checkboxes, spanning the models you build, the data that feeds them, and the vendors whose models you embed. Keeping pace with evolving global AI regulations The regulatory floor keeps moving. The EU AI Act phases in over several years, US agencies are issuing guidance, and standards bodies are revising their work. Tracking this by hand across eight jurisdictions is not realistic for a lean team. A compliance platform that maps a single control set to multiple frameworks turns that sprawl into something maintainable. Proving trust to enterprise buyers procuring AI products The end goal of most of this work is a shorter sales cycle. Enterprise buyers procuring AI want evidence, not assurances. A live, shareable view of your AI compliance posture answers the questionnaire before it becomes a bottleneck, which is exactly what a Trust Center is built to do. How Vanta Supports ISO 42001 Certification for AI Companies Automated evidence collection mapped to ISO 42001 controls The heaviest part of any certification is evidence. Vanta connects to your cloud, identity, and development stack and pulls control evidence automatically, then maps it to the relevant ISO 42001 clauses and Annex A controls. Instead of screenshotting configurations the week before an audit, you accumulate evidence continuously. That shifts the audit from a scramble into a review. Pre-built policy templates for AI governance ISO 42001 expects documented policies for AI use, roles, and risk management. Building these from a blank page is slow and error-prone. Pre-built AI governance policy templates give teams a defensible starting point they can adapt to their actual operations, which matters when an auditor asks not just whether a policy exists but whether it reflects what you really do. Continuous control monitoring for AI systems Certification is a snapshot. An AIMS is supposed to be alive. Continuous monitoring is where the platform earns its keep, flagging when a control drifts out of compliance so you can fix it before it becomes an audit finding or, worse, a real incident. Cross-mapping ISO 42001
Most companies configure Vanta backwards. They connect integrations first, watch tests turn green, and only then ask which framework they are actually being audited against. By the time the auditor asks for the observation window start date, half the account needs to be rebuilt. The order you set things up in Vanta matters almost as much as what you set up, and getting it wrong costs weeks you do not have before a first audit. This checklist walks through the sequence that actually holds up under audit: the decisions to make before you touch the platform, the sequence of configuration inside it, and the final readiness checks before you hand the account to an auditor. Why a Vanta Implementation Checklist Matters Before Your First Audit Vanta is compliance automation software, not a compliance program. It monitors, syncs, and flags. It does not decide your scope, pick your framework, or tell you when your observation window can safely begin. Those calls are yours, and if you make them after connecting integrations rather than before, you end up rescoping mid-implementation, which resets test history and pushes your audit timeline back by weeks. A first-time implementation typically runs six to twelve weeks from account creation to a fully passing test suite, depending on how much of the underlying control environment already existed. Companies that skip the pre-implementation planning stage and jump straight into connecting AWS and Okta tend to discover, three weeks in, that half their integrations are out of scope, their policies do not match their actual operations, and their observation window needs to restart. Ready for your first audit? Get audit-ready with expert Vanta implementation support. Schedule Pre-Implementation: Foundational Decisions to Make First Define Your Target Framework (e.g., SOC 2, ISO 27001, HIPAA) Every downstream Vanta setting, from which integrations you connect to which policies you publish, depends on the framework you are pursuing. SOC 2 Type II evaluates your controls against the AICPA’s five Trust Services Criteria, security, availability, processing integrity, confidentiality, and privacy, with security as the only mandatory category. ISO 27001 asks you to build a full Information Security Management System (ISMS) under a structured set of clauses, backed by a broader set of technical, physical, and organizational controls in Annex A. HIPAA and PCI DSS bring their own control sets tied to specific data types, protected health information and cardholder data, respectively. If your customers are asking for a specific report, let that drive the decision rather than defaulting to whichever framework has the most templates in Vanta’s library. A fintech company with enterprise banking customers may need SOC 2 first and PCI DSS second. A healthcare SaaS vendor almost always needs HIPAA regardless of what else it pursues. Mapping frameworks to actual customer and contractual requirements before configuration saves you from scoping controls you will never use. Important: Choosing multiple frameworks at once is common, but sequencing them wrong creates duplicate work. Configure your primary framework fully, get through a full observation cycle if pursuing Type II, and add secondary frameworks once your evidence collection habits are established. Vanta will map shared controls across frameworks automatically, but only once both are active in the account. Set Your Audit Timeline and Observation Window If you are pursuing SOC 2 Type I, there is no observation window. The audit evaluates whether your controls are designed correctly as of a single point in time, and you can move to audit as soon as your tests pass. SOC 2 Type II is different: the observation window, also called the audit window or monitoring period, is the span during which the auditor samples evidence to confirm your controls actually operated, not just that they existed on paper. For a first Type II audit, a three to six month window is standard. Mature organizations settling into an annual cadence typically move to a full twelve-month window once they have proven consistent operation. Do not start the observation window until you are confident your controls are actually running as designed. Auditors can sample any event from the first day of the window forward, and a control failure in week two of a six-month window is just as damaging to your report as one in week twenty. This is the single most common timeline mistake first-time customers make in Vanta: they start the clock the day they finish connecting integrations, before policies are published, before HR sync is confirmed, and before access reviews have actually happened once. Identify Internal Owners and Stakeholders Every control needs a named owner inside Vanta, not a department. “Engineering” is not a control owner. The engineering manager who reviews production access quarterly is. Before you start configuring, map out who owns identity and access management, who owns vendor risk, who owns HR onboarding and offboarding, and who owns policy publication and employee acknowledgment. If your organization is small enough that one person wears several of these hats, that is fine, but it needs to be explicit in the tool, because Vanta’s task assignments and reminder emails route based on these ownership fields. Choose Your Auditor Before You Configure Vanta Auditor selection affects configuration choices that are expensive to reverse. Different CPA firms and ISO certification bodies have different tolerances for exceptions, different expectations around evidence formatting, and different preferences on how granular your control mapping should be. Get your auditor engaged, or at minimum shortlisted, before you finalize your framework scope and observation window in Vanta. Some firms will do a pre-audit readiness call that surfaces scoping issues Vanta’s automated checks will not catch, like whether a particular subprocessor needs to be in scope. Step 1: Configure Company Settings in Vanta Add Company Details and Business Information Start with the basics: legal entity name, headquarters address, description of the service you provide, and the systems that process customer data. This becomes the backbone of your system description, the narrative document that accompanies your SOC 2 report and explains what your company does and how the in-scope systems support
Two controls decide whether your ISO 27001 business continuity plan survives an audit: Annex A 5.29 and Annex A 5.30. One keeps your security controls working while everything else is failing. The other gets your systems back online before the damage becomes permanent. Plenty of teams write a continuity policy that satisfies neither in the way a certification auditor expects, and they discover the gap during the Stage 2 audit, when it is expensive to fix. This article covers what ISO 27001:2022 actually requires for business continuity, the components an auditor will ask to see, the step-by-step build, and the mistakes that turn a continuity plan into a non-conformity. What Is an ISO 27001 Business Continuity Plan? An ISO 27001 business continuity plan is the documented set of procedures that keeps information security effective and critical ICT services available during a disruption. It is not a generic “keep the lights on” binder. Under ISO 27001, the plan protects the confidentiality, integrity, and availability of information when normal operations break down: a ransomware event, a cloud outage, a data center failure, or a supplier collapse. The plan lives inside your Information Security Management System (ISMS). It draws on your risk assessment, your asset register, and your Business Impact Analysis (BIA), and it feeds your disaster recovery procedures. Scope is the part people get wrong. ISO 27001 cares about the information security aspects of continuity, not every operational hiccup a full business continuity program might cover. Why You Need a Business Continuity Plan for ISO 27001 Compliance Downtime is expensive, and the bill arrives fast. For most organizations, the question is not whether a disruption will happen, but how quickly they recover when it does. There is also a hard compliance reason. You cannot certify to ISO 27001 while ignoring continuity. The standard requires you to maintain information security during disruption and to keep ICT able to support recovery, and an auditor will ask for the evidence. A continuity plan is where availability stops being a promise and becomes a tested capability. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Strengthen Your Business Continuity Strategy Schedule A Consultation ISO 27001 Requirements Related to Business Continuity Planning ISO/IEC 27001:2022 carries 93 Annex A controls across four categories: organizational, people, physical, and technological. Continuity sits in the organizational set, and two controls do the heavy lifting, supported by two more on the technical side. Annex A 5.29 – Information Security During Disruption A.5.29 requires you to maintain information security at an appropriate level when a disruption hits. The point is that security controls have a habit of degrading under pressure. People disable multi-factor authentication to “speed things up,” logging stops on a failover system, or access controls loosen while everyone scrambles. A.5.29 says the confidentiality and integrity of your information must be maintained even while availability is under threat. It is classed as both a preventive and a corrective control, meaning it should reduce the chance of an incident and also help resolve one already underway. Annex A 5.30 – ICT Readiness for Business Continuity A.5.30 is the technical engine. It requires that your ICT readiness is planned, implemented, maintained, and tested against business continuity objectives and ICT continuity requirements. In plain terms, your servers, networks, applications, and cloud services need a defined recovery path, each with a Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and you need to prove the path works. This control is entirely new in the 2022 revision. It has no precedent in ISO 27001:2013, which is exactly why teams migrating from the older version so often have a gap here. Important: A.5.30 did not exist in ISO 27001:2013. If your continuity documentation was written against the old Annex A 17 cluster and never updated, you are missing a control the auditor will specifically test. Treat ICT readiness as a fresh requirement, not a relabel. Two technological controls back these up. Annex A 8.13 (Information Backup) requires backups to be taken and tested in line with an agreed policy, and Annex A 8.14 (Redundancy of Information Processing Facilities) covers the failover and redundancy that let critical systems keep running when a component dies. Relationship Between ISO 27001 and ISO 22301 This is where confusion is common. ISO 27001 requires the information security aspects of continuity. ISO 22301 is the dedicated standard for a full Business Continuity Management System (BCMS), covering people, facilities, supply chain, and operations far beyond information security. An ISO 27001 certificate does not certify your wider continuity program. The good news: both standards share the Annex SL high-level structure, so risk assessment, internal audit, management review, and document control carry across. Teams that already run ISO 27001 can layer ISO 22301 on top with far less effort than starting from scratch. Key Components of an ISO 27001 Business Continuity Plan Business Impact Analysis (BIA) The BIA is the foundation. It identifies your critical business processes, the ICT systems they depend on, and the cost of losing each one over time. It is where your recovery objectives come from, not from a vendor datasheet. A BIA also sets the Maximum Tolerable Period of Disruption (MTPD): the point beyond which an activity’s failure causes unacceptable damage. Risk and Disruption Scenario Assessment Your risk assessment identifies what could cause a disruption and how likely it is, feeding the Risk Treatment Plan and the Statement of Applicability (SoA) that records which controls apply. Continuity planning then runs concrete scenarios: ransomware, a regional outage, a key supplier failure, the loss of a data center. Response and Recovery Strategies For each critical system, you define how you will respond and recover: failover to a secondary site, restore from backup, or switch to a manual workaround. This links incident response to crisis management, the executive-level decision-making that kicks in when an incident escalates beyond a routine fix. Roles and Responsibilities Name real people, not departments. “IT will handle it” is the single most common
When researchers found that Microsoft 365 Copilot could be tricked into leaking corporate data from a single email, the flaw got a clean public identifier: CVE-2025-32711, severity 9.3. When a bug hunter coaxed ChatGPT into producing valid Windows product keys by framing the request as a guessing game, it got nothing. Both were prompt injections. Only one is trackable. That Vulnerability Tracking Gap in AI Security, and what it costs defenders, is the subject of this article. What Is a CVE and Why Does It Matter for Software Security? A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for a specific software flaw. It gives the whole industry one name for one bug, so a researcher in Berlin and an analyst in Bahrain know they mean the same thing. The Role of MITRE’s CVE Program in Traditional Vulnerability Management The CVE program is run by the MITRE Corporation, a US nonprofit. Since 1999 it has assigned hundreds of thousands of IDs, each tied to a discrete, reproducible defect in a defined product and version. A CVE is the connective tissue of coordinated disclosure: a researcher reports the flaw, the vendor patches it, the ID is published, and defenders map it to their own assets. Without that shared label, the same bug ends up with three names and no clear owner. The National Vulnerability Database (NVD) and CVSS Scoring The National Vulnerability Database, maintained by NIST, enriches each CVE with a CVSS (Common Vulnerability Scoring System) score from 0 to 10. That lets teams triage: a 9.3 jumps the queue, a 4.0 waits. Why Prompt Injection Breaks the Traditional CVE Model The CVE model assumes a bug lives in code, sits in a version, and can be fixed. Prompt injection violates all three. Prompt Injection as a Class of Attack, Not a Discrete Bug Prompt injection smuggles instructions into the data an LLM reads, so the model follows the attacker rather than the user. OWASP ranks it as LLM01, the top entry in its 2025 Top 10 for LLM Applications. It is a property of how language models work, not one line of faulty code, so you cannot file a CVE against it. A SQL injection either works or it does not. A prompt injection might succeed nine times in ten, fail on the eleventh, then stop working after a silent model update, which makes the “reproducible” part of reporting genuinely hard. Model Versioning vs. Software Versioning Software has clean version numbers. A weight update to a hosted model can ship silently, with no version a researcher can cite. Two calls to “gpt-4o” a week apart may not behave the same way, and there is no changelog to point at. Why “Patching” an LLM Differs From Patching Code Patching code closes a specific hole. A developer rewrites the faulty line, ships the diff, and the exploit path is gone for good. That clean, binary, auditable loop is the entire premise on which the CVE system rests. “Patching” a model offers none of it. There is no single line to fix, because the behavior the attacker abused is the same behavior that makes the model useful: it reads text and follows instructions. A vendor’s only levers, retraining, hardening the system prompt, or wrapping the model in input and output guardrails, all lower the odds of a successful attack rather than removing the possibility. The fix reduces the success rate from 80 percent to 5 percent and marks it as remediated. The hole is narrower, not closed. The recent record shows how thin that margin is. EchoLeak got past Microsoft’s dedicated cross-prompt-injection classifier by hiding its exfiltration channel in reference-style Markdown that the filter did not recognize, and the AgentFlayer exploit slipped through OpenAI’s URL safety check by routing stolen data through trusted Azure Blob Storage links. Each guardrail worked against the obvious version of the attack and fell to a rephrasing. There is a tuning tax on top of that: crank the filters too tight and the model starts refusing legitimate work, so vendors settle for a balance point rather than elimination. The practical takeaway is to treat “we’ve addressed this” as risk reduction, not closure. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule A Free ASSESSMENT The Current State of AI Vulnerability Tracking Several frameworks exist. None is a true registry of individual, citable prompt injection vulnerabilities. OWASP LLM Top 10 and the LLM01 Classification The OWASP GenAI Security Project’s LLM01:2025 entry is the most cited reference point. It is a category, not a catalog: it does not enumerate specific incidents with IDs. MITRE ATLAS for Adversarial AI Threats MITRE ATLAS is an ATT&CK-style knowledge base of adversarial tactics against AI systems, documenting 16 tactics and more than 80 techniques with real-world case studies as of late 2025. It maps how attacks work, but is not a per-vulnerability ledger with scores. AVID (AI Vulnerability Database) and Its Limitations AVID, run by a nonprofit, is the closest thing to a dedicated AI vulnerability database, cataloging failure modes with reproducible evidence. But it leans on community submissions, skews toward bias and broader failure modes, and notes that the definition of an “AI vulnerability” is itself still a working one. Vendor-Specific Disclosures vs. Industry-Wide Registries Disclosure happens vendor by vendor. OpenAI patched the Windows-key jailbreak server-side; Microsoft fixed EchoLeak and issued a CVE. There is no common venue where these land side by side. The Consequences of No Shared Threat Registry for Prompt Injection Fragmented Disclosure Across AI Vendors Each lab discloses on its own terms, on its own blog, if at all. A defender protecting a multi-model stack has to monitor a dozen channels and hope nothing slips by. Duplicate Discovery and Wasted Research Effort Researchers rediscover the same attack repeatedly. The guessing-game jailbreak, the “dead grandma” trick, and other framing attacks are variations on one theme nobody numbered. No Standardized Severity Scoring for
On November 10, 2026, third-party certification becomes mandatory for most small defense contractors that handle Controlled Unclassified Information. That date, the start of Phase 2 of the CMMC rollout, is the one to circle in red. The framework itself has been binding since the 32 CFR program rule took effect on December 16, 2024, and certification clauses began appearing in new contracts on November 10, 2025. Roughly 73 percent of the Defense Industrial Base (DIB) is made up of small businesses, and a 20-person machine shop now faces the same control set as a prime with a dedicated security team. This guide breaks down what the CMMC requirements for small business actually demand: the levels, the controls, the documentation, the real cost, and the route to certification. What Is CMMC and Who Needs to Comply? The Cybersecurity Maturity Model Certification is the Department of Defense’s program for verifying that contractors protect sensitive federal information on their own systems. For years, contractors simply self-attested compliance with NIST Special Publication 800-171. CMMC ends the honor system. It keeps self-assessment for lower-risk work and adds independent audits for everything else. Two regulations run the program. 32 CFR Part 170 defines the structure, the three levels, and the assessment rules. 48 CFR amends the Defense Federal Acquisition Regulation Supplement and embeds CMMC into contracts through clause DFARS 252.204-7021. The first sets the standard, the second makes it a condition of the award. Compliance is not optional based on company size. If you process, store, or transmit Federal Contract Information (FCI) or Controlled Unclassified Information (CUI) in the performance of a DoD contract or subcontract, CMMC applies. The requirement flows down from prime contractors to subcontractors and suppliers at every tier. The main carve-out is for companies that supply only commercially available off-the-shelf (COTS) products. The distinction between the two data types drives everything. FCI is information not meant for public release that is provided by or generated for the government under a contract. CUI is more sensitive: technical drawings, specifications, and procurement data the government requires you to safeguard. Which one you handle sets your level. The fastest way to check is your contract itself. Clauses such as DFARS 252.204-7012, 7019, and 7020 are strong signals that CUI is in scope. CMMC Levels Explained for Small Businesses CMMC has three levels. Most small contractors land at Level 1 or Level 2. Level 3 is reserved for a tiny fraction of the supply chain handling the most sensitive programs. Level 1 covers basic safeguarding of FCI. It maps to the 15 requirements in FAR 52.204-21, things most businesses already do, like using passwords and limiting who can access systems. Self-assessment is permitted and the cost is modest. Level 2 is where the majority of CUI-handling contractors sit. It requires all 110 security requirements in NIST SP 800-171 Revision 2, organized across 14 control families. Some non-prioritized contracts allow an annual self-assessment, but DoD estimates that around 95 percent of Level 2 contractors handle CUI critical enough to require a C3PAO assessment. Level 3 adds 24 selected enhanced requirements from NIST SP 800-172 on top of the full 110, for high-value programs targeted by advanced persistent threats. Assessments are conducted by the government’s Defense Industrial Base Cybersecurity Assessment Center (DIBCAC), and a contractor must already hold Level 2 certification before a Level 3 assessment can begin. Fewer than 1 percent of contractors will need it. To determine your level, read the solicitation and ask your prime directly. If any data you touch is CUI, plan for Level 2 and assume a third-party assessment until a contract tells you otherwise. Prepare Your Business for CMMC Compliance Get ready for the November 2026 CMMC deadline with expert guidance. Talk to a CMMC Expert Core CMMC Requirements Small Businesses Must Meet Level 2 requirements break into 14 control families covering 110 individual requirements and 320 assessment objectives. Access Control and System and Communications Protection are the two heaviest domains. In practice, these families fall into two buckets. The technical controls govern how your systems behave: limiting access to authorized users, requiring multi-factor authentication, logging system activity, hardening configurations, encrypting data, and detecting and responding to incidents. The administrative controls govern how your organization behaves: training staff, screening personnel, controlling physical spaces, assessing risk, and documenting everything. A small business cannot skip a family because it is inconvenient. There is no partial credit and no small-business exemption from the 110. Documentation Requirements for Small Business Compliance Assessors evaluate evidence, not intentions. Two documents anchor the entire effort. The System Security Plan (SSP) describes your environment, your CUI boundary, and how you implement each of the 110 controls. It is a living document and the first thing any assessor reads. The Plan of Action and Milestones (POA&M) records gaps, owners, and timelines for fixing them. CMMC scores Level 2 on a 110-point scale weighted by control importance. A score of at least 88 (80 percent) can earn conditional status, but only if certain high-value controls are fully met. Conditional status gives you 180 days to close every remaining item on your POA&M and pass a closeout assessment. Some critical controls cannot be deferred to a POA&M at all. Beyond the SSP and POA&M, you need written policies and procedures for each domain, plus concrete evidence that controls operate as documented: configuration screenshots, training logs, access reviews, and audit records. Pro Tip: Build your SSP Build your SSP before you spend a dollar on tools. Mapping your current state against all 110 requirements first tells you exactly where the gaps are, so you remediate the right things in the right order instead of buying software you may not need. Technical Requirements and Controls A handful of technical controls account for most assessment failures, and they deserve direct attention. The most effective cost and risk lever is scoping: isolating CUI into a dedicated enclave, a defined set of systems and networks, so the 110 controls apply only there rather than across your
Most security certifications were built for software that follows rules. AI agents do not. They consume data, draw conclusions, call tools, and take action, increasingly without a human in the loop. That gap is what AIUC-1 was created to close: it is the first auditable security standard built specifically for AI agents, and a few enterprise buyers have started asking vendors for it by name. This guide covers what AIUC-1 actually tests, the six risk domains it audits, how the certification process works, what it costs, how long it lasts, and how it aligns with SOC 2, ISO 42001, ISO 27001, and the NIST AI Risk Management Framework. It also covers the structural questions worth asking before you treat an AIUC-1 report as proof of anything. What Is AIUC-1 Certification? AIUC-1 is a certifiable standard for AI agents created by the Artificial Intelligence Underwriting Company (AIUC), a San Francisco-based, venture-backed startup founded by people with experience at organizations including Anthropic. The standard was developed with input from Orrick, Stanford, the Cloud Security Alliance, MIT, and MITRE, and launched in mid-2025. The framework comprises 51 requirements and 130 controls, organized across six risk pillars. It evaluates whether an organization has implemented and tested the technical guardrails, operational practices, and legal policies needed to reduce the risk of unsafe, unreliable, or unauthorized AI behavior. Certification applies to a specific AI system or product, not to the organization as a whole. An AIUC-1 certificate, audit report, and badge tell enterprise buyers that an agent has been independently tested against agent-specific risks. People describe AIUC-1 as the “SOC 2 for AI agents,” and the analogy holds in spirit. The difference is what it looks at. SOC 2 examines a service organization’s general controls. AIUC-1 examines how an agent behaves under pressure: when someone tries to jailbreak it, when it is asked to do something outside its scope, when it has access to data it should not expose. Worth Knowing: About AIUC-1 AIUC-1 does not define what counts as an “AI agent.” The vendor decides which system to certify and what falls in scope. That makes scope the single most important thing to check on any certificate, because a narrowly scoped audit may not cover the agent you actually use. Why AIUC-1 Certification Matters for Enterprise AI Adoption The business case rests on a simple problem: enterprises cannot reliably assess the security of their AI vendors, and the failures are expensive. According to EY research on responsible AI, 64% of companies with over $1 billion in revenue have already lost more than $1 million to AI-related failures. That gap shows up directly in sales cycles. When security, legal, and procurement teams evaluate an AI vendor, they ask about hallucinations, prompt injection defenses, and what happens when an agent makes an unauthorized call. SOC 2 and ISO 27001 do not answer those questions. AIUC-1 gives buyers a structured, third-party-tested answer, which is why holding the certificate can move a stalled procurement review forward. The certification also produces real engineering outcomes, not just a badge. AIUC has reported cases where a customer service agent’s hallucination rate dropped from 11% to under 2% after strengthening its groundedness filter, and another where inappropriate-tone outputs fell from 9% to under 2% through better defensive prompting and output moderation. One company found and patched a PII exposure vulnerability during the certification process itself. The Six Core Risk Domains Covered by AIUC-1 AIUC-1’s 51 requirements are grouped into six domains. Each targets a category of risk that traditional security frameworks were not designed to handle. Data and Privacy Covers how customer data is used, retained, and protected. Requirements address input and output data policies, limits on what data the agent can access, protection of IP and trade secrets, prevention of cross-customer data exposure, and prevention of PII leakage. This is where the standard forces clarity on whether customer data trains the model and how long it is kept. Security The adversarial-resistance domain. It covers third-party testing of adversarial robustness, detection and real-time filtering of malicious inputs, prevention of prompt injection and unauthorized agent actions, enforcement of user access privileges, and protection of the deployment environment. This is the heart of what separates an agent audit from a general security audit. Safety Focuses on preventing harmful and out-of-scope outputs. Requirements include defining an AI risk taxonomy, conducting pre-deployment testing, preventing harmful and customer-defined high-risk outputs, and flagging high-risk outputs for human review. Safety is partly judgment-based, which means documentation alone can sometimes satisfy a requirement, so the testing behind it deserves scrutiny. Reliability Targets the failure modes that erode trust in production: hallucinations and tool misuse. Controls cover hallucination prevention and restrictions on which tools an agent can call and when. For a customer-facing agent, this is the domain that keeps it from inventing a refund policy or triggering the wrong workflow. Accountability Covers what happens when things go wrong. Requirements include AI failure response plans, vendor due diligence, and clear AI disclosure so users know when they are interacting with an agent. With human workers, accountability is built into org charts and chains of command. Agents need an equivalent, and this domain supplies it. Society The broadest domain, focused on preventing misuse with wider consequences: AI-enabled cyber attacks and CBRN (chemical, biological, radiological, nuclear) misuse. Most enterprise agents will touch only a few of these controls, but they matter for higher-capability systems. Insider Note: Of the 130 total controls, roughly 65 are mandatory, and 65 are optional. A straightforward agent typically needs to meet around 40 controls. A complex, multi-modal agent gets closer to 65. The scoping exercise determines which apply, so two AIUC-1 certificates can represent very different amounts of work. Ready to Earn Your AIUC-1 Certification? Accelerate Your AI Certification Journey Talk to an Expert Who Needs AIUC-1 Certification? AIUC-1 is built for any company developing or deploying agentic AI that sells into enterprises. The strongest fit is an organization whose product uses AI agents in customer-facing operations, handles
Most teams walk into a SOC 2 audit expecting standard requirements for their password policy: minimum length, 90-day rotation, one uppercase letter, one symbol, and so on. But there is no such checklist. The AICPA never published a list of mandatory password rules, and the federal guidance that most auditors lean on has thrown out half of what passed for best practice a decade ago. Beyond compliance, this is remains a crucial cybersecurity control: Stolen and brute-forced credentials still drive a large share of breaches, and password policies are the main way to mitigate this risk. This guide covers what SOC 2 expects around passwords, where those expectations come from, and how to build a policy that satisfies an auditor without making your security worse. What Are SOC 2 Password Requirements? SOC 2 password requirements are the access controls that a service organization implements to govern how passwords are created, stored, enforced, and retired, all in service of the Trust Services Criteria. The important word is controls, not rules. SOC 2 does not hand you a specification. It asks whether your controls are suitably designed and operating effectively to keep unauthorized people out of your systems. The Role of Passwords in the SOC 2 Trust Services Criteria The Trust Services Criteria, developed by the AICPA, are the evaluation standard for every SOC 2 report. Passwords sit inside the Security category, which is mandatory in all SOC 2 engagements, and specifically inside the Common Criteria series CC6, covering logical and physical access. Passwords are one of the most basic logical access controls you have, and one of the most scrutinized, because CC6 is usually the most evidence-intensive part of the entire audit. Relevant Common Criteria: CC6.1, CC6.2, and CC6.3 CC6.1 covers the controls that restrict logical access to systems, infrastructure, and data, this is where your password policy, MFA enforcement, and account lockout settings live. CC6.2 governs how access is granted, modified, and removed, meaning your provisioning workflows, access reviews, and offboarding processes are all evaluated here. CC6.3 focuses on the removal of access when it is no longer needed and the management of privileged credentials specifically. Together, these three criteria map to the full lifecycle of a credential: creation, ongoing use, and retirement. An auditor working through CC6 will expect evidence at every stage. Does SOC 2 Mandate Specific Password Rules? No. The AICPA is explicit that the Trust Services Criteria do not define the controls an organization must have. You identify and implement controls that meet the criteria, and the auditor evaluates them. That means there is no AICPA-mandated minimum length, no required rotation interval, and no prescribed complexity formula. What the auditor checks is whether your stated controls exist, work, and reasonably prevent unauthorized access. Insider note: Auditors rarely fail you for choosing a 10-character minimum over 12. They fail you when your written policy says one thing and your actual system configuration says another. Consistency between the policy document and the enforced setting matters far more than the specific number. Why Password Requirements Matter for SOC 2 Compliance Preventing Unauthorized Access Credentials are the front door. The 2025 Verizon DBIR found that stolen credentials remained the single most common initial access vector, appearing in 22% of breaches, and that brute force attacks against basic web applications nearly tripled year over year. Strong authentication controls are the difference between an attacker hitting a wall and an attacker walking straight in with a valid login. Reducing Data Breach Risk Weak or reused passwords feed credential stuffing, where attackers replay username and password pairs harvested from earlier breaches against your login pages. Reuse is rampant: research from Microsoft’s Digital Defense Report routinely finds that the majority of people reuse passwords across services. A single leaked password elsewhere becomes a working key to your environment unless your controls catch it. Demonstrating Logical Access Controls to Auditors SOC 2 is an attestation. It is not enough to be secure; you have to prove it with evidence. Well-designed password controls produce exactly the artifacts an auditor wants: configuration screenshots, enforcement logs, MFA reports, and access review records. Good controls and good evidence are two sides of the same coin, and an internal audit process that routinely collects this evidence makes the formal engagement significantly less stressful. Core SOC 2 Password Requirements Although SOC 2 prescribes nothing specific, a defensible password policy almost always addresses the same set of controls. These are what auditors expect to see and what your peers in compliance treat as table stakes. Minimum Password Length Length is the strongest single lever for password entropy, and modern guidance favors it over everything else. A common defensible baseline is at least 12 characters for standard user accounts, with longer requirements for service and admin accounts. NIST SP 800-63B recommends that verifiers support passwords up to 64 characters so that passphrases and password-manager output are never truncated, an important implementation detail that many teams overlook. Password Complexity and Blocklists Old-style complexity rules, one uppercase, one symbol, one number, are fading, and for good reason. They push users toward predictable substitutions without meaningfully raising entropy. The more effective control is a blocklist: screening new passwords against dictionaries of common and previously breached credentials and rejecting matches. Tools like Have I Been Pwned’s Pwned Passwords API make this straightforward to implement. This stops Password1! from sneaking through even though it technically satisfies a legacy complexity rule. Password Rotation and History Forced periodic rotation is the control most teams keep out of habit, and it is also the one that modern guidance most clearly discourages. Rotation pushes users toward predictable patterns, Spring2025 becoming Summer2025, without improving security in any measurable way. Password history settings, which prevent the immediate reuse of recent passwords, still have a place, but blind calendar-based expiry should be replaced with event-driven resets: force a change when there is evidence of compromise, not because the calendar says 90 days have passed. Account Lockout After Failed Login Attempts An account
A 300-question security review used to eat a full week of an analyst’s time. In 2026, the teams winning enterprise deals turn that same review around in an afternoon. The gap between those two outcomes is no longer about how many people you throw at the problem. It is about whether your answers live in a structured, searchable knowledge base that AI can draw from, or whether they are scattered across old spreadsheets, Slack threads, and the memory of one overworked security engineer. Security questionnaires have grown longer, more frequent, and more specific. Buyers send the Standardized Information Gathering (SIG) questionnaire, the Consensus Assessments Initiative Questionnaire (CAIQ), the HECVAT for higher education, and an endless stream of custom forms, often through portals like OneTrust or ServiceNow that resist copy-paste. Each one stalls a deal until someone answers it. That is why questionnaire automation has shifted from a nice-to-have to a core part of how revenue and security teams operate. This guide reviews the nine tools worth evaluating this year, maps each to the team it actually fits, and shows you how to choose without falling for the inflated accuracy claims every vendor prints on its homepage. What Is Security Questionnaire Automation Software? Security questionnaire automation software uses AI, usually a large language model (LLM) paired with retrieval-augmented generation (RAG), to draft answers to incoming vendor security assessments. Instead of an analyst hunting through a SOC 2 report or a policy document, the software matches each question to verified content in a central knowledge base and generates a cited response in seconds. The better platforms do more than draft text. They ingest a questionnaire in any format, route questions that need a human to the right subject matter expert, attach supporting evidence, track approvals, and submit the finished response back in the buyer’s original format or portal. The output is a workflow, not just a wall of generated answers. Key Benefits of Using Security Questionnaire Automation Software Faster Turnaround on Security Reviews Speed is the headline benefit and the one buyers feel first. Teams routinely report cutting response time from several days to a few hours, and concierge services advertise turnaround as short as twelve hours on standard questionnaires. When a security review is the last gate before a contract signs, shaving a week off it directly accelerates the sales cycle. Higher Accuracy and Consistency Manual answers drift. One analyst describes your encryption posture one way, another phrases it differently three months later, and a sharp-eyed buyer notices the inconsistency. A central knowledge base enforces one approved answer per question, so every response reflects the same source of truth. That consistency matters more than raw speed when a regulated buyer is reading closely. Reduced SME and InfoSec Bottlenecks The real constraint in most questionnaire programs is not typing. It is the queue of questions waiting on a subject matter expert who already has a day job. Automation handles the repetitive eighty percent automatically and surfaces only the genuinely novel questions for human input, which frees your InfoSec team to review rather than author. Stronger Audit Trails and Compliance Posture Every credible platform now logs who answered what, when, and from which source. That audit trail is useful for the questionnaire itself, but it also feeds your broader compliance posture. When an auditor asks how you keep customer-facing security claims accurate, a versioned, evidence-linked knowledge base is a far stronger answer than a folder of spreadsheets. Insider Note: Every vendor on this list advertises an accuracy figure, usually 92 to 96 percent. Read the denominator before you believe it. A 95 percent accuracy rate measured against questions the AI chose to answer is very different from 95 percent across an entire real questionnaire including the hard, company-specific ones. The number that matters is how many answers ship without a human rewrite, and only a pilot on your own questionnaires reveals that. What to Look for in the Best Security Questionnaire Automation Software AI Answer Accuracy and Grounded Retrieval The core engine should retrieve from your approved content and ground every answer in it, not generate plausible-sounding text from a general model. Grounded retrieval is what keeps the AI from inventing a control you do not actually have, which is the failure mode that destroys buyer trust instantly. Knowledge Base Management and Governance The knowledge base is the asset, not the AI. Look for version control, expiry dates on answers, owner assignment, and tools to retire stale content and merge duplicates. A platform that makes library maintenance painful will quietly rot, and a rotten library produces confident wrong answers. Support for Any Questionnaire Format (Excel, Word, PDF, Portals) Buyers send questionnaires in whatever format suits them. If the software handles a clean Excel file but chokes on a messy Word table or a scanned PDF, you will fall back to manual work for a meaningful share of your volume. Format coverage is unglamorous and decisive. Portal Auto-Fill (OneTrust, ServiceNow, ProcessUnity) Portal-based questionnaires are where most automation ROI leaks away. A tool that drafts beautiful answers but cannot push them into an OneTrust or ServiceNow GRC portal leaves you copy-pasting field by field. The strongest platforms offer a browser extension that completes portal forms directly. Important: When you scope a tool, ask specifically how it handles the portals your largest buyers use. Many platforms quietly degrade to a sidebar that helps you find content to paste manually rather than truly auto-filling. That distinction can be the difference between a one-hour review and a half-day of clicking. Evidence and Citation Backing In 2026, sophisticated buyers expect answers backed by source links: a policy, a control record, a test result. Citation backing is becoming the baseline for a buyer to trust an automated answer, and it doubles as your internal proof that the answer is defensible. Collaboration and Approval Workflows Questionnaires are cross-functional. Sales owns the deadline, security owns the truth, and legal sometimes owns the wording. The platform should assign sections, track ownership, and
Three Gulf states now run three different data protection regimes. Saudi Arabia’s regulator has already issued dozens of enforcement decisions. Bahrain has had a working statute since 2019, and the UAE has a federal law on the books but is still waiting on the executive regulations that will give it teeth. For any company operating across the region, the practical question is no longer whether these laws apply but how far apart they sit, and where compliance built for one falls short of another. This is a structured comparison of the personal data protection laws in Bahrain, UAE, and Saudi Arabia: what each one demands, where they converge on familiar GDPR principles, and the specific points where treating them as interchangeable will get you fined. The Three Laws at a Glance Bahrain moved first. Law No. 30 of 2018, the Personal Data Protection Law (PDPL), came into force on August 1, 2019, making it the first comprehensive standalone data protection statute in the Gulf Cooperation Council. It is supplemented by ten ministerial resolutions issued in 2022 that cover transfers, security measures, and notification procedures. The UAE followed with Federal Decree-Law No. 45 of 2021, effective January 2, 2022 — the country’s first federally applicable, GDPR-style law, issued alongside Federal Decree-Law No. 44 of 2021, which created the UAE Data Office as the federal regulator. The catch is that the executive regulations meant to flesh out timelines and penalties have still not been published, which leaves parts of the regime in a holding pattern. Saudi Arabia’s Personal Data Protection Law, issued by Royal Decree M/19 in September 2021 and amended in March 2023, is the strictest and the most actively enforced of the three. It came into force on September 14, 2023, and a one-year grace period ended on September 14, 2024. Since then, every organization processing the personal data of people in the Kingdom has been fully on the hook. Worth knowing: Saudi Arabia’s PDPL Saudi Arabia’s PDPL protects a person’s data not only during their lifetime but after death. That post-mortem protection is unusual among global privacy laws and means retention and disclosure decisions cannot assume an individual’s rights simply lapse when they die. Who the Laws Actually Reach All three statutes reach beyond their own borders. Bahrain’s PDPL applies to anyone residing or doing business in Bahrain, and to entities outside the country that process personal data using equipment located inside it. The UAE law applies to the processing of data belonging to people in the UAE, regardless of where the controller or processor is based. Saudi Arabia goes furthest, applying to any entity inside or outside the Kingdom that processes the personal data of Saudi residents — a scope that pulls in international businesses that may never have considered themselves subject to Gulf regulation. The big structural difference is the UAE’s free zones. The federal PDPL does not apply inside zones that maintain their own data protection regimes, most notably the Dubai International Finance Centre (DIFC) and the Abu Dhabi Global Market (ADGM), each of which runs its own established framework. A company in the DIFC answers to DIFC rules, not the federal law. That carve-out has no equivalent in Bahrain or Saudi Arabia, and it matters enormously for regional structuring decisions. Ready for GCC data privacy compliance? Talk to our experts and simplify Bahrain, UAE, and Saudi data privacy compliance. Schedule The Regulators Each country has its own supervisory authority, and they are at very different stages of maturity. Bahrain’s Personal Data Protection Authority (PDPA) operates under the Ministry of Justice, Islamic Affairs and Waqf and has full investigation, audit, and penalty powers. SDAIA — the Saudi Data and Artificial Intelligence Authority — is the current regulator in Saudi Arabia, with long-term supervision potentially moving to the National Data Management Office under the Kingdom’s wider data governance framework. SDAIA is visibly active: its enforcement committees issued 48 decisions confirming PDPL violations across the 2025 and 2026 review cycles, a level of regulatory output that should get the attention of any compliance team operating in the region. The UAE is the outlier. The UAE Data Office exists in law but is not yet fully operational, and the Telecommunications and Digital Government Regulatory Authority was tasked with providing administrative support during the office’s early years. In practice this means data subjects in the UAE currently lack a clear federal route to lodge a complaint, and enforcement guidance is still maturing. That ambiguity cuts both ways: it reduces immediate enforcement risk, but it also makes it harder to know exactly what compliance looks like. Lawful Basis, Consent, and Core Principles Consent sits at the center of all three regimes, but Bahrain leans on it hardest. Bahrain’s PDPL sets a default rule that personal data may not be processed without the data subject’s written and explicit consent, with a narrow set of alternative bases such as contract performance, legal obligation, and vital interests. Saudi Arabia and the UAE both recognize consent alongside other grounds, and Saudi Arabia’s amended law added legitimate interest as a basis — though it cannot be used for sensitive data and controllers are warned against treating consent as a convenient fallback when a more specific ground applies. Beneath the lawful-basis question, the three laws share the principles that anyone familiar with the same GDPR-shaped foundation will recognize: lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, and security. The vocabulary and structure track the European model closely, and deliberately so. That means a mature GDPR program is a strong starting point, not a finished one — the architecture transfers, but the local rules introduce enough variation to demand dedicated attention. Data Subject Rights The rights packages are broadly similar across the three jurisdictions, but the enforcement emphasis differs. Individuals in all three countries can access their data, request correction, and object to certain processing. Saudi Arabia’s PDPL spells out the most comprehensive set — including access, correction, deletion, objection, and portability —
ISO 14001:2026 took effect on April 15, 2026, and it carries the first genuinely new clause the environmental standard has seen in over a decade. Any checklist built against the 2015 edition is now partly out of date. The structure auditors examine has shifted to the ISO Harmonized Structure, climate change is written into the requirements rather than bolted on through an amendment, and a new change management clause gives certification bodies a fresh place to record findings. This guide breaks down what an ISO 14001 certification audit checklist needs to cover now, clause by clause, and how to use it without turning your environmental management system into a paperwork exercise. What Is an ISO 14001 Audit Checklist? An ISO 14001 audit checklist is a structured set of questions and verification points an auditor works through to confirm an environmental management system (EMS) meets the requirements of the standard. It maps each clause to specific evidence: documents, records, interviews, and observed practice. The checklist is the auditor’s working tool, not the audit itself. A good checklist prompts the auditor to look for objective evidence rather than tick boxes, and it leaves room to record where the documented system and actual practice diverge. That gap — between what the procedure says and what people actually do — is where most findings come from. Stay Ahead of ISO 14001:2026 Changes Book an ISO 14001 Gap Assessment Schedule Why You Need an ISO 14001 Audit Checklist Without a checklist, audits drift. Auditors skip clauses, linger on the areas they find interesting, and produce findings that are hard to compare year over year. A checklist enforces coverage and consistency, which matters most when more than one auditor works the program or when you want surveillance results that trend cleanly against the baseline. It also protects you before the certification body arrives. A disciplined internal audit run against a checklist that mirrors the external audit surfaces the same nonconformities your registrar would — while you still have time to fix them. The checklist turns a once-a-year scramble into a repeatable process. Worth knowing: ISO 19011 ISO 19011 is the international guideline for auditing management systems, and it is not a standard you can certify against. You cannot become “ISO 19011 certified.” It exists to make your audit program competent and consistent — which is exactly what a third-party auditor checks when they review your internal audit records. Types of ISO 14001 Audits Not every audit serves the same purpose, and your checklist depth should match the audit type. The four you will encounter are internal, second-party, third-party certification, and the surveillance and recertification audits that follow. Internal Audit Sometimes called a first-party audit, this is conducted by or on behalf of the organization itself. It is a requirement of Clause 9.2, and it is the single most important audit you run, because it is the one you control. Internal audits should be planned across a program, cover the full EMS over the cycle, and use auditors who are competent and independent of the work they assess. Second-Party Audit A second-party audit is one organization auditing another it has a relationship with — most often a customer auditing a supplier or a company auditing its contractors. Under the 2026 revision, with its sharper focus on externally provided processes, products, and services, expect more of these as larger buyers push environmental criteria down their supply chains. Third-Party Certification Audit This is the audit that earns the certificate. An accredited certification body assesses your EMS against ISO 14001 in two stages. Stage 1 is a readiness review that checks whether the system exists, is documented, and is ready to be assessed. Stage 2 verifies that the EMS is fully implemented, effective, and producing the results it claims. Certification follows only once any major nonconformities are closed. Surveillance and Recertification Audits ISO management system certificates run on a three-year cycle governed by ISO/IEC 17021-1. After initial certification, the body conducts annual surveillance audits in years two and three to confirm the system is still operating, then a recertification audit before the certificate expires. Surveillance audits are narrower than the full assessment, but they are not a formality — and many organizations will fold their move to ISO 14001:2026 into a surveillance or recertification visit to keep cost and disruption down. ISO 14001 Audit Checklist: Clause-by-Clause Breakdown ISO 14001:2026 follows the ISO Harmonized Structure, the common framework shared with ISO 9001, ISO 45001, and ISO/IEC 27001. The familiar Plan-Do-Check-Act cycle still runs underneath it. Clauses 1 through 3 cover scope, references, and terms. The auditable requirements live in Clauses 4 through 10, and that is where your checklist does its work. Clause 4: Context of the Organization Verify that internal and external issues, interested parties, and the EMS scope are identified and documented. This is where the 2026 revision lands hardest. Context analysis must now explicitly weigh environmental conditions — including climate change, biodiversity, pollution levels, and the availability of natural resources. A context review that mentions only commercial and regulatory factors will draw a finding. Clause 5: Leadership and Commitment Check for evidence that top management is involved in substance, not ceremony. The environmental policy must be documented, communicated, and appropriate to the organization. Auditors look for real engagement: leaders who can speak to the policy, the objectives, and how environmental performance feeds into business decisions. The 2026 wording tightens leadership accountability, so a policy signed once and forgotten will not hold up. Clause 6: Planning and Risk Assessment This clause covers environmental aspects and impacts, compliance obligations, risks and opportunities, and objectives. It generates more nonconformities than almost any other. The life cycle perspective in Clause 6.1.2 is strengthened, with clearer expectations on upstream and downstream impacts. The headline change is Clause 6.3, Planning of Changes — the only entirely new clause in the revision. It requires a structured, planned approach to changes that affect the EMS, such as new products, site relocations, supplier changes, or process
A 3PAO is the independent firm that decides whether a cloud service is secure enough to handle federal data. The acronym stands for Third-Party Assessment Organization, and these accredited auditors sit at the center of the FedRAMP process. A federal agency will not grant an Authority to Operate (ATO) at the Moderate or High impact level without a 3PAO assessment behind it. That makes the 3PAO one of the most consequential vendors a cloud service provider (CSP) will hire on the road to the federal market. This guide explains what a 3PAO is, what it actually does, how a firm earns the accreditation, and when you should bring one in. It also covers how the role is changing under FedRAMP’s 2025 overhaul, because the job looks different now than it did even a year ago. What Does 3PAO Stand For? 3PAO stands for Third-Party Assessment Organization. The “third party” part is the whole point. The assessor is independent of both the cloud provider being evaluated and the government agency relying on the results. That independence is what gives a 3PAO report its weight. An agency can trust the findings precisely because the assessor has no stake in the outcome. What Is a 3PAO? A 3PAO is an independent firm accredited to evaluate the security of cloud services seeking authorization under FedRAMP, the Federal Risk and Authorization Management Program. The FedRAMP Program Management Office (PMO) recognizes these firms only after they pass a demanding accreditation process. Once recognized, a 3PAO is listed publicly on the FedRAMP Marketplace under the Assessors tab, where CSPs and agencies can find them. 3PAOs are not limited to federal work. The same firms are commonly authorized to perform GovRAMP assessments, the program formerly known as StateRAMP, for state and local government cloud procurement. The skill set transfers directly, since both programs lean on the same NIST control foundations. What Does a 3PAO Do? A 3PAO independently tests whether a cloud service offering (CSO) does what its documentation claims. The longer version breaks into four distinct areas: 1- Independent Security Assessments The core deliverable is a security assessment. The 3PAO evaluates a CSP’s controls against the relevant FedRAMP baseline, which maps to NIST SP 800-53. It builds a Security Assessment Plan (SAP), executes the testing, and documents the findings in a Security Assessment Report (SAR). The SAR is the artifact an agency’s Authorizing Official reads when deciding whether to grant an ATO. 2- Documentation Review and Validation Before any testing happens, the 3PAO reviews the System Security Plan (SSP), the primary document describing how each control is implemented. SSPs routinely run to hundreds of pages, and a vague or incomplete one will stall the schedule fast. The assessor checks that what the SSP claims matches what the system actually does, then tracks unresolved issues in a Plan of Action and Milestones (POA&M). 3- Penetration Testing FedRAMP assessments include mandatory penetration testing, and the 3PAO performs it. The assessor probes the system the way an attacker would, looking for exploitable weaknesses that control documentation alone would never surface. A clean SSP means little if a tester can walk straight through the front door. 4- Ongoing Continuous Monitoring Support Authorization is not a one-time event. CSPs must sustain compliance through continuous monitoring (ConMon), which includes regular scanning, vulnerability remediation, and periodic reassessment. 3PAOs often support annual assessments and significant-change reviews. One structural note worth tracking: as of March 2025, FedRAMP stopped running centralized continuous monitoring, and that responsibility now sits with each sponsoring agency. Worth knowing: 3PAO Reports FedRAMP states that 3PAO reports “serve as the basis from which the federal government makes informed, risk-based authorization decisions.” The assessment is not a formality. It is the evidence the entire authorization rests on. How Does an Organization Become an Accredited 3PAO? Becoming a 3PAO is nearly as demanding as the assessments these firms perform. There is one accreditation body, and the bar is high. A2LA Accreditation Requirements The American Association for Laboratory Accreditation (A2LA) is the sole body that accredits FedRAMP 3PAOs. Its FedRAMP 3PAO accreditation program puts applicants through a rigorous evaluation of technical competence. A firm must spend at least a year in A2LA’s Cybersecurity Inspection Body Program before it can even be considered for FedRAMP recognition, and it must pass technical proficiency testing administered through A2LA’s testing partner. ISO/IEC 17020 Compliance Accreditation hinges on conformance with ISO/IEC 17020, the international standard for bodies that perform inspections. The standard sets requirements for impartiality, independence, technical competence, and a functioning quality management system. In practice, this is what stops a 3PAO from cutting corners or playing favorites. The accreditation certifies the firm’s process, not just the talent of its people. FedRAMP-Specific Requirements Beyond ISO/IEC 17020, FedRAMP layers on its own recognition requirements covering program-specific knowledge and assessment methodology. A firm has to demonstrate it understands FedRAMP’s baselines, templates, and reporting expectations — not just general inspection practice. Only after clearing both bars does the firm appear on the Marketplace as a recognized 3PAO. Why Are 3PAOs Important for FedRAMP? FedRAMP runs on a “do once, use many” philosophy. One rigorous, independent assessment lets multiple federal agencies reuse the same authorization package instead of each running its own review. The 3PAO is what makes that trust transferable. Because the assessor is accredited and independent, an agency in one department can rely on a SAR produced for another. The program exists because federal systems must meet security obligations set under FISMA, the Federal Information Security Modernization Act, and the General Services Administration (GSA) runs FedRAMP to standardize how cloud services meet them. Without accredited assessors, every agency would judge cloud security on its own terms — which is exactly the fragmentation FedRAMP was built to end. Worth knowing: The FedRAMP Authorization The FedRAMP authorization landscape changed significantly in 2024 and 2025. The Joint Authorization Board (JAB) and its provisional ATO path were dissolved under OMB Memorandum M-24-15, leaving a single “FedRAMP Authorized” designation. Authorizations now flow through agency authorization or
The NIST AI Risk Management Framework (AI RMF 1.0) is the most widely referenced standard for managing AI risk in the United States, and it is not a law, a regulation, or a certifiable standard. It is voluntary guidance. That combination explains both its rapid adoption and the confusion around it: regulators cite it, enterprise buyers ask about it in security questionnaires, and AI governance programs are built on it, yet no auditor will ever hand you an AI RMF certificate. This article explains what the framework actually contains, how its four core functions work, and where it fits alongside ISO/IEC 42001 and the EU AI Act. What Is the NIST AI RMF 1.0? Background and Purpose of the Framework The AI RMF is a structured approach for identifying, assessing, and managing the risks that AI systems create across their entire lifecycle, from design and data collection through deployment, monitoring, and decommissioning. Its stated goal is to help organizations build and use AI systems that are trustworthy: valid, reliable, safe, secure, accountable, transparent, explainable, privacy-enhanced, and fair. The framework treats AI as a socio-technical system, meaning risk does not come from models and data alone. It also comes from how people build, deploy, oversee, and interact with those systems. That framing is the single most important idea in the document, because it pushes risk management beyond model accuracy metrics and into governance, human oversight, and organizational culture. Who Published It and When The framework was published by the National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce, on January 26, 2023. The official document is NIST AI 100-1, developed over 18 months of public workshops, requests for information, and two public draft rounds. Congress directed NIST to create it through the National Artificial Intelligence Initiative Act of 2020, so the framework carries legislative backing even though compliance with it does not. Voluntary Nature of the Framework NIST describes the AI RMF as voluntary, rights-preserving, non-sector-specific, and use-case agnostic. There is no enforcement mechanism, no audit regime, and no certification. In practice, the word voluntary undersells its weight. U.S. regulators, including the FTC and sector agencies, reference NIST principles when assessing whether an organization exercised reasonable care; federal contractors face growing expectations to demonstrate NIST-aligned AI governance, and enterprise procurement teams increasingly ask vendors how they apply it. Voluntary frameworks have a habit of becoming de facto requirements, and the AI RMF is following that exact path. Insider Note: In vendor risk assessments, “do you align with the NIST AI RMF” is becoming the AI equivalent of “do you have a SOC 2 report.” There is no certificate to show, so what buyers actually want is documented evidence: an AI inventory, a risk assessment methodology, and named accountability for AI decisions. Organizations that can produce those three artifacts pass most questionnaires. Why the NIST AI RMF 1.0 Was Developed Addressing Unique AI Risks Traditional software risk frameworks assume deterministic systems: the same input produces the same output, and failures are traceable to specific defects. AI systems break those assumptions. Models drift as real-world data shifts; training data can embed historical bias at scale; outputs can be opaque even to their developers; and the same model can behave differently across deployment contexts. The AI RMF was built specifically for these properties. It treats risk as continuous rather than one-shot, requiring ongoing measurement and monitoring instead of a single pre-deployment review. Building Trustworthy AI Systems The second driver was the trust gap. By 2022, organizations were deploying AI faster than they could explain or govern it, and high-profile failures in hiring, lending, and facial recognition had made AI bias a mainstream concern. NIST’s answer was to define trustworthiness in operational terms rather than aspirational ones, breaking it into seven measurable characteristics that risk, security, and product teams could actually work against. Key Drivers Behind Its Creation Three forces converged. First, the congressional mandate in the National AI Initiative Act of 2020. Second, international momentum: the framework explicitly aligns with the OECD AI Principles, positioning U.S. guidance within a global consensus on responsible AI. Third, industry demand for a shared vocabulary. Before the AI RMF, every organization defined AI risk differently, which made procurement, audits, and cross-industry collaboration unnecessarily painful. The framework gave executives, engineers, auditors, and regulators a common language. Core Concepts Behind the NIST AI RMF 1.0 Defining AI Risk The framework defines risk as the composite measure of an event’s probability of occurring and the magnitude of its consequences. Two things distinguish the AI RMF’s treatment of risk from older frameworks. It explicitly considers positive impacts as well as harms, framing risk management as a way to maximize benefits, not just avoid downsides. And it acknowledges that AI risk is genuinely hard to measure: third-party models, emergent behavior, and a lack of agreed metrics mean organizations must often manage risks they cannot precisely quantify. Characteristics of Trustworthy AI Systems The AI RMF defines seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Validity and reliability is described as a necessary precondition for all the others, since an inaccurate system cannot be meaningfully safe or fair. The framework is candid that these characteristics involve trade-offs. Improving explainability can reduce accuracy, and strengthening privacy can limit the data available for bias testing. Managing those tensions is a governance decision, not a technical one. Framing Risks: Harms to People, Organizations, and Ecosystems The framework organizes potential harm into three groups. Harm to people covers individual civil liberties, physical and psychological safety, and economic opportunity, as well as harm to communities and society at large. Harm to organizations covers business disruption, security breaches, financial loss, and reputational damage. Harm to ecosystems covers damage to interconnected systems, including the global financial system, supply chains, and natural resources. This breadth is deliberate. It forces impact assessments to look beyond the deploying organization’s own balance
Every defense contractor that handles Controlled Unclassified Information (CUI) has a number attached to its CAGE code in a DoD database. That number ranges from -203 to a perfect 110 and most organizations that calculate it honestly for the first time land somewhere they would rather not advertise. This guide covers how CMMC scoring works: where the number comes from, what counts as a passing score at each CMMC level, how to calculate and submit a score in SPRS, and where Plans of Action and Milestones (POA&Ms) fit in. What Is CMMC Scoring? CMMC 2.0 is the Department of Defense program for verifying that companies in the Defense Industrial Base (DIB) actually protect Federal Contract Information (FCI) and CUI, rather than simply attesting that they do. The program rule, 32 CFR Part 170, took effect in December 2024, and the acquisition rule that inserts CMMC requirements into contracts via DFARS 252.204-7021 began phasing in from November 2025. Phase 2, which makes third-party certification the default for contracts involving CUI, arrives in November 2026. CMMC scoring is the quantitative layer underneath all of this. At Level 2, the score measures implementation of the 110 security requirements of NIST SP 800-171, the standard that has applied to contractors handling CUI since DFARS 252.204-7012 made it mandatory. CMMC did not invent new controls at Level 2; it created a verification and scoring regime around controls contractors were already obligated to implement. The score matters for three practical reasons. It determines contract eligibility, because solicitations now specify a required CMMC status and contracting officers check SPRS before award. It drives prime contractor flow-downs, since primes must verify subcontractor scores before passing CUI down the supply chain. And it creates legal exposure: a senior official affirms the score, and a knowingly inflated number is a False Claims Act problem, not a paperwork problem. Understanding the SPRS Scoring System The Supplier Performance Risk System (SPRS) is the DoD’s authoritative source for supplier risk information. For cybersecurity purposes, it stores the results of NIST SP 800-171 assessments and CMMC statuses against each contractor’s CAGE code. Contracting officers, programme offices, and DCMA personnel query it routinely; prime contractors can verify that a subcontractor has a current assessment on file. SPRS does not perform the assessment. It is a reporting database. Self-assessment scores are entered directly by the contractor through the Procurement Integrated Enterprise Environment (PIEE). Results of third-party certification assessments are entered by the C3PAO into the CMMC instance of eMASS, which then populates SPRS automatically. The relationship between an SPRS score and CMMC certification is straightforward: same methodology, different assessor. The self-assessment score is your own claim about your posture. A CMMC Level 2 certification is the same 110 requirements scored by a Certified Third-Party Assessment Organization (C3PAO), with the result carrying formal status under the programme rule. A contractor whose self-reported 110 collapses to 60 under C3PAO scrutiny has a credibility problem on the record. The CMMC Scoring Methodology Explained The methodology comes from the NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1, now codified for CMMC in 32 CFR 170.24. Every organisation starts at the maximum of 110 points. For every requirement scored NOT MET, a weighted value of 1, 3, or 5 points is subtracted. The weighting reflects security impact. Five-point requirements are those whose absence exposes the network or CUI directly. Three-point requirements have a specific, meaningful effect on security. One-point requirements have a limited or indirect effect. Because total possible deductions add up to 313, the floor is -203. Negative scores are common on a first honest assessment, and they are not a clerical curiosity: a deeply negative number visible to a contracting officer signals an organisation years away from certification. There is no partial credit. A requirement that is 90 percent implemented deducts its full point value, exactly like one that was never started. The only two exceptions are multi-factor authentication (3.5.3), which deducts 3 points instead of 5 if MFA covers remote and privileged users but not all users, and FIPS-validated encryption (3.13.11), which deducts 3 points instead of 5 if encryption is in place but not FIPS-validated. Everything else is binary. One further prerequisite catches people out: a System Security Plan (3.12.4) must exist at the time of assessment. Without an SSP describing how each requirement is met, the assessment cannot be completed at all, and the absence is treated as non-compliance with DFARS 252.204-7012 rather than as a scoring deduction. CMMC Score Requirements by Level Scoring works differently at each of the three CMMC levels, and the term passing score means something different at each. Level 1 Level 1 sits apart from both Level 2 and Level 3: it requires an annual self-assessment of just 15 basic safeguarding requirements, carries no numeric score, permits no POA&Ms, and requires only an annual affirmation. There is no minimum number to hit because the assessment is pass/fail on each individual requirement. Level 2 At Level 2, the 110-point methodology applies in full. A score of 110 earns Final Level 2 status. A score of at least 88, where every unmet requirement is POA&M-eligible under 32 CFR 170.21, earns Conditional Level 2 status — but only as a temporary bridge to the full 110. At Level 3 Level 3, the bar rises further: organizations must first hold Final Level 2 status from a C3PAO assessment, then undergo a DIBCAC-led assessment against the 24 enhanced requirements drawn from NIST SP 800-172 requirements, each worth a single point. The Level 2 thresholds deserve emphasis because they are widely misread. A score of 88 does not mean you passed. It means you are eligible for Conditional Level 2 status, and only if every unmet requirement is one the rule allows on a POA&M. Conditional status starts a 180-day clock. Final Level 2 status requires the full 110, achieved either at the initial assessment or at the POA&M closeout assessment. How to Calculate Your CMMC Score The most reliable way to calculate your score is
Most companies pursuing ISO 27001 certification cost analysis for the first time will spend between $10,000 and $50,000 in year one, and far less than half of that goes to the auditor. A 50-person SaaS company typically pays $10,000 to $22,000 in certification body fees alone, then doubles or triples that figure in implementation work, tooling, and internal hours before the Stage 2 audit even begins. The wide range exists because ISO 27001 certification cost is not a price tag; it is the sum of a dozen separate decisions: your scope, your security maturity, your certification body, and whether you build the ISMS yourself, hire a consultant, or run it through a compliance automation platform. This article breaks down every one of those costs, stage by stage and region by region, including the ones that never appear in vendor quotes. What Determines ISO 27001 Certification Cost? Six variables drive almost all of the variance between a $10,000 certification and a $150,000 one. Company Size and Employee Count Headcount is the single biggest cost driver because certification bodies calculate audit days (mandays) primarily based on the number of people working within the scope of your Information Security Management System (ISMS). The calculation is not arbitrary: accredited bodies follow the audit time tables in ISO/IEC 27006, which means a 20-person company and a 200-person company will receive structurally different quotes no matter how hard they negotiate. More employees also means more interviews, more evidence sampling, and more Annex A controls applied across more people. Scope and Complexity of the ISMS Scope is the variable you actually control. Your Statement of Scope defines which business units, systems, products, and locations fall inside the ISMS. A scope limited to one product line and the engineering team that runs it costs dramatically less to implement and audit than a whole-of-company scope. Complexity compounds this: bespoke infrastructure, regulated data types, and heavy third-party dependency chains all add controls, evidence, and audit time. Number of Physical and Cloud Locations Each physical site within scope can require its own audit visit, with travel costs on top. Multi-site organisations can reduce this through sampling (more on the square root rule later), but every additional location still adds something. Cloud environments count too: multiple cloud providers, regions, and tenancy models expand the technical scope auditors must cover, even when no travel is involved. Existing Security Maturity A company that already runs access reviews, maintains an asset inventory, and documents its incident response process is buying a much shorter journey than one starting from a blank page. The gap analysis exists precisely to price this difference. Organisations already aligned to SOC 2, NIST CSF, or Cyber Essentials Plus typically reuse 50 to 70 percent of their existing controls and evidence, which translates directly into lower implementation cost. Choice of Certification Body Certification bodies are not interchangeable on price. Large international names like BSI, Bureau Veritas, LRQA, and DNV charge premium day rates, often 30 to 50 percent above smaller accredited bodies, and their brand carries weight with enterprise procurement teams. What matters most is accreditation: a certificate issued by a body accredited by UKAS, ANAB, or another IAF (International Accreditation Forum) member carries international recognition. An unaccredited certificate is cheaper and close to worthless in serious sales conversations. Internal vs. External Implementation Approach The final driver is who does the work. Internal teams cost salary hours. Consultants cost fees. Platforms cost subscriptions. Each approach lands at a very different total, which is why this article dedicates a full section to it below. Average ISO 27001 Certification Cost Ranges The ranges below cover total first-year cost: implementation, tooling, and certification audits combined. They assume an accredited certification body and a sensibly defined scope. Cost for Small Businesses and Startups (1–50 Employees) A focused startup with a single product, cloud-native infrastructure, and a tight scope can realistically certify for $10,000 to $35,000 all-in. Lean implementations using templates or an automation platform sit at the bottom of that range. UK micro-businesses can find UKAS-accredited audit fees starting around £6,250, with day rates near £1,250. Cost for Mid-Sized Organizations (50–250 Employees) This is where most certifications happen, and where costs spread widest. Expect 8 to 12 initial audit days, $30,000 to $80,000 in total first-year spend, and a six to nine month timeline. Multiple departments, more mature customer requirements, and the first real multi-team coordination overhead all show up in the budget. Cost for Large Enterprises (250+ Employees) Enterprise certifications routinely exceed $100,000 in year one once you include program management, multiple sites, and large-scale audits. The audit fee alone can pass $50,000 for complex, multi-site scopes. At this scale, the internal time investment, covered under hidden costs below, often outweighs every external invoice. ISO 27001 Cost Breakdown by Stage Here is where the money actually goes, in roughly the order you will spend it. Cost of Purchasing the ISO 27001 Standard The official ISO/IEC 27001:2022 document costs CHF 155 (roughly $170) from the ISO store. Most teams also buy ISO 27002, the implementation guidance for the Annex A controls, for a similar amount. Budget $300 to $400 for both. Do not skip this purchase: implementing against second-hand summaries of the standard is a common source of audit findings. Gap Analysis Costs A consultant-led gap analysis before committing to anything else runs $2,000 to $10,000 depending on scope, while platform-based readiness assessments are often bundled into the subscription. The output, a clear map of where you stand against every clause and control, is what makes the rest of the budget predictable. ISMS Implementation Costs This is the largest and most variable line item: building the risk assessment, the risk treatment plan, the Statement of Applicability (SoA), and operationalizing the controls you have selected. Done internally, it consumes 200 to 600 hours of staff time over four to eight months. Done with consultants, expect $10,000 to $50,000 in fees for a typical SMB. Documentation and Policy Development Costs ISO 27001 requires a defined set of documented
A Vulnerability Assessment and Penetration Testing report is the final deliverable where weeks of security testing either turn into action or quietly fade away in a company’s digital archive. The testing finds the holes, and the report decides whether anyone fixes them. Get it wrong, and you have an expensive PDF that satisfies an auditor and protects nobody. Get it right, and you have a prioritised plan that tells your team exactly what to fix first and why it matters, saving you a lot of money in avoided security breaches in the long run. This guide covers what a VAPT report is, what belongs in it, how to write one that holds up under scrutiny, and how it ties into the certifications most businesses actually care about. What Is a VAPT Report? VAPT stands for Vulnerability Assessment and Penetration Testing. The report is the document that captures everything the testing uncovered: the weaknesses, how serious each one is, which an attacker could realistically exploit, and what to do about them. The two halves do different jobs. A vulnerability assessment is broad and largely automated. It scans systems, networks, and applications to produce a prioritised list of known weaknesses, without trying to exploit them. Penetration testing is narrow and manual. A skilled tester takes selected weaknesses and tries to exploit them, chaining flaws together the way a real attacker would, to prove what damage is actually possible. One gives you visibility. The other gives you validation. A strong VAPT report fuses both into a single picture of real risk rather than theoretical exposure. Vulnerability Assessment Penetration Testing Approach Broad, mostly automated scanning Focused, manual exploitation Goal Identify known weaknesses at scale Validate real-world impact Output Prioritised list of weaknesses Exploited findings with proof of concept Answers What might be wrong? What can an attacker actually do? What Is the Objective of a VAPT Report? The objective is not to list vulnerabilities. Any scanner can produce a list. The objective is to turn raw findings into decisions: what to fix, in what order, and how much each issue matters to the business. A good report does three things at once. It gives executives a clear read on risk and the cost of ignoring it. It gives engineers the technical detail and reproduction steps they need to fix each issue. And it creates a point-in-time record proving that testing happened, which auditors, regulators, and customers all ask to see. The same document has to serve a boardroom and a bug queue, which is exactly why structure and audience awareness matter so much. Who Needs a VAPT Report? Almost any organisation that runs internet-facing systems or handles sensitive data benefits from one. Three groups need it most. Organizations Pursuing or Maintaining Compliance This is the most common trigger. Frameworks such as PCI DSS, SOC 2, ISO 27001, and GDPR all expect some form of security testing, and a VAPT report is the cleanest way to evidence it. For regulated businesses, the report is not optional documentation. It is the artefact an assessor reviews to decide whether a control is actually working, and a missing or stale report can stall an entire certification. Organizations of Any Size Size offers no protection. Automated attacks scan the entire internet indiscriminately, and a small company with an exposed admin panel is a softer target than a large enterprise with a mature security team. Regular testing matters most after meaningful change: a new product launch, a cloud migration, an acquisition, or rapid headcount growth. Each of those expands the attack surface faster than most teams update their defences. Clients and Business Partners Increasingly, the report is a sales document. Enterprise buyers send security questionnaires before they sign, and “do you conduct penetration testing, and can we see a summary?” is now a standard line item. A clean, customer-facing summary of a VAPT report shortens sales cycles and builds trust. Its absence becomes a gap that procurement teams probe directly. Worth Knowing: Enterprise Vendor Assessments Enterprise vendor assessments such as SIG and CAIQ routinely ask about penetration testing frequency, findings, and remediation. A polished report you can share on request often does more for a deal than another case study, because it answers a security reviewer’s question before they have to chase you for it. The Anatomy of a VAPT Report: Key Elements Formats vary by tester and by standard, but credible reports share the same seven building blocks. Executive Summary. A non-technical overview for leadership. It states the overall risk posture, the headline findings, and the business impact in plain language. For many executives this is the only section they will read, so it has to stand on its own. Methodology, Scope, and Tools Used. What was tested, what was deliberately excluded, which standards were followed (commonly OWASP, PTES, or NIST Special Publication 800-115), which tools were used, and the dates of the engagement. Scope is what defines the boundary of every claim the report can make. Scan Results and Details of Tests Performed. The summarised output of automated scanning alongside the specific manual tests carried out, giving reviewers a clear view of coverage. Detailed Findings and Vulnerabilities. The core of the document. Each finding gets a description, the affected asset, a severity rating, supporting evidence, and clear reproduction steps so the fix can be verified later. Risk Assessment Profile. Each vulnerability rated by severity, exploitability, and business impact, most often scored with a framework such as the Common Vulnerability Scoring System. This is what lets a team prioritise rationally instead of fixing whatever looks scariest. Remediation Planning and Recommendations. Specific, prioritised, actionable fixes, ideally with suggested timelines and owners. Vague advice like “harden the server” fails here. “Disable TLS 1.0 on these three endpoints” succeeds. Appendices and Supporting Evidence. Screenshots, request and response captures, payloads, proof-of-concept artefacts, and raw scanner output. This is the material that turns assertions into proof. Pro Tip: Writing the Executive Summary Write the executive summary last, and write it for
Vanta does not publish a single price on its website. Every quote is custom, generated after a sales call, and shaped by four variables: your headcount, the number of frameworks you need, the add-ons you select, and how long you commit. The median Vanta contract sits around $20,000 per year based on aggregated procurement-platform data, with the full range running from about $10,000 for a lean startup to $80,000 and beyond for a multi-framework enterprise. There is also one cost that most analyses miss: the actual audit fee, which is not included in the Vanta subscription price. This breakdown covers every tier, every hidden line item, and the levers that actually move the number down. Vanta Pricing at a Glance Vanta sells five named tiers, each aligned to a company stage or GRC maturity level. The figures below come from customer-reported benchmarks aggregated by procurement and price-intelligence platforms such as Vendr and PriceLevel, since no list prices exist publicly. Treat them as ranges, not quotes. The audit, paid to an independent firm, sits on top of all of these and typically adds $10,000 to $50,000 depending on framework and scope. Plan Typical Annual Cost Best For Core ~$10,000 Startups, single framework Plus $15,000–$30,000 Growing teams needing access reviews and questionnaire automation Growth $25,000–$50,000 Scaling companies running multiple frameworks Scale $50,000–$80,000 Formalised GRC or security teams Enterprise $80,000+ Multi-entity, IPO-level, or highly complex environments Reach SOC 2 Compliance in 6 Weeks or Less Get 20% to 30% Off Vanta Through Our Partner Discount Talk to Our Team Vanta Pricing Plans Explained Core Plan: Entry-Level Compliance for Startups Core is the entry point, generally landing around $10,000 per year, with reported deals clustering between roughly $7,500 and $14,000. It covers one framework, usually SOC 2 or ISO 27001, with automated evidence collection, ready-made policy templates, basic integrations, a public-facing Trust Center, and access to Vanta’s network of approved audit firms. Smaller teams pursuing a single framework land at the low end of that range. It is built for the first-time compliance journey, not for running compliance as an ongoing operational function. Plus Plan: Advanced Features for Growing Teams Plus typically runs $15,000 to $30,000 per year. It adds the capabilities Core leaves out: automated access reviews, approval workflows, and a capped allowance of automated security-questionnaire responses, commonly cited at 25 per year. That questionnaire cap is the detail that catches growing teams off guard, and it is covered in the hidden-fees section below. Growth Plan: Built for Scaling GRC Programs Growth, sometimes sold as the Professional tier, ranges from roughly $25,000 to $50,000 per year and is Vanta’s most commonly sold plan for scaling companies. It supports multiple frameworks, advanced integrations, customisable risk-management workflows, custom monitoring tests for non-standard controls, automated access reviews, advanced reporting, and a far larger questionnaire allotment, often cited at 144 per year. This is the tier for organisations treating compliance as a service and a real business function, rather than a one-time checkbox. Scale Plan: Expanded Compliance Coverage Scale pricing starts where Growth tops out and can reach up to $80,000 per year. It is aimed at companies with formalised GRC or security teams, many connected assets, and several frameworks running in parallel. SCIM-based user provisioning and deeper automation across onboarding and offboarding tend to appear at this level. Enterprise Plan: Fully Custom Pricing Enterprise is entirely bespoke, starting above $80,000 and quoted case by case. It bundles a dedicated customer success manager, priority support, custom integrations, and tailored implementation. It becomes relevant for organisations managing multiple legal entities, thousands of assets, strict SLA requirements, or IPO-level scrutiny. Insider note: Vanta’s plan names shift over time and between sales reps. You will see Core called Essentials, and Growth called Professional, in different quotes and on different comparison sites. Anchor your evaluation to what the plan actually includes, frameworks supported, questionnaire allowance, access review automation, rather than the label on the proposal, because the label is the least stable thing about it. How Much Does Vanta Cost Per Year? Annual Cost by Company Size and Stage For a startup under 50 employees chasing a single framework, expect roughly $10,000 to $12,000 per year. Most growing companies pay between $25,000 and $55,000. Larger organisations running multiple frameworks commonly land between $50,000 and $110,000 or more once add-ons and headcount are factored in. The median across all reported deals stays near $20,000, which tells you most buyers sit in the Core-to-Growth band rather than at the extremes. How Pricing Scales With Company Size and Complexity Vanta prices primarily on employee count and framework count. Add an employee bracket, and the per-seat-driven base creeps up. Add a framework, and you pay again for the incremental coverage. Complexity compounds this: more cloud accounts, more vendors to assess, and more integrations all push you toward higher tiers and more add-ons. Two companies of identical headcount can pay very different amounts purely on framework count and the modules they bolt on. How to Negotiate Vanta Pricing Buy Through a Certified Partner Certified partners can frequently pass through discounts of 20 to 40 percent off list on multi-year contracts, alongside faster onboarding and implementation support. As a certified Vanta partner, Axipro secures clients 25% off Vanta pricing, and that discount applies on top of the platform’s standard multi-year terms rather than instead of them. The saving is only part of the value. Axipro folds the licence into a consultant-led compliance program, so you get the negotiated rate plus hands-on implementation, framework scoping, and audit preparation, rather than a cheaper login and a blank dashboard. For a team weighing a $25,000 quote, a quarter off the platform cost covers a meaningful slice of the audit fee that Vanta’s subscription never includes. Negotiate Multi-Year Discounts A two or three-year commitment is the most reliable discount lever. Vanta will trade a lower annual rate for a longer term and committed future growth. If you expect to add headcount or frameworks, name that expansion in the negotiation and
The Vanta agent checks four things on a laptop: whether the disk is encrypted, whether a password manager is installed, whether antivirus is running, and whether the screen locks on its own. That is the entire job. It is a lightweight background program that reports those signals back to Vanta so your compliance evidence stays current without anyone emailing screenshots to an auditor. Most of the confusion around it comes from one of two directions: people expect it to manage their fleet like a full device-management platform, or they worry it reads far more than it does. Neither is true, and the gap between those two assumptions is where this guide lives. What follows covers what the agent collects, what it deliberately ignores, how it talks to the Vanta platform, how it stacks up against a full MDM, and which compliance frameworks the evidence ends up supporting. What Is the Vanta Agent? The Vanta agent is a small program installed on employee computers to continuously confirm that each device meets a short list of security requirements. If you have seen it referred to as the Vanta Device Monitor, that is the same product under an earlier name. The two terms are interchangeable. Under the hood, it runs a hardened build of osquery, an open-source framework that exposes operating system state as a queryable SQL database. Vanta ships a modified version that strips out the tables it considers risky, which is why the agent can read a disk-encryption flag but cannot pull your browser history or SSH keys. It is read-only by design. It inspects configuration and reports back; it never changes a setting on the machine. Vanta positions it primarily for smaller fleets, generally companies running fewer than about 75 devices, where standing up a full management platform would be overkill. What Does the Vanta Agent Do? The agent exists to turn a recurring manual chore — proving that every laptop is configured securely — into something that happens quietly in the background. Continuous Device Monitoring Once installed, the agent keeps tabs on the device’s security posture on an ongoing basis rather than at a single point in time. This matters because audits care about whether a control held throughout the period, not whether it happened to be true the morning someone took a screenshot. Continuous checks caught the laptop with encryption switched off last Tuesday. Automated Compliance Checks Each signal the agent gathers maps to a control your auditor wants evidence for. Instead of chasing employees for proof that their disk is encrypted, the check runs automatically, and the result flows into Vanta as evidence. The work that used to eat days of an onboarding cycle collapses into a background process. Real-Time Security Posture Tracking The findings appear in Vanta as pass or fail states against each requirement, so a security lead can see fleet-wide compliance at a glance. A device that drifts out of compliance surfaces quickly, which shortens the window between a problem appearing and someone noticing it. What Information Does the Vanta Agent Collect? This is the question employees actually care about, and the honest answer is reassuring: the agent collects security configuration, not content. It does not transmit passwords, environment variables, SSH keys, emails, or browsing history. It reads whether protections are switched on, not what you are doing with the machine. Insider Note: The reason the agent cannot snoop even if someone wanted it to is architectural, not a policy promise. Vanta deploys a modified osquery build that removes the tables capable of reading sensitive content. The dangerous queries are not blocked at the dashboard; they are absent from the binary. That distinction is worth raising directly when an employee pushes back on installation. Operating System and Version Details The agent records the OS and version so Vanta can confirm the device runs a supported, patchable platform. An end-of-life operating system is a control failure in its own right, and this is how it gets flagged. Disk Encryption Status It checks whether full-disk encryption is active — FileVault on macOS and BitLocker on Windows. This is the single most universally required device control across every major framework, which is also why it is the one Linux check the agent does support. Screen Lock and Password Policies The agent verifies that the screen locks automatically after a period of inactivity and that a password or equivalent is required to get back in. An unlocked laptop left on a train is a textbook breach, and this control is the cheapest defense against it. Antivirus and Firewall Status It confirms that antivirus or endpoint protection software is installed and running. The point is not to endorse a particular product but to prove that some recognized protection is active and has not been quietly disabled. Installed Software and Auto-Update Settings To detect the controls above, the agent reads the list of installed applications — for example, to confirm a password manager is present — along with update-related settings. It is reading the inventory to verify protections exist, not building a behavioral profile of the user. How Does the Vanta Agent Work? How the Agent Communicates with the Vanta Platform After installation, the employee registers the device against your Vanta account, which links that machine to its owner. From then on the agent runs its checks locally and sends only the results — the pass or fail signals — up to Vanta over an encrypted connection. The raw system queries stay on the device. What travels is the verdict, not the underlying data. How Often the Vanta Agent Runs Checks The agent uses osquery’s scheduled-query model, meaning each check runs on a recurring interval in the background rather than continuously hammering the system. Results sync to Vanta periodically through the day, and the platform’s tests re-evaluate on a regular cadence so a freshly remediated device clears its failing check without anyone forcing a manual refresh. In practice, a fixed laptop usually shows green within hours, not at the
Roughly 60% of data breaches still trace back to a person rather than a system, according to Verizon’s 2025 Data Breach Investigations Report. Earlier editions of the same report put the figure as high as 74%. That single statistic is why every framework Drata supports — from SOC 2 to HIPAA — treats Drata security awareness training as a required control rather than a nice-to-have. Drata gives you three ways to run that training: automatic tracking across your personnel and recurring resets that keep evidence current for auditors. This guide covers how each piece works, how to configure it, and the quiet mistakes that break compliance. What Is Security Awareness Training in Drata? Security awareness training in Drata is the annual cybersecurity education your workforce completes to satisfy personnel-related controls across frameworks. The control language is consistent across audits: security awareness training is provided to all employees on an annual basis. Drata’s job is to deliver or track that training, then hold the completion evidence in one place so you can show an auditor that every current employee and contractor met the requirement for the current cycle. The discipline itself is well established. The broad concept of security awareness maps to the Protect function (PR.AT) of the NIST Cybersecurity Framework, which treats workforce education as a foundational layer of organizational defense. Inside Drata, training settings live on the Internal Security page, and completion surfaces on the Personnel page and in each person’s My Drata onboarding. Training Methods Available in Drata Drata supports three approaches, and you choose one on the Internal Security page. They differ mainly in who delivers the content and who supplies the completion evidence. Drata Embedded Security Awareness Training (Default) Drata built its own training course that personnel complete directly inside the platform. During onboarding, the employee opens the Complete Security Awareness Training task, clicks Begin Training, and works through the module. On completion, the task flips to completed automatically, and the Personnel page reflects it. No file uploads, no chasing screenshots. This is the simplest route to compliance and the default for most accounts. Connected Training Provider If you already run a training platform, you can connect it so completion data flows into Drata automatically. Drata integrates with providers including KnowBe4, Huntress, and Curricula. Once connected, Drata recognizes that provider as your default training source and pulls completion status for the campaigns you select. For each person, Drata combines campaign selection, enrollment, and completion status to decide whether they are compliant. Insider Note: Drata only syncs training for individuals who are not yet compliant. Once someone is marked compliant, Drata stops pulling their status from the connected provider, so a later change in that tool won’t accidentally overwrite a green check. The practical consequence: if you need to re-run someone, reset them in Drata first, then let the sync pick them back up. External Training (Evidence Upload) The third option covers training done entirely outside Drata. Here, evidence is uploaded manually — either by the employee through My Drata, or by an admin on their behalf, depending on configuration. Compliance is determined by the presence of valid evidence — a certificate, screenshot, or other file — for each current person. How to Configure Security Awareness Training in Drata Where to Find Security Awareness Training Settings All training configuration lives in one place. Select your account from the bottom-left navigation, open Settings, then Internal Security. Only account administrators can access this section. The Security Awareness Training section is where you choose your method. If HIPAA or an AI-related framework is enabled on your account, additional training sections appear below it. Setting Up Security Awareness Training for All Personnel Under the Security Awareness Training section, select the radio button for your chosen method — embedded, a connected provider, or external upload — then save. That setting applies to all personnel going forward, and new hires see the corresponding task in their onboarding automatically. Assigning Training to Individual Personnel Most configuration is account-wide, but you manage individuals from the Personnel page. Select a person to open their detail drawer, where you can view their training status and, for the external method, view or upload evidence on their behalf. This is also where you handle one-off resets, covered further below. HIPAA Training in Drata (If Enabled) What Is Annual HIPAA Training in Drata? The HIPAA Security Rule requires covered entities to implement a security awareness and training program for their entire workforce — a standard codified at 45 CFR 164.308(a)(5). If you have purchased the HIPAA framework in Drata, a dedicated HIPAA Training section appears on the Internal Security page so you can track this separately from general security awareness. Personnel complete it annually to address the associated control. How to Configure HIPAA Training With HIPAA enabled, the HIPAA Training section offers four options: Drata’s embedded HIPAA training, a connected provider, external training with manual evidence upload by an admin or information security lead, or opting out if HIPAA training is not required for your personnel. Select one and save. If you opt out, Drata removes all references to HIPAA training from the interface. Compliance is based on valid evidence existing for each current employee or contractor. AI Awareness Training in Drata What Is AI Awareness Training? AI awareness training covers responsible and secure use of AI tools, and it maps to newer governance frameworks. Personnel should complete it annually to satisfy requirements in frameworks such as the NIST AI Risk Management Framework and ISO 42001. The setting only appears on your Internal Security page when a related framework is enabled on your account. How to Configure AI Awareness Training The AI Awareness Training section offers four options that mirror the others: Drata’s embedded AI training, a connected provider, external training with manual upload, or a URL that links personnel straight to an external course from My Drata. With the embedded option, Drata generates a certificate of completion as a PDF and uploads it automatically, viewable from the
The identity and access management market will pass $25 billion in 2026, and it is crowded with vendors that all make the same promise: the right people get the right access to the right resources at the right time. The hard part of any IAM solutions comparison is not finding capable products. It is that the leading platforms were each built to solve a different problem first, then expanded outward. Okta started with access. SailPoint started with governance. CyberArk started with privilege. Choose by brand reputation alone, and you risk buying a governance tool to solve an access problem, or paying enterprise prices for capabilities a mid-market team will never switch on. This guide compares the major providers by what they are actually good at, then walks through how to match one to your environment. What Is an IAM Solution? An IAM solution is the set of technologies that manages digital identities and controls what each identity can access. NIST frames the goal simply: ensure the right people and things have the right access to the right resources at the right time. In practice, that breaks into a few core functions: authenticating users (proving they are who they claim), authorizing them (deciding what they may do), and administering the account lifecycle as people join, move, and leave. The category splits into recognizable disciplines. Access management (AM) handles authentication and single sign-on. Identity governance and administration (IGA) handles who should have access and proves it to auditors. Privileged access management (PAM) protects the high-value accounts that can change infrastructure or read sensitive data. Most vendors now sell across these lines, but few are equally strong in all of them. That gap is the whole reason a comparison is worth doing. Why Comparing IAM Solutions Matters in 2026 Identity is now the primary attack surface. Stolen credentials and phishing remain among the top routes attackers use to get inside, which is why identity spending keeps climbing even when other security budgets flatten. The IAM market reached roughly $22 billion in 2025 and is on track for about $25 billion in 2026, growing near 15 percent a year, according to Fortune Business Insights. Two shifts make the comparison harder than it was a few years ago. First, the workforce went hybrid and cloud-first, so identity has to span on-prem systems, SaaS, and multi-cloud at once. Second, machine identities exploded. Your choice of platform now locks in how well you can govern not just employees but the service accounts, tokens, and AI agents multiplying across your environment. Gartner has reported that roughly 48 percent of organizations still lack a written IAM strategy — a serious problem, because a comparison is worth little if it is not anchored to documented requirements. Vendor demos are designed to make every product look like the obvious answer. Key Criteria for Comparing IAM Solutions A useful comparison rests on a consistent scorecard rather than the feature checklists vendors supply. The criteria below are the ones that tend to decide satisfaction two years after purchase. Core Identity and Access Capabilities Start with the fundamentals: single sign-on, multi-factor authentication, lifecycle provisioning and deprovisioning, and access certification. The differentiator in 2026 is adaptive, risk-based authentication that weighs device, location, and behavior before granting access, alongside phishing-resistant methods such as passkeys. A tool that only does password-plus-OTP is already behind. Deployment Options: Cloud-Native, Hybrid, and On-Premises Deployment model shapes cost, speed, and control. Cloud-native SaaS platforms deploy fastest and shift maintenance to the vendor. On-prem suits organizations with strict data-residency rules or deep legacy systems. Hybrid is the common reality, and the question to ask is how gracefully a platform bridges old and new — not whether it claims to. Integration Capabilities with Existing Infrastructure An IAM platform is only as good as its connectors. Look for prebuilt integrations with your core systems, directory services, HR platforms, and major SaaS apps, plus open standards support: SAML, OIDC, SCIM, and increasingly standards for continuous authorization. A thin connector catalog means custom engineering, which is where budgets quietly disappear. Scalability for Enterprise vs. Mid-Market Organizations Scale is not only user count. It is the number of applications, directories, and identity types a platform can govern without performance or administrative strain. Enterprise suites assume a dedicated identity team. Mid-market tools assume a stretched IT generalist. Buying the wrong tier means either paying for unused complexity or hitting a ceiling within two years. Pricing Models and Total Cost of Ownership Headline per-user pricing rarely reflects real cost. Implementation, professional services, connector licensing, premium support, and the internal staff time to run the platform often exceed the subscription itself. Compliance and Audit Support For regulated industries, audit support is a core feature, not a bonus. Strong platforms run access certification campaigns, segregation-of-duties checks, and audit-ready reports aligned with frameworks such as SOX, HIPAA, ISO 27001, and PCI DSS. The NIST Digital Identity Guidelines (SP 800-63, revised in 2025) are a useful reference for the assurance levels your authentication should meet. Vendor Support, Stability, and Roadmap You are buying a multi-year relationship. Financial stability, support quality, and a credible roadmap matter as much as today’s feature set, especially as the market consolidates and converges. A vendor that gets acquired or pivots can leave you maintaining a product on a slow decline. Pro Tip: Comparing Quotes When you compare quotes, normalize them to a three-year total cost of ownership that includes implementation and at least one major version upgrade. Vendors that look cheap per seat sometimes carry the heaviest services bill, and the gap usually shows up in year one, not at signing. IAM Solutions Compared: The Leading Providers The vendors below dominate enterprise shortlists. Each entry notes the problem the platform solves best — which is the most reliable way to read past the marketing. Okta Workforce Identity Cloud Okta is the largest independent identity vendor and was named a Leader in the 2025 Gartner Magic Quadrant for Access Management for the ninth straight year. Its strength is breadth of
Researchers who buy second-hand drives off online marketplaces keep finding the same thing: live data. A widely cited study by Blancco Technology Group found that 42% of used drives sold on eBay still held recoverable information, including financial records and personal data the previous owners assumed was long gone. The drives were not hacked; they were thrown away by organizations that treated deleting a file as the same thing as destroying it. Secure data disposal is where many compliance programs fail. ISO 27001, SOC 2, and GDPR all demand it, but they describe it in different languages, enforce it through different mechanisms, and punish failure in very different ways. This article sets out what each framework requires, where the requirements overlap, and how to run a single disposal program that satisfies all three at once. Why Secure Data Disposal Matters Across Compliance Frameworks Disposal is the last link in the data lifecycle, and the easiest one to skip. An organization can run flawless access controls, encryption, and monitoring for years and still cause a reportable breach the moment one unwiped laptop leaves the building. A recoverable drive in a recycling skip is functionally identical to an open database on the internet, and auditors and regulators know it. Most disposal failures are unforced errors: a control that was already written into policy but never carried through to the actual hardware. The gap between having a disposal policy and proving this specific drive was destroyed is exactly where audits and breach investigations live. Defining Secure Data Disposal: Key Terms and Concepts What Is Secure Data Disposal? Secure data disposal is the end-to-end process of removing data and the equipment that holds it from active use, in a way that prevents its recovery. It covers the full lifecycle end: deletion of data while a system is still live, sanitisation of media that will be reused, physical destruction of media that will not, and the safe handling of equipment that is recycled, returned to a lessor, or sold. Disposal is the goal. The methods are how you get there. What Is Secure Data Destruction? Secure data destruction is the subset of disposal that renders media permanently unusable or its contents mathematically irretrievable. Shredding a drive, pulverising it, incinerating it, or destroying the encryption keys that make an encrypted disk readable are all forms of destruction. Destruction is one route to disposal, and it is the right route when the data is highly sensitive, or the media will never be reused. Secure Data Disposal vs. Secure Data Destruction: What Is the Difference? The distinction matters more than it looks. Disposal is the outcome you owe to every framework: data gone, unrecoverable, equipment handled appropriately. Destruction is just one of the methods. You can dispose of data without destroying the hardware by sanitising a drive thoroughly enough to reuse it. Confusing the two leads to two classic mistakes: destroying assets that could have been securely wiped and reused, and assuming a quick deletion counts as disposal when it does not. Important: Emptying the recycle bin, formatting a drive, or hitting delete does not dispose of data under any of these frameworks. Standard deletion only removes the pointer to the data; the bits remain until they are overwritten. Every framework discussed here expects the data to be unrecoverable, which is a far higher bar than not visible. What ISO 27001 Requires for Secure Data Disposal ISO/IEC 27001 handles disposal through a small cluster of Annex A controls that auditors read as a single process rather than in isolation. The two controls that do most of the work are 7.14 and 8.10. For a deeper look at how these controls fit into a broader compliance program, see our ISO 27001 implementation guide. ISO 27001 Annex A 7.14: Secure Disposal or Re-Use of Equipment Annex A 7.14 is a physical control. Before any equipment is disposed of or reused, the organisation must check whether it holds information assets or licensed software and ensure those are permanently erased or the media physically destroyed. It applies to servers, laptops, desktops, mobile devices, printers, network gear, and any storage media: if it ever processed information, it is in scope. The control replaces the older 2013 clause 11.2.7 and adds explicit expectations around removing identifying markings and handling end-of-occupancy scenarios. ISO 27001 Control 8.10: Information Deletion Annex A 8.10 is a technological control, and it focuses on the data rather than the box. It requires information stored in systems, devices, or media to be deleted when it is no longer required, and rendered unrecoverable. The cleanest way to keep these straight: 8.10 governs the data while it is in use or reaches its retention limit; 7.14 governs the hardware at end of life. Most retention-driven deletion sits under 8.10; most decommissioning sits under 7.14. ISO 27001 Control 8.12: Data Leakage Prevention and Its Role in Disposal Control 8.12 is rarely filed under disposal, but improperly discarded media is one of the oldest data leakage channels there is. A drive that leaves your control with recoverable data on it is a leak, regardless of how it left. Treating disposal as part of your leakage prevention posture forces the right question at the right time: what could walk out the door on this device, and has it actually been removed? Physical Destruction and Irretrievable Erasure Under ISO 27001 ISO 27001 offers two broad routes: physically destroy media that holds information, or erase and overwrite it so retrieval by a malicious party is precluded. The standard cross-references ISO/IEC 27040 for detailed sanitisation methods. The unifying requirement is that recovery should be impractical, not merely inconvenient. Deletion alone never satisfies this. Overwriting, Full-Disk Encryption, and Other Approved Methods Overwriting user-accessible storage with multiple passes is acceptable for many sensitivity levels. Full-disk encryption changes the economics of disposal entirely: if a device is encrypted from day one and the keys are properly managed, secure disposal can be as simple as destroying the keys, a technique known as
A business continuity plan that has never been tested is, to a SOC 2 auditor, a document and nothing more. The Availability criteria do not award credit for a polished plan sitting in a shared drive. They ask for evidence that you ran the plan, watched it work or fail, recorded what happened, and fixed what broke. That gap — between having a plan and proving it works — is where most availability findings originate. Business continuity plan testing for SOC 2 is the exercise that turns your plan into auditable evidence. It maps directly to Availability criterion A1.3, one of the few SOC 2 controls that explicitly requires you to test something rather than merely document it. This guide covers what counts as a valid test, the test types auditors accept, a step-by-step process, the exact evidence you need, and the mistakes that turn a routine review into a finding. What Is Business Continuity Plan Testing in the Context of SOC 2? Business continuity plan (BCP) testing is the structured validation of whether your organization can keep critical operations running — and restore them within defined targets — during a disruption. In a SOC 2 context, the testing is not freeform. It must produce dated, traceable evidence that the recovery procedures in your plan actually work, that the people involved know their roles, and that systems and data come back within your stated recovery objectives. Why SOC 2 Requires Business Continuity Plan Testing SOC 2 is an attestation against the AICPA’s Trust Services Criteria, and the Availability category exists specifically for organizations that make uptime or resilience commitments to customers. A plan you never exercise cannot demonstrate operating effectiveness over the audit period — which is the entire point of a Type 2 examination. Testing is the control that converts a static plan into a recurring, observable activity an auditor can sample. SOC 2 Trust Services Criteria and BCP Testing Requirements Availability is one of the five Trust Services Criteria, and it is optional, included only when your service commitments warrant it. When in scope, it is built around three sub-criteria: A1.1 addresses capacity management. A1.2 addresses recovery infrastructure and backup processes. A1.3 addresses the testing of recovery procedures. BCP testing lives squarely in A1.3, with A1.2 supplying the backups and infrastructure that the test validates. Availability Criteria A1.2 and A1.3 Explained Per the AICPA’s Trust Services Criteria, A1.2 requires the entity to design, implement, operate, and monitor environmental protections, recovery infrastructure, and data backup processes that meet its availability objectives. In plain terms: you need real backups, stored away from production, with recovery infrastructure ready to use. A1.3 then requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. The two work as a pair: A1.2 builds the capability, A1.3 proves it functions. Important: The most common A1.3 gap is not a missing test. It is a test that never validated the recovery objectives. Teams run a tabletop, write “no issues found,” and move on — but the plan claims a 4-hour RTO that no one ever measured against an actual restore. If your plan states recovery targets, your test evidence must show whether you met them. A test that does not measure against your RTO and RPO leaves the most important question unanswered. What Auditors Look for During a BCP Test Review Auditors want proof that the test happened, proof that it was meaningful, and proof that it led somewhere. Concretely, that means a test plan with a defined scenario, a dated record of execution with participants, results measured against your recovery objectives, a list of gaps or issues found, and evidence that those issues were remediated. A test that finds nothing and changes nothing is treated with suspicion — because real tests almost always surface something. Types of Business Continuity Plan Tests Accepted for SOC 2 SOC 2 does not mandate a specific test type. It expects the rigor of the test to match the criticality of what you are protecting. The four common approaches sit on a spectrum from low-effort, low-disruption to high-effort, high-assurance. Tabletop Exercises A tabletop exercise is a facilitated discussion where key personnel talk through a disruption scenario and their responses. It is cheap, fast, and excellent for confirming that people understand their roles and that the plan reads coherently. Its limit is obvious: nobody actually recovers anything. For many organizations a tabletop is a legitimate annual test, especially in the first audit cycle, but auditors expect more rigor as a program matures. Walkthrough and Simulation Tests A simulation applies a specific scenario and asks the team to perform recovery actions, not just describe them. It is more involved than a tabletop and far better at exposing the gaps that only appear when people touch the tools. Simulations are where teams discover that a runbook references a system that was decommissioned, or that the on-call engineer lacks the access the plan assumes. Full Interruption Tests A full interruption test shuts down primary systems and shifts operations entirely to the recovery environment. It is the most comprehensive validation available and the only one that proves your failover genuinely works end to end. It also carries real operational risk, so it demands thorough planning and is usually reserved for mature programs and the most critical systems. Parallel Testing Parallel testing activates recovery systems alongside production without taking the primary offline, then compares the two to confirm the recovery environment performs as expected. It delivers much of the assurance of a full interruption test while sparing the business the disruption. For most SaaS and cloud-hosted services, parallel testing of failover and restore is the sweet spot between confidence and risk. How to Test Your Business Continuity Plan for SOC 2 Compliance The sequence below aligns with the contingency planning process in NIST’s Contingency Planning Guide, SP 800-34, which auditors widely treat as authoritative for resilience practices. Each step produces an artifact, and the artifacts together form
A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.
HIPAA and GDPR are the two most consequential data protection frameworks any healthcare or technology organisation is likely to encounter. They share a common purpose, protecting sensitive personal data, but they differ significantly in scope, enforcement mechanisms, and compliance obligations. For organisations operating across the Atlantic, understanding where they align, where they clash, and how to satisfy both simultaneously is not optional. It is a legal necessity. What Is HIPAA? The Health Insurance Portability and Accountability Act was enacted by the U.S. Congress in 1996. Its original purpose was to modernise the flow of healthcare information and ensure the portability of health insurance coverage. Over time, it became primarily known for its data protection requirements, administered by the U.S. Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR). HIPAA is built around three core rules. The Privacy Rule governs how Protected Health Information (PHI) may be used and disclosed. The Security Rule sets standards for safeguarding electronic PHI (ePHI). The Breach Notification Rule establishes mandatory reporting timelines when PHI is compromised. Who Needs to Be HIPAA Compliant? HIPAA applies to covered entities, healthcare providers, health plans, and healthcare clearinghouses, and to their business associates: any third-party organisation that handles PHI on their behalf. If you build software that processes patient data for a U.S. hospital, you are a business associate. If you store medical records in the cloud for an insurance company, you are a business associate. A Business Associate Agreement (BAA) is the formal contract that governs this relationship. What Types of Data Does HIPAA Protect? HIPAA protects Protected Health Information (PHI): any individually identifiable information relating to a person’s past, present, or future physical or mental health condition, the provision of healthcare, or the payment for healthcare. This includes names, dates of birth, Social Security numbers, medical record numbers, and any data that could be used to identify a patient in connection with their health. Electronic PHI, the subset stored or transmitted digitally, is subject to the Security Rule’s additional technical requirements. What Is GDPR? The General Data Protection Regulation came into force across the European Union on 25 May 2018, replacing the 1995 Data Protection Directive. It is the world’s most comprehensive data privacy law, and its extraterritorial reach means it extends well beyond Europe’s borders. The GDPR is enforced by national Data Protection Authorities (DPAs) and coordinated at the European level by the European Data Protection Board (EDPB). Unlike HIPAA, GDPR is not sector-specific. It applies to any organisation processing the personal data of EU residents, regardless of industry. Who Needs to Be GDPR Compliant? Any organisation that processes the personal data of individuals located in the European Union, regardless of where the organisation is based. A U.S. hospital treating European patients, a SaaS company offering services to German users, or a health app collecting data from French residents all fall within GDPR’s scope. The regulation applies to both data controllers (organisations that determine how and why data is processed) and data processors (third parties that process data on a controller’s behalf). What Types of Data Does GDPR Protect? GDPR protects all personal data: any information relating to an identified or identifiable natural person. Health data is explicitly designated a special category under GDPR Article 9, commanding heightened protection alongside biometric data, genetic data, racial or ethnic origin, religious beliefs, and sexual orientation. HIPAA vs GDPR: Key Differences at a Glance Feature HIPAA GDPR Jurisdiction United States only EU + extraterritorial reach Sector Healthcare only All sectors Regulatory body HHS / OCR National DPAs / EDPB Data covered PHI only All personal data Consent model Treatment-based exceptions Explicit consent required Breach notification 60 days (proposed: 72 hours) 72 hours Max fine $1.9M per violation category/year €20M or 4% of global turnover DPO required No Sometimes Right to erasure Limited Yes Scope and Geographic Reach HIPAA’s reach is defined by entity type: it applies to covered entities and business associates operating within the United States. Whether a patient holds EU citizenship is irrelevant to HIPAA jurisdiction. What matters is whether the organisation providing care or processing health data operates within the U.S. healthcare system. GDPR’s reach is defined by the location of the data subject, not the organisation. Article 3 of the GDPR gives it explicit extraterritorial effect. If your organisation targets or monitors EU residents, GDPR applies, regardless of where you are headquartered, where your servers are located, or what industry you operate in. Types of Data Protected: Personal Data vs Protected Health Information (PHI) This is the sharpest structural difference between the two frameworks. HIPAA is focused exclusively on health data in the context of healthcare delivery or payment. GDPR covers all personal data, from email addresses and IP addresses to medical records and genetic profiles. Health data under GDPR is a subset of the broader personal data category, not the totality of it. An organisation that is fully HIPAA-compliant may still be in violation of GDPR if it mishandles employee data, marketing data, or website analytics. Legal Basis for Data Processing GDPR requires organisations to identify a valid legal basis before processing any personal data. For health data, that typically means explicit consent or one of the specific derogations in Article 9(2), such as processing necessary for medical diagnosis or the provision of healthcare. This is a meaningful threshold; pre-ticked boxes, bundled consent, or vague terms of service do not meet GDPR’s standard. HIPAA takes a different approach. It permits covered entities to use and disclose PHI for treatment, payment, and healthcare operations without obtaining patient consent. Authorisation is required only in specific circumstances, such as disclosures for marketing purposes or release of psychotherapy notes. Important: GDPR’s explicit consent requirement creates real friction for U.S. healthcare organisations treating EU patients. A hospital cannot rely on its standard HIPAA-compliant intake forms to satisfy GDPR. The legal bases must be documented separately, and consent forms must meet the GDPR’s granularity requirements. Regulatory Authority and Enforcement HHS OCR is