Home / Blog
Axipro Resource Hub
Latest Articles
One in five breached organizations last year traced the incident to shadow AI, and those breaches cost an average of $670,000 more than standard incidents, according to IBM’s 2025 Cost of a Data Breach Report. The worst part is that most of those organizations already ran a CASB, a DLP program, or both. The tools were on, but the traffic still got through. That’s the visibility gap this article is about. AI tool usage tracking isn’t the same problem as SaaS discovery, and the security stack built for the SaaS era misses most of what matters about AI. Below, we break down what tracking actually requires, where CASB and DLP fail, which categories of AI usage slip through, and what a stack that works looks like in 2026. What AI Tool Usage Tracking Actually Means Most teams that say they “track AI usage” mean they can see that someone visited chat.openai.com. That is app discovery, and it answers almost none of the questions a security or governance team actually needs answered. Beyond App Discovery: Tracking Prompts, Data Flows, and Model Interactions Real tracking covers three layers. First, which tools are in use: chatbots, copilots, coding assistants, embedded SaaS features, agents. Second, what data moves: the content of prompts, uploaded files, and pasted context, mapped against data classifications. Third, how models behave in your environment: which endpoints get called, which OAuth grants exist, which agents hold standing permissions. Seeing that an employee opened ChatGPT gets you nowhere. What you actually need to know is whether they pasted a customer contract into a personal account while they were there. The Difference Between Detection, Monitoring, and Continuous Tracking Detection is a point-in-time answer to “what AI is here?” Monitoring watches known tools on an ongoing basis. Continuous tracking is broader: it assumes the inventory changes weekly, correlates identity, data, and endpoint signals over time, and feeds a governance program rather than a one-off report. Frameworks such as the NIST AI Risk Management Framework and ISO 42001 assume the third mode. A discovery scan from last quarter won’t satisfy an auditor, and it certainly won’t slow down an attacker. Why Traditional SaaS Monitoring Falls Short for AI SaaS monitoring was built around a stable premise: an app is a destination with a domain, a login, and an admin console. AI breaks that premise in several ways at once. The risky activity is the content of an interaction, not the visit. The tool often isn’t a destination at all but a feature inside an app you already sanctioned. And increasingly the “user” isn’t a person but an agent acting on delegated credentials. Why CASB Misses Shadow AI Usage The Cloud Access Security Broker sits between users and cloud services to enforce policy, and for classic SaaS governance it still earns its keep. AI has structural blind spots that no amount of tuning can fix. CASBs Were Built for SaaS Apps, Not Model Endpoints A CASB catalog maps domains to applications with risk scores. AI usage doesn’t resolve neatly to a domain. The same api.openai.com endpoint serves a sanctioned enterprise deployment, a developer’s weekend experiment, and a data-leaking browser extension, and the catalog sees one “app”. Meanwhile, new model endpoints, wrappers, and niche AI tools appear faster than any vendor catalog can keep up with. Gartner research from late 2025 found 69% of organizations already suspect or have evidence that employees use prohibited public generative AI tools, catalog or no catalog. Blind Spots in Encrypted API Traffic to LLM Providers Prompt content travels over TLS. Without full TLS inspection, a CASB sees connection metadata: destination, volume, timing. It can’t see that the payload contained source code or patient records. And full TLS inspection is harder than the datasheet implies. Certificate pinning breaks it for many native apps and CLI tools, legal and works-council constraints limit it in the EU, and most organizations carve out broad exemption lists that AI traffic happily rides through. The OAuth and Embedded AI Problem CASBs Can’t See When an employee grants an AI meeting-notes tool access to their calendar and mailbox via OAuth, no proxy is involved at all. The vendor’s servers communicate directly with Microsoft’s or Google’s APIs using a persistent token. The same applies to AI features embedded inside sanctioned SaaS, think Notion AI, Slack AI, or Salesforce Einstein. The CASB sees approved traffic to an approved app, while the AI processing happening inside it, and whichever sub-processor it forwards data to, stays invisible. Personal Accounts and BYO-AI Bypass CASB Proxies Netskope’s 2026 Cloud and Threat Report found that nearly half of employees who use generative AI at work do so through personal accounts. Personal accounts on managed devices are hard enough; personal accounts on personal devices, home networks, and mobile connections never touch the corporate proxy path at all. Tenant restrictions help for a handful of major providers and do nothing for the long tail. Browser-Based and Extension-Delivered AI Escape Network Inspection AI browser extensions read page content and form inputs locally, then exfiltrate via their own backend, often to generic cloud infrastructure that categorizes as “technology” rather than “AI”. From the network’s view, it is routine HTTPS to a CDN. The riskiest interaction, an extension scraping everything an employee views, produces the most boring traffic signature. Insider Note: In AI governance readiness assessments, the OAuth grant review is where clients get the biggest surprise. We routinely find dozens of AI tools holding live mail, calendar, or drive scopes that nobody in IT ever approved, granted by employees who abandoned the tool (and sometimes the company) months earlier. The tokens keep working anyway. Why DLP Fails to Catch Shadow AI Data Exposure DLP has the opposite problem. It can sometimes see content, but it doesn’t understand it, and AI interactions defeat the pattern matching it depends on. Prompt-Based Data Loss Doesn’t Match DLP Signature Patterns DLP fires on signatures: credit card regexes, SSN formats, keyword dictionaries, file fingerprints. Sensitive prompts rarely look like that. “Summarize why we’re losing
Most SOC 2 preparation effort goes into access controls, encryption, and vendor reviews. Then the auditor’s first evidence request arrives, and item one has nothing to do with technology: show us your board charter, your meeting minutes, and proof that your board operates independently from management. That’s CC1.2, and it causes more last-minute scrambling than almost any technical control in the framework. This guide explains what CC1.2 requires, provides a board charter template with sample language that auditors accept, and covers the situation most startups actually face: satisfying the criterion without a traditional board of directors. What Is a SOC 2 Board Charter and Why It Matters for CC1.2 A board charter is a formal document that defines your board’s purpose, composition, authority, meeting procedures, and oversight responsibilities. Outside of compliance, it’s a corporate governance tool and a good idea in general for companies with shareholders. Inside a SOC 2 audit, it’s the primary design evidence for CC1.2, the criterion that asks whether an independent body oversees management and the internal control environment. The charter matters because CC1.2 is one of the few criteria where the control is a document plus behavior. The charter establishes the structure. The auditor then tests whether the structure operates: did the board actually meet, did it review the security program, did it challenge management? A beautifully drafted charter with no meeting minutes behind it fails just as surely as no charter at all. If you’re earlier in your preparation, our complete SOC 2 guide covers how the full audit fits together. Understanding CC1.2: The Board Independence Criterion CC1.2 is part of the Trust Services Criteria published by the AICPA (American Institute of Certified Public Accountants). The criterion requires that the board of directors, in the AICPA’s words, “demonstrates independence from management and exercises oversight” of how internal control is developed and how it performs. That sentence hides two separate tests. Independence means the board isn’t just management wearing a second hat. Active oversight means the board actually reviews and challenges the control environment instead of existing on paper. Plenty of companies pass one and fail the other. How CC1.2 Fits Within the CC1 Control Environment The Common Criteria run from CC1 through CC9, and the CC1 series covers the control environment: the governance and people layer everything else rests on. CC1.1 addresses integrity and ethical values, CC1.2 addresses board independence and oversight, CC1.3 covers organizational structure and reporting lines, CC1.4 covers competence and hiring, and CC1.5 covers accountability. CC1.2 is the layer that makes the other four credible. A code of conduct means little if nobody independent of management ever checks whether leadership follows it. The COSO Principle 2 Connection The Trust Services Criteria are built directly on the COSO Internal Control—Integrated Framework and its 17 principles. CC1.2 maps to COSO Principle 2, which carries four points of focus: the board establishes oversight responsibilities, applies relevant expertise, operates independently of management, and provides oversight of the system of internal control. Those four phrases are worth memorizing, because they’re effectively the outline of a good board charter. Why Auditors Prioritize Board Charter Evidence Auditors test the control environment first because failures there cascade. If governance is weak, every other control claim gets harder to trust: who approved the risk assessment, who reviewed the incident report, who held management accountable when a control slipped? An exception at CC1.2 tells the auditor that nobody independent was watching, and they’ll read the rest of your evidence with that in mind. That’s why board charter requests sit near the top of almost every evidence list. Worth Knowing: Points of Focus Points of focus are not pass/fail requirements. The AICPA describes them as characteristics that assist evaluation, and the 2022 revisions changed points of focus without changing any criteria. In practice, though, they function as the auditor’s mental checklist, so drafting your charter against them is the safest move. What Auditors Actually Look For in a Board Charter Auditors don’t grade prose style. They scan for specific, verifiable commitments. Here’s what they check, roughly in order. Documented Board Independence from Management The charter must state how many members are independent, define what independence means (no operational role, no material financial relationship beyond board compensation or equity), and describe how independence is maintained. “The board includes members independent of management” without a definition is boilerplate; auditors want criteria they can test against actual member profiles. Defined Oversight Responsibilities This is the heart of CC1.2. The charter should explicitly assign the board oversight of internal control, information security, and risk management. If the charter only mentions financial oversight and strategy, it wasn’t written with SOC 2 in mind, and the auditor will notice the gap. Clear Authority and Decision-Making Powers What can the board approve, veto, or demand? Typical provisions include approving the risk management framework, reviewing audit results, approving executive appointments, and requiring management to report on control deficiencies. Authority without teeth reads as decorative. Meeting Cadence and Quorum Requirements The charter should commit to a minimum meeting frequency (quarterly is the common standard) and define a quorum. This clause matters more than founders expect, because it’s the one auditors test directly against your calendar: if the charter says quarterly and you met twice last year, that’s an exception you wrote for yourself. Committee Structures Larger organizations delegate through audit, risk, and compensation committees, each with its own mini-charter. Smaller companies don’t need committees, but if your charter mentions them, they must exist and produce minutes. Never copy a public-company template with a phantom audit committee. Conflict of Interest Provisions A disclosure and recusal process for conflicts, usually paired with an annual attestation. This clause supports the independence claim: independence isn’t a one-time status, it’s maintained through disclosed and managed conflicts. Evidence of Board Member Expertise and Qualifications COSO’s “applies relevant expertise” point of focus means the board should be able to ask probing questions about security and risk, not just finance. Charters increasingly include a skills expectation clause, and
Most Drata reviews are written by Drata’s competitors. Scroll the first page of Google and you’ll find review posts from rival compliance platforms, each one ending with a pitch for their own tool. This one is different, and the bias runs the other way, so let’s put it on the table: Axipro is a Drata Gold Partner, and our consultants configure the platform for clients every week. That means we profit when companies choose Drata. It also means we know exactly where it saves you months, where the invoice grows faster than you planned, and when you should pick something else. This review covers all three. What Is Drata? Drata is a compliance automation platform (the industry calls the category GRC, for governance, risk, and compliance) founded in 2020 in San Diego by Adam Markowitz, Daniel Marashlian, and Troy Markowitz. Its core job: connect to your cloud infrastructure, identity provider, HR system, and code repositories, then continuously test your security controls against frameworks like SOC 2 and ISO 27001, collecting timestamped evidence as it goes. When your auditor shows up, most of the evidence is already packaged. Funding, Valuation, and Market Position Drata has raised $328 million, most recently a $200 million Series C in late 2022 that valued the company at $2 billion. It passed $100 million in annual recurring revenue in early 2025, acquired the trust center platform SafeBase for $250 million the same year, and now serves more than 8,000 customers. In late 2025 it earned a FedRAMP 20x Low Pilot Authorization, which puts it in a small group of compliance platforms cleared through the U.S. government’s modernized FedRAMP review track. Together with Vanta, it’s one of the two platforms almost every compliance buyer shortlists. Who Drata Is Built For The sweet spot is cloud-native companies from seed stage to mid-market: SaaS businesses pursuing their first SOC 2 or ISO 27001, and scaling teams juggling three or four frameworks at once. If your infrastructure lives in AWS, Azure, or GCP and your team uses standard tools like Okta, GitHub, and a mainstream HRIS, Drata’s automation covers a large share of your evidence collection out of the box. The further you drift from that profile (heavy on-prem systems, exotic tooling, air-gapped environments), the more manual work remains. How Drata Works: From Connection to Audit The workflow runs in five stages. First, you connect your tech stack through more than 270 native integrations covering cloud providers, identity, version control, HRIS, MDM, and ticketing. Second, continuous control monitoring kicks in: automated tests run around the clock against your connected systems, checking things like MFA enforcement, encryption settings, and access reviews. Third, automated evidence collection captures timestamped proof each time a test passes, building the evidence library your auditor will draw from. Fourth, when a test fails, remediation workflows and alerts route the issue to an owner through Slack, Jira, or email, with guidance on how to fix it. Fifth, the Audit Hub gives your auditor a scoped login to review evidence directly in the platform instead of trading spreadsheets and screenshots over email. In our client engagements, that last piece cuts back and forth more than any other feature. Auditors ask fewer clarifying questions when they can trace evidence to its source themselves. Drata’s Core Features Reviewed Overview of the Drata platform and compliance management dashboard. Multi-Framework Control Mapping Drata maintains a single control set mapped across every framework you activate. Pass an encryption control once, and it satisfies the corresponding requirements in SOC 2, ISO 27001, and HIPAA simultaneously. For multi-framework programs, this is the feature that pays for the platform. Adding ISO 27001 to an existing SOC 2 program typically starts you at 60 to 80 percent complete rather than zero. The Drata Agent The Drata Agent is a lightweight application installed on employee laptops. It checks device posture: screen lock, disk encryption, password manager, antivirus, OS updates. It reads configuration states, not files, browsing history, or keystrokes. Employees sometimes push back on installing it anyway, which is why we advise clients to communicate what it does and doesn’t see before rollout, not after the first complaint. Companies with an existing MDM like Jamf or Intune can often pull device evidence from that integration instead. Risk Management, Vendor Risk, and the Trust Center The built-in risk register lets you score risks by likelihood and impact and tie them to controls and remediation tasks. Vendor risk management got a genuine upgrade with the August 2025 agentic AI release, which now collects vendor evidence, reviews SOC 2 reports, and drafts risk summaries with far less manual chasing. The Trust Center, built on the acquired SafeBase product, gives you a public page where prospects can review your certifications and policies under NDA. Clients in active enterprise sales cycles tell us it measurably shortens security review, though note it’s a paid add-on at most tiers, not a bundled feature. Policies, Training, and the Rest Drata ships editable policy templates for every major framework, embedded security awareness training with completion tracking, and an API for anything the native integrations miss. The policy templates are a real accelerator for first-time programs, with one caveat we see constantly: teams accept templates wholesale without adapting them, then get flagged in audit when their actual practice doesn’t match their written policy. A template you don’t follow is worse than no template. Supported Compliance Frameworks Drata supports more than 30 frameworks. The ones that matter for most buyers: SOC 2 (Type I and Type II) against the AICPA Trust Services Criteria, ISO 27001, HIPAA (where Drata operationalizes safeguards, since no formal HIPAA certification exists), GDPR under the EU data protection rules, and PCI DSS. Coverage extends to CMMC, NIS2, DORA, FedRAMP, and various NIST standards. You can also build custom frameworks by mapping your own control set, useful for internal standards or customer-specific requirements. What Users Really Say Drata holds a 4.8 out of 5 on G2 across more than 1,100 reviews, the highest score among the
Vanta is worth it for most cloud-native companies chasing their first SOC 2 or ISO 27001. It’s a harder call if you run on-prem infrastructure, have unusual evidence requirements, or a budget that can’t absorb a renewal surprise. That’s the short answer. The longer one comes down to three things: how much of the platform’s automation applies to your stack, what the contract costs by year two, and how much compliance expertise you have in-house. This review draws on Vanta’s 2026 product releases, third-party procurement data, review platforms, and our experience at Axipro as a Vanta partner implementing the platform for clients across SOC 2, ISO 27001, and ISO 42001 engagements. We work inside the tool every week. We also see exactly where it stops working, and a human has to pick up. What Is Vanta? A Quick Overview Vanta is a compliance automation platform that now calls itself an Agentic Trust Platform. It connects to your cloud infrastructure, identity provider, code repositories, HR system, and device fleet, then runs continuous automated tests against the controls your target framework requires. It collects evidence on its own, maps it to controls, and packages the whole thing for your auditor. Vanta at a Glance Founded in 2018, Vanta now serves more than 15,000 customers, from early-stage startups to names like Atlassian, Duolingo, and Icelandair. The platform supports 35+ frameworks, ships 400+ integrations (the deepest library in the category), and runs over 1,400 pre-built automated tests. In 2026, Forrester named Vanta a Leader in The Forrester Wave: Governance, Risk, and Compliance Platforms, Q2 2026, the first time it appeared in the evaluation. Who Vanta Is Built For (Startups, Mid-Market, Enterprise) Startups remain the core market: roughly 58% of Vanta’s G2 reviews come from small businesses, typically SaaS companies that need a SOC 2 report to close their first enterprise deals. Mid-market teams use it to run multiple frameworks off shared evidence. The enterprise push is newer. In March 2026, Vanta shipped an Organizations Center and adaptive business unit scoping, which lets larger companies segment compliance by product, region, or team inside a single workspace instead of duplicating controls across accounts. Frameworks Vanta Supports Coverage includes SOC 2 (Type I and Type II), ISO 27001, ISO 42001 for AI management systems, HIPAA, GDPR, HITRUST, FedRAMP, PCI DSS, and the NIST AI RMF, among 35+ total. The AI governance coverage matters more each quarter: ISO 42001 and NIST AI RMF requests now show up in security questionnaires that had never mentioned AI before 2025. Vanta Key Features Reviewed Overview of the Vanta platform and compliance management dashboard. Continuous Controls Monitoring This is the engine. Vanta’s 1,400+ tests run continuously against AWS, GCP, Azure, Okta, GitHub, and whatever else you’ve connected: are S3 buckets encrypted, is MFA enforced, are background checks done on time, does anyone hold access they shouldn’t? Failing controls get flagged with remediation guidance and SLA tracking, so compliance stops being an annual scramble and turns into something you maintain as you go. Automated Evidence Collection Instead of screenshots and spreadsheet exports, evidence flows in from your integrations and lands on the right controls. Cross-mapping is the underrated part: evidence you collect for SOC 2 gets reused for ISO 27001, HIPAA, or ISO 42001, which is why adding a second framework on Vanta takes weeks rather than months. The Vanta AI Agent (2026 Update) The AI Agent launched in mid-2025 and has moved fast since. In November 2025, Vanta rebuilt it as AI Agent 2.0, the core of the new Agentic Trust Platform, alongside a Risk Graph and Customer Commitments tracking. In March 2026, dedicated agents for compliance, third-party risk, and customer trust workflows. In June 2026, the Vanta Agent for Risk unified internal and vendor risk into one continuously updated view. In practice, the agent scans your program for inconsistencies, drafts policy change summaries for annual reviews, suggests control mappings when you upload policies, validates evidence before audits, and flags questionnaire gaps before they slow a security review. Vanta pitches it as a 24/7 GRC engineer. That’s marketing, but not empty marketing: it takes real hours of tedious work off your plate. Every draft still needs a human review before adoption, and the agent does its best work when a question maps to evidence you already hold. Insider Note: The AI Agent is only as good as its signal. If a large slice of your stack sits outside Vanta’s 400+ integrations, its suggestions shift from precise to generic. Test it against your actual environment during a trial, not a polished demo tenant. Policy, Vendor Risk, and Training Modules Policy templates cover the standard library, with AI-assisted drafting and version tracking. Vendor Risk Management (VRM) is a paid add-on that collects vendor evidence and generates AI risk summaries, feeding the broader third-party risk management picture. Security awareness training is built in, which removes one more standalone tool from the stack. Trust Center and Questionnaire Automation The Trust Center gives you a public page where prospects self-serve your security posture, and questionnaire automation drafts answers to inbound security reviews. Vanta reports automating over 80% of questionnaire responses with up to a 95% acceptance rate and 81% faster review completion. Those are vendor numbers, so apply a discount, but the direction matches what users report. Watch the caps: lower tiers limit automated questionnaires per year, and enterprise sales teams burn through those limits quickly. Access Reviews Access review campaigns pull directly from your identity provider, so quarterly reviews become a guided approval flow instead of a spreadsheet exercise. It’s a strong module; just know it sits in the Plus tier and above, not the entry plan. Vanta Pros and Cons (Honest Breakdown) Pros: Where Vanta Excels The integration library is the deepest in the category, and it shows during onboarding: most tests light up within days for a standard cloud stack. Auditor familiarity is a real, compounding advantage, since most CPA firms know Vanta’s exports and ask fewer clarification questions. Cross-framework evidence reuse
Learn how organizations can use the EU AI Act to build trust, speed up innovation, strengthen procurement, and gain a competitive advantage through effective AI governance. The Biggest Mistake Organizations Make About the EU AI Act When executives hear “EU AI Act,” their first thought is usually: another regulation, another compliance project, another expense. And who could blame them? Between GDPR, DORA, and NIS2, businesses are under real pressure to show they handle technology responsibly. Here’s what most of them miss, though. Complying with the EU AI Act does more than keep you clear of fines. Done well, it becomes a selling point. Companies that treat AI governance as a strategic skill earn customer trust and close enterprise deals faster. That matters because customers, investors, and regulators are asking tougher questions about AI than ever: Can you explain your AI decisions? How do you manage bias? Who’s accountable when something goes wrong? What controls protect sensitive data? The EU AI Act gives you a framework for answering them. When you can show good governance, you satisfy regulators, and you also win over the customers and partners deciding whether to trust you in the first place. That trust is worth real money in the AI era. And good governance doesn’t mean more bureaucracy. It means consistency. With clear ownership, defined risk processes, and transparent documentation, AI projects become easier to run and easier to scale. Teams stop reinventing governance for every new initiative and follow a repeatable framework instead, which speeds up decisions and cuts uncertainty. Companies with mature AI governance are already seeing this play out. They build more customer confidence in their AI products and answer procurement and due diligence requests in days instead of weeks. They run less risk of expensive AI failures or reputational damage, look credible to investors and regulators, and roll out AI consistently across the organization. In a market where trust increasingly drives purchasing decisions, that shows up in revenue. A McKinsey survey on the state of AI found that organizations investing in responsible AI practices are better positioned to capture value as adoption scales. Three Steps to Get Started You don’t need to transform the whole organization at once. Here’s where you can start: First, map your AI environment. Build an inventory of AI systems and know where they’re being used. You can’t govern what you can’t see, and most organizations are surprised by how many AI tools are already in play across teams. Second, spot risk early. Work out which high-risk use cases exist and build governance into the development lifecycle. The EU AI Act classifies systems by risk level, so knowing where your use cases fall tells you exactly how much scrutiny each one needs before it ships. Third, fold governance into existing processes. Add AI governance to your security, privacy, and enterprise risk programs instead of running it as a separate effort. This is where recognized standards like ISO/IEC 42001 pull their weight, giving you a structured management system that slots into what you already have rather than bolting on yet another silo. That’s enough to set your organization up for the long run. The debate around the EU AI Act shouldn’t be about staying on the right side of regulation. It should be about building AI that people trust and that you can actually scale. Organizations that put governance in place now will innovate faster and earn a stronger market reputation while their competitors scramble to catch up. In a few years, the edge will go to the companies that govern AI best, not the ones that use it the most. Is your organization preparing for the EU AI Act? Start by assessing your AI governance maturity and aligning your AI strategy with recognized frameworks like ISO/IEC 42001 and the NIST AI RMF, and turn compliance into a business advantage.
ISO/IEC 27001 certificates nearly doubled in a single year, from 48,671 in 2023 to 96,709 in 2024, according to ISO’s own certification survey. A big share of that jump comes from startups, not enterprises. The reason is simple: buyers stopped taking “we take security seriously” at face value, and a certificate is the fastest way to prove it. This guide covers when a startup should pursue ISO 27001, what it costs, how long it takes, and how a small team gets certified without a dedicated security department. What Is ISO 27001 and Why It Matters for Startups ISO/IEC 27001 is the international standard for information security management. It doesn’t hand you a checklist of firewalls to buy. Instead, it asks you to build and run an Information Security Management System (ISMS): a documented, repeatable way of finding your security risks and doing something about them. Certification means an accredited third party checked that your ISMS works and matches the standard. For a startup, that distinction matters. You’re not being graded on whether you own expensive tools. You’re being graded on whether you can show a system, which is exactly what an enterprise buyer’s procurement team wants to see before they sign. The Core Principles: Confidentiality, Integrity, and Availability Everything in ISO 27001 traces back to the CIA triad: confidentiality, integrity, and availability. Confidentiality means only the right people see the data. Integrity means the data is accurate and hasn’t been tampered with. Availability means the data is there when someone needs it. Every control you put in place, and every risk you assess, ties back to protecting one of those three properties. ISO puts it plainly: an ISMS that meets the standard preserves the confidentiality, integrity, and availability of information by running a risk management process. Keep the triad in mind, and the rest of the framework stops feeling abstract. How ISO 27001 Differs from Other Security Frameworks for Early-Stage Companies SOC 2 is the framework startups usually bump into first, especially when selling into the US. It results in an attestation report from a CPA firm, scoped to specific systems. ISO 27001 is a certification, recognized in over 150 countries, and it covers your whole organization through a formal ISMS with management reviews and company-wide risk assessment. The two overlap heavily. Roughly 70 to 80 percent of the controls line up, so if you do one, the second gets much cheaper. The real difference is structure. SOC 2 checks whether specific controls work. ISO 27001 checks whether you’ve built a management system that keeps those controls working over time. It also aligns closely with GDPR, which is why it travels well in Europe. Insider Note: Auditors can usually tell within an hour whether your ISMS is real or was assembled the week before the audit. A management review meeting with actual notes, decisions, and follow-ups from three months ago is worth more than a perfect-looking policy binder with no evidence anyone ever used it. When Should a Startup Pursue ISO 27001 Certification? The honest answer: when a deal, a market, or an investor is asking for it, or is about to. Certifying purely because it feels responsible is a good way to burn cash and calendar time you don’t have yet. Early-Stage vs. Growth-Stage: Timing the Certification At pre-seed and seed, ISO 27001 is usually early unless you’re selling into regulated industries or the EU from day one. Your product and processes are still shifting, and certifying a moving target means re-documenting everything a quarter later. At Series A and beyond, the math changes. Deals get bigger, buyers get more careful, and investor due diligence starts probing your security posture. Certifying while you’re 15 to 40 people is often the sweet spot: mature enough to have stable processes, small enough that scoping the ISMS is still manageable. When ISO 27001 Might Be Overkill for Your Startup If your customers are US SMBs who only ever ask for SOC 2, leading with ISO 27001 may be solving a problem you don’t have. If you’re pre-revenue and still hunting for product-market fit, your time is better spent shipping. And if no one in your sales pipeline has ever mentioned a certificate, that silence is data. Pro Tip: Pull your Last 20 Security Questionnaires Before you commit, pull your last 20 security questionnaires or RFPs and count how many explicitly asked for ISO 27001 versus SOC 2 versus nothing. That single tally answers the “which framework, and when” question faster than any consultant’s discovery call. Key Benefits of ISO 27001 for Startups Unlocking Enterprise Sales and Bigger Deals The clearest return is revenue you couldn’t touch before. Large buyers often won’t even start a security review without a recognized certificate on file. ISO 27001 gets you past the first gate of enterprise sales, and it shortens the review itself because a big chunk of the questionnaire is already answered by your certification. Building Investor and Board Confidence Certification signals operational maturity. When an investor sees a functioning ISMS, they see a founder who can build systems, not only ship features. That plays well in investor due diligence, where a security gap can stall a term sheet, and it gives your board something concrete to point to on risk. Establishing Customer Trust from Day One A certificate is third-party proof, and third-party proof beats self-assurance every time. For a young company with no brand equity yet, it’s a shortcut to being taken seriously by customers who’ve never heard of you. Creating a Scalable Security Foundation Because ISO 27001 makes you build a system rather than a one-off fix, it scales as you grow. New hires, new products, and new data types slot into an ISMS you already run. You’re not rebuilding security from scratch at every stage. Reducing Long-Term Compliance Costs Adding SOC 2, HIPAA, or ISO 42001 later is far cheaper once an ISMS exists, thanks to that 70 to 80 percent control overlap. The first framework is the expensive one.
Most organizations think their AI governance is further along than it is. McKinsey’s 2026 AI Trust Maturity Survey of roughly 500 organizations found an average maturity score of 2.3 out of 4, and only about a third reported level three or higher in strategy, governance, and agentic AI oversight. Adoption is outpacing control, and regulators have noticed. An AI governance maturity model gives you a way to measure that gap honestly. This guide covers what a maturity model is, the six dimensions it should measure, the five levels most models use, and how to assess your own organization and build a roadmap to the next level. What Is an AI Governance Maturity Model? An AI governance maturity model is a structured framework that describes how capable an organization is at governing its AI systems, usually across five progressive levels. The concept borrows directly from the Capability Maturity Model (CMM) that software engineering has used since the early 1990s: define the capability, describe what it looks like at each stage of development, and score yourself against it. The purpose is diagnosis. A maturity model tells you where governance is strong, where it’s theater, and where it doesn’t exist at all. How It Differs from General AI Governance Frameworks Frameworks like the NIST AI Risk Management Framework or ISO/IEC 42001 tell you what good governance contains: policies, risk assessments, accountability structures, monitoring. A maturity model tells you how well you’re doing those things today. The framework is the destination. The maturity model is the odometer. That distinction matters in practice. Plenty of companies can point to an AI policy document. Far fewer can show that the policy changes what teams actually ship. Why Enterprises Need a Maturity Model Three reasons. First, budget: you can’t prioritize governance investment without knowing which dimension lags. Second, accountability: a maturity score gives boards something concrete to track quarter over quarter. Third, regulation: the EU AI Act and frameworks like ISO 42001 assume a functioning management system, and a maturity assessment is the fastest way to find out whether yours would survive scrutiny. Core Dimensions of an AI Governance Maturity Model A useful model measures more than policy coverage. Six dimensions show up consistently across the credible models, including the IEEE-USA flexible maturity model built on the NIST AI RMF. Strategy and leadership. Does the organization have a stated position on AI risk, an executive owner (increasingly a Chief AI Officer), and board visibility? Gartner’s 2025 polling found 55% of organizations now have an AI board or dedicated oversight committee, which means nearly half still govern by improvisation. Policies, standards, and accountability. Written policies mapped to regulations, a RACI matrix for AI decisions, and clear escalation paths. Many organizations adapt the three lines of defense model from financial risk: the teams building AI, the risk function overseeing them, and internal audit checking both. Data governance and model lifecycle. Training data lineage, quality controls, and lifecycle management from development through deployment, monitoring, and retirement. This is where AI governance meets MLOps, and where mature organizations maintain an AI register, a live inventory of every model and system in production. Risk, compliance, and ethics. Risk classification of AI systems, impact assessments, bias and fairness testing, and explainability requirements. Banks will recognize the DNA of model risk management under SR 11-7 here. People, skills, and culture. Training, role clarity, and whether people outside the governance team actually understand their obligations. Tools, automation, and monitoring. Drift detection, automated policy checks, audit logging, and dashboards. Governance that lives in spreadsheets caps out around level three. The 5 Levels of AI Governance Maturity Level 1: Ad Hoc / Initial AI use happens without oversight. There’s no inventory, no policy, or a policy nobody follows. Shadow AI is common, and risk surfaces only when something breaks publicly. Level 2: Developing / Repeatable Someone has been assigned responsibility. A draft policy exists, a partial inventory exists, and reviews happen for high-profile projects. The practices are repeatable but depend on specific people rather than defined processes. Level 3: Defined / Structured Governance is documented, standardized, and applied across the organization. There’s a governance committee, a risk classification scheme, defined lifecycle gates, and mandatory training. Most organizations pursuing ISO 42001 certification are working to reach and formalize this level. Level 4: Managed / Metrics-Driven Governance produces numbers. Coverage rates, review cycle times, incident counts, and risk reduction are measured and reported to leadership. Controls are enforced by tooling rather than goodwill, and audits confirm the system works as described. Level 5: Optimized / Adaptive Governance improves itself. Monitoring feeds back into policy, controls adapt to new model types (agentic systems being the current test), and the organization anticipates regulatory change rather than reacting to it. Almost nobody is here yet, and that’s fine. Level 5 is a direction, not a deadline. Insider Note: In assessments, the most common self-scoring error is claiming level 3 on the strength of documents alone. If your policy says every model gets a pre-deployment review and your inventory shows 40 models but your review log shows 6, you’re at level 2. Evidence beats paperwork every time, and auditors check the logs first. AI Governance Maturity Matrix The matrix crosses dimensions with levels so you can score each one independently. Organizations are rarely uniform: it’s normal to sit at level 3 on policy and level 1 on monitoring. For scoring, keep the rubric simple: 1 to 5 per dimension, scored on evidence you could show an auditor, not on intentions. Board-level indicators (does the board see AI risk reporting?) and operational indicators (does every production model have a completed impact assessment?) should be scored separately, because they fail independently. How to Assess Your Current AI Governance Maturity Start with a baseline self-assessment. Pull together a cross-functional group covering engineering, legal, risk, security, and the business owners of major AI use cases, and score each dimension against the matrix. Half a day is usually enough for a first pass. For each dimension, the
Most organizations get ISO 42001 certified in 2 to 9 months. Companies that already hold ISO 27001 regularly land in the 2 to 5 month range, while enterprises with sprawling AI portfolios and no existing management system can take 12 months or more. The audit itself only takes days. Almost the entire calendar goes into building and operating your AI Management System (AIMS) long enough to produce evidence an auditor can actually check. That is the short answer. The longer answer depends on your starting point, your scope, and how quickly you can get a certification body on the schedule. This article breaks down the full timeline phase by phase, the factors that stretch or compress it, and what the recertification cycle looks like once you hold the certificate. Typical ISO 42001 Certification Timeline at a Glance ISO/IEC 42001:2023 is the first international standard for AI management systems, published in December 2023. Because it follows the same harmonized structure as ISO 27001 and ISO 9001, the certification process will feel familiar to anyone who has been through a management system audit: build the system, run it, pass a Stage 1 and Stage 2 audit, then maintain it through annual surveillance. Here is how timelines typically break down by company size. Average Timeline for Small Businesses Small companies move fastest because scope stays contained. A startup with two or three AI systems, a handful of decision makers, and short approval chains can finish scoping in a week and get policies signed off in days rather than weeks. The realistic floor for a small business starting from scratch is around 3 months. With an existing ISO 27001 program and a compliance platform already collecting evidence, 2 months is achievable. Average Timeline for Mid-Sized Companies Mid-sized companies usually take 6 to 9 months. The AI inventory is growing, more departments are touching AI systems, and risk assessments have to cover more use cases. Coordination becomes the hidden cost: getting engineering, legal, and product to agree on an AI policy takes longer than writing the policy itself. Average Timeline for Enterprises Enterprises should plan for 9 to 12 months, sometimes longer. The main drivers are AI system sprawl across business units, longer procurement cycles for certification bodies, and audits that take more days. The Stage 2 audit for a large multinational can run two weeks or more on its own, and internal alignment before the audit takes far longer than the audit itself. Breakdown of the ISO 42001 Certification Timeline by Phase The phases below overlap in practice. Treat the durations as effort estimates for a reasonably resourced program, not a strict sequence. Phase 1: Scoping and Gap Analysis (2–4 Weeks) Everything starts with two questions: which AI systems are in scope, and how far is your current governance from what the standard requires? The gap analysis maps your existing policies and controls against the standard’s clauses and Annex A controls, and produces the project plan for everything that follows. Get the scope wrong here and every later phase inherits the mistake. Phase 2: AIMS Design, Leadership, and AI Policy Development (2–4 Weeks) This phase establishes the skeleton of the management system: the AI policy, governance roles, objectives, and the leadership commitments the standard requires. Executive sign-off is the gating item. The documents are not hard to write. Getting senior leadership to formally own AI governance is where programs stall. Phase 3: AI Risk and Impact Assessments (2–6 Weeks) ISO 42001 requires both AI risk assessments and AI impact assessments, and the distinction matters. Risk assessments look at what could go wrong for the organization. Impact assessments look at consequences for individuals and society, which is a newer discipline for most teams. This phase takes longer when you have many AI systems, high-risk use cases, or no prior methodology to adapt. The output feeds directly into your Statement of Applicability (SoA), the document that maps which Annex A controls you have selected and why. Insider Note: Impact assessments are where auditors probe hardest, because they are the most distinctive part of ISO 42001 compared with ISO 27001. A recycled security risk register with “AI” pasted into it will get picked apart in Stage 2. Build the impact assessment methodology properly the first time. Phase 4: Controls Implementation (2–10 Weeks) The longest phase. Here you implement the Annex A controls selected in your SoA: AI system lifecycle documentation, data governance for training data, human oversight mechanisms, transparency measures, supplier management for third-party AI, and so on. Duration depends almost entirely on the gap analysis results. Organizations with mature engineering practices often find they already do much of this and just need to document it. Organizations without formal AI development processes are building from zero. Phase 5: Documentation, Training, and Evidence Collection (2–8 Weeks) Certification requires proof that the system operates, not just that it exists on paper. That means records: training completion logs, risk assessment outputs, review meeting minutes, monitoring reports. This phase runs partly in parallel with implementation, but it cannot be compressed below a certain floor because auditors want to see evidence generated over time, not a folder of documents all created the week before Stage 1. Phase 6: Internal Audit and Management Review (2–4 Weeks) The standard requires an internal audit of the AIMS and a formal management review before the certification audit. This is your dress rehearsal. A good internal audit surfaces nonconformities while they are still cheap to fix. Skipping or rushing it is a false economy that shows up later as Stage 2 findings. Phase 7: Stage 1 Certification Audit (1–2 Weeks) The certification body reviews your documentation and assesses readiness for Stage 2. The audit itself takes 1 to 3 days for most organizations. The auditor examines your scope statement, AI policy, risk and impact assessment methodology, SoA, and internal audit results, then issues findings. The 1–2 week window covers the audit plus the report. Phase 8: Closing Nonconformities (2–4 Weeks) Almost every Stage 1 produces findings.
CMMC requirements started appearing in Department of Defense contracts on November 10, 2025, when the final DFARS rule took effect. By November 10, 2028, the clause at DFARS 252.204-7021 must appear in every solicitation and contract where contractor systems process, store, or transmit Controlled Unclassified Information (CUI). For most of the Defense Industrial Base (DIB), the math is blunt: pass a CMMC assessment or lose eligibility for DoD work. A CMMC readiness assessment is how you find out whether you’d pass before the stakes are real. It’s a structured review of your environment, documentation, and evidence against the requirements of the Cybersecurity Maturity Model Certification, done before you sit for a self-assessment or a Certified Third-Party Assessment Organization (C3PAO) audit. A good one tells you exactly where you stand and what to fix first. This guide covers what a readiness assessment includes, how the process works at each CMMC level, what it costs, how long it takes, and how to pick someone to run one. What Is a CMMC Readiness Assessment? A CMMC readiness assessment is a pre-certification evaluation that measures your organization against the specific requirements of your target CMMC level. It examines your scope, implemented controls, System Security Plan (SSP), Plan of Action and Milestones (POA&M), and the evidence supporting them, then produces a gap analysis and a remediation roadmap. The purpose is simple: surface every deficiency while it’s still cheap to fix. An assessor who finds a scoping error during a readiness review costs you a few weeks of rework. A C3PAO who finds the same error during a certification assessment can cost you the assessment fee, months of delay, and in some cases contract eligibility. How It Differs From an Official C3PAO Audit An official CMMC Level 2 certification assessment is conducted by a C3PAO accredited by the Cyber AB, the official accreditation body for the CMMC ecosystem. The C3PAO’s findings are binding. Results go into the DoD’s assessment systems, and a passing result produces a CMMC status that contracting officers verify before award. A readiness assessment carries no official weight. Nothing gets filed or certified, and a poor result costs you nothing beyond the work needed to fix it. That’s the whole point. It’s the only stage in the entire process where failure is free. There’s also a conflict-of-interest rule worth knowing. A C3PAO cannot provide consulting and remediation services to an organization and then certify that same organization. If a C3PAO helps you prepare, a different C3PAO has to assess you. How It Differs From a Mock Assessment A mock assessment is a dress rehearsal. It simulates the certification assessment itself: assessors interview control owners, request evidence on the spot, and score findings the way a C3PAO would. A readiness assessment is broader and comes earlier, and its job is discovering and closing gaps rather than rehearsing the exam. Most organizations run a readiness assessment first, remediate, then run a mock assessment a few weeks before the real one to see whether staff and evidence hold up under live questioning. How It Differs From a Self-Assessment A self-assessment is a formal CMMC mechanism rather than a preparation exercise. CMMC Level 1 and a subset of Level 2 contracts let organizations self-assess, post the results to the Supplier Performance Risk System (SPRS), and have a senior official affirm compliance annually. That affirmation is a representation to the government, and false or careless affirmations carry False Claims Act exposure. A readiness assessment is the check you run before making that representation, so the number you affirm reflects reality. Why a CMMC Readiness Assessment Matters Avoiding Failed Certification Attempts CMMC Level 2 covers all 110 security controls of NIST SP 800-171, evaluated against 320 assessment objectives. Every objective has to be met for a control to score, and there’s no partial credit. Organizations that skip readiness work routinely walk into certification believing they’re compliant because controls are “mostly” implemented. Mostly implemented scores the same as not implemented. Protecting DoD Contract Eligibility Under the phased rollout that began in November 2025, CMMC status is a condition of award. Prime contractors also have to flow the requirement down to subcontractors that handle Federal Contract Information (FCI) or CUI, and they’ve been pushing their supply chains hard. So a missed certification hurts twice: you lose the immediate contract, and you risk dropping out of a prime’s approved supplier pool during the exact window when those pools are being rebuilt around CMMC status. Reducing Remediation Costs and Delays Gaps found early get fixed on your schedule with your choice of solution. Gaps found during certification get fixed under deadline pressure, often with whatever expensive tooling can be deployed fastest. There’s a conditional CMMC status for organizations that pass with a limited POA&M, but closeout has to happen within 180 days, and only certain lower-weighted controls are POA&M-eligible in the first place. Readiness work keeps you out of that corner. Worth Knowing: The DoD Assessment Methodology The DoD Assessment Methodology weights each NIST SP 800-171 control at 1, 3, or 5 points, deducted from a starting score of 110. The floor is -203. To achieve even a conditional Level 2 status, you need a minimum score of 88. A handful of unmet 5-point controls, such as FIPS-validated encryption or multifactor authentication, can put certification out of reach on their own, so a readiness assessment should always show the point weight attached to every gap. When to Conduct a CMMC Readiness Assessment Before your first self-assessment. If a contract requires a Level 1 or Level 2 self-assessment, run readiness work before you post a score to SPRS. The score you affirm is a legal representation, and it’s far easier to fix the environment than to explain a misstated score later. When contract requirements are approaching. If CMMC language has shown up in a solicitation you plan to bid, or your prime has set a certification deadline, count backward. Remediation after a readiness assessment typically takes six to twelve months for organizations starting
CMMC certification costs between $4,000 and $30,000 at Level 1, $30,000 to $300,000 or more at Level 2, and $100,000 to well over $1 million at Level 3. Most contractors expect the audit fee to be the big number. It isn’t. The formal assessment typically accounts for only 25% to 40% of total spend, with preparation, remediation, and technology upgrades consuming the rest. The stakes changed in late 2025. The final 48 CFR acquisition rule took effect on November 10, 2025, which means CMMC requirements now appear directly in Department of Defense (DoD) solicitations and contracts. Starting in November 2026, Phase 2 of the rollout gives contracting officers the authority to require third-party certification for Level 2 work. If you handle Controlled Unclassified Information (CUI), certification is no longer optional, and the cost question becomes a budgeting exercise rather than a hypothetical. This guide breaks down every major cost category, what moves your number up or down, and how to keep the total under control. What Is CMMC Certification and Why Does Cost Vary? The Cybersecurity Maturity Model Certification (CMMC) is the DoD’s framework for verifying that companies in the Defense Industrial Base (DIB) actually protect the sensitive information they handle. The program, codified in 32 CFR Part 170, builds on the security requirements of NIST SP 800-171 and, at the top tier, selected controls from NIST SP 800-172. Costs vary so widely because you can’t buy CMMC off a shelf. Your environment has to reach a certain state and then stay there. A 15-person machine shop with one well-scoped CUI enclave faces a fundamentally different project than a 500-person prime contractor with CUI flowing through a dozen systems. Your starting security posture, the scope of your assessment boundary, and whether you build internally or hire help all move the total by six figures in either direction. Average CMMC Certification Cost at a Glance The DoD’s own published estimates are instructive. A triennial Level 2 certification assessment, including affirmations, is projected at roughly $105,000 for small entities and $118,000 for larger ones. Those figures cover only assessment and affirmation activities, though. The DoD excludes implementation costs from its estimates on the grounds that NIST SP 800-171 compliance has been contractually required under DFARS 252.204-7012 since 2017. Your real budget has to cover both. CMMC Certification Cost by Level CMMC Level 1 (Foundational) Cost: $5,000 – $30,000 Level 1 covers Federal Contract Information (FCI) and requires 15 basic safeguarding practices drawn from FAR 52.204-21. Because Level 1 permits an annual self-assessment with no third-party auditor, the costs are internal labor, basic tooling, and documentation. Small contractors with reasonable IT hygiene often land near the bottom of the range. The DoD estimates annual Level 1 assessment and affirmation activity at around $6,000 for a small entity, with the remainder of the range driven by any remediation needed to attest honestly. CMMC Level 2 (Advanced) Cost: $50,000 – $300,000+ Level 2 is where most of the DIB lands and where budgets get serious. It requires full implementation of all 110 security requirements in NIST SP 800-171, assessed across 320 individual objectives. For most contracts, a C3PAO (Certified Third-Party Assessor Organization) accredited by the Cyber AB has to conduct the assessment every three years. Market data puts C3PAO assessment fees at $30,000 to $100,000 depending on scope, site count, and complexity. Preparation dwarfs that figure for most organizations. Companies starting from a low maturity baseline routinely spend three to four times the assessment fee on readiness work before an auditor ever shows up. CMMC Level 3 (Expert) Cost: $300,000 – $1,000,000+ Level 3 adds 24 enhanced requirements from NIST SP 800-172 on top of a completed Level 2 certification, and the assessment is conducted by the government’s DIBCAC rather than a commercial C3PAO. DIBCAC charges no assessment fee, but don’t mistake free for cheap. The DoD estimated roughly $41,000 in additional implementation cost for the 800-172 controls alone, and total triennial assessment-related costs in the $146,000 to $159,000 range. Real-world totals run far higher once you account for the advanced tooling, threat hunting capability, and organizational changes Level 3 demands. Only contractors supporting the most sensitive programs need this tier. Worth Knowing: You can’t skip to Level 3. You can’t skip to Level 3. A final Level 2 certification with all POA&M items closed is a prerequisite for the same assessment scope, so Level 3 budgets always include a full Level 2 project first. CMMC Certification Cost Breakdown by Expense Category Gap Assessment and Readiness Planning Costs A gap assessment maps your current environment against NIST SP 800-171 and typically costs $1,500 to $20,000 depending on depth and scope. This is the most valuable dollar you’ll spend in the entire project, because everything downstream is priced off what it finds. Documentation and System Security Plan (SSP) Costs The System Security Plan (SSP) is the cornerstone document of any assessment, mapping every control to your specific implementation. Professionally developed SSPs and supporting policies run $12,000 to $60,000. A weak SSP is one of the most common reasons assessments stall or fail, so this is a poor place to economize. Remediation and Security Control Implementation Costs Closing the gaps is usually the largest line item: $20,000 to $150,000 or more. Multi-factor authentication, logging and SIEM deployment, encryption, access control restructuring, and incident response capability all live here. Organizations with mature security postures spend far less than those starting from scratch. Technology and Infrastructure Upgrade Costs Many contractors move CUI into a dedicated enclave rather than securing their entire network. Enclave platforms typically cost $300 to $400 per user per month. Others upgrade endpoint protection, replace unsupported systems, or migrate to government-grade cloud environments, each with its own licensing and migration costs. C3PAO Assessment and Audit Fees The formal Level 2 assessment runs $30,000 to $100,000, driven by assessor-days, number of sites, and evidence quality. Well-organized evidence directly reduces assessor time and therefore your invoice. Consulting and Advisory Fees Specialist consultants, including Registered Practitioners (RPs) and
After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information
The EU AI Act’s transparency requirements take effect on 2 August 2026, and most of the companies they cover still think the rules are not their problem. Article 50 applies to any business that publishes AI-generated content or runs an AI system that talks to people in the EU. That includes the marketing team generating campaign images and the support team running a chatbot. It also covers the AI agents you’ve wired into customer email. Penalties reach €15 million or 3% of total worldwide annual turnover, whichever is higher, and you don’t need an office in Europe to be in scope. If your content or your chatbot reaches EU users, the obligations reach you. In a nutshell: if you publish AI-generated images or video, deploy chatbots or AI agents that interact with EU users, or publish AI-written text on matters of public interest, then yes, the EU AI Act applies, starting 2 August 2026. A quick word on the “AI Act delay” headlines. The Digital Omnibus package did push the high-risk system deadlines back, in some cases by more than a year, but it did not move the deployer obligations in Article 50. Companies that read those headlines and stood down their AI Act work made an expensive mistake, because the rules most likely to touch an ordinary business are the ones that stayed on the calendar. What Article 50 Actually Requires Article 50 of the AI Act sets out transparency obligations in four situations. In plain English: Tell people when they’re talking to AI. Systems designed to interact directly with people — chatbots, voice assistants, and AI agents — must make clear that the user is dealing with AI, unless that’s already obvious. Mark AI-generated content so machines can detect it. Providers of generative AI systems must mark outputs in a machine-readable format, typically through metadata and watermarking, so the content is detectable as artificially generated. Label deepfakes. Anyone deploying AI to generate or manipulate image, audio, or video content that resembles real people, places, objects, or events, and could falsely appear authentic, must disclose that the content is artificial. Label AI-generated text on matters of public interest. Text published to inform the public must carry a label if AI-generated or manipulated, unless a human reviewed it and a person or organization holds editorial responsibility for it. Article 50 also covers emotion recognition and biometric categorization systems, which carry their own disclosure duties. Far fewer businesses run into those, so this article sticks to the four above. The distinction running through all of this is provider vs deployer. The provider builds or supplies the AI system. The deployer uses it professionally. Most companies reading this are deployers. If You Use AI-Generated Images Realistic AI images sit closer to the deepfake rules than most marketing teams assume. The Act’s definition covers content depicting people, objects, places, and events that could falsely appear authentic to a viewer, which describes a large share of what image generators produce for campaigns, social posts, and landing pages. So what does “clearly and distinguishably labeled” mean? The threshold is best described by its failures: a tiny disclosure hidden in the website footer doesn’t qualify. Neither does a faint label on an image, a label that flashes for an instant in a video, or a disclosure buried in your terms and conditions. The label has to be visible right where someone sees the content, and it has to meet accessibility standards so people with disabilities can perceive it too. The Code of Practice proposes a standardized “AI” visual label, localized per language (“KI” in German, “IA” in French). It also draws a useful line between fully AI-generated content and AI-assisted content, with lighter requirements for the latter. A designer who used AI to extend a background is in a different position from a team publishing a fully synthetic image of a person who doesn’t exist. Important: The deepfake duty doesn’t care about intent. A flattering, harmless AI image of your CEO at an event that never happened is still a deepfake under the Act. Marketing teams generate this kind of content casually. From August, every one of those images needs a label. If You Deploy AI Agents or Chatbots The rule itself is simple: people must know they’re dealing with AI. The provider carries the design obligation, but as the deployer you’re the one putting the system in front of your customers, and you’re the one an EU regulator will contact if your branded assistant pretends to be human. The Act contains an exception for cases where it’s “obvious” the user is talking to AI, judged from the perspective of a reasonably well-informed and observant person. Don’t lean on it. What’s obvious to your product team isn’t obvious to every customer, and the human-sounding voice agents and email-writing AI agents rolling out right now are designed specifically to not feel like software. If an AI agent negotiates a renewal over email or handles a support ticket end to end, disclose it. Pro Tip: Put the Disclosure at the Start of the Interaction Put the disclosure at the start of the interaction, in the interface itself: “You’re chatting with an AI assistant.” A line in your privacy policy doesn’t meet the standard, and a disclosure that appears after the conversation ends is worthless. For voice agents, say it up front in the greeting. What Your AI Vendors Owe You The machine-readable marking obligation in Article 50(2) sits with providers — the companies supplying your generative AI tools. The final Code of Practice expects providers to apply at least two layers of marking where necessary, such as embedded metadata combined with watermarking, and to offer detection mechanisms so deployers, authorities, and researchers can verify whether a piece of content came from AI. One timing caveat: the Digital Omnibus gives generative AI systems already on the market before 2 August 2026 until 2 December 2026 to comply with the marking requirement. Every other Article 50 obligation stays on
Compliance Hubs
Discover key insights, educational articles, helpful guides and more.
The CNIL‘s screening rule sounds simple: hit two of the nine high-risk criteria, and you owe a full Data Protection Impact Assessment (DPIA). The trouble starts when you hit one or none, because the GDPR never says that skipping the DPIA means skipping assessment altogether. Plenty of processing falls outside the CNIL’s screening rules: operations below the two-criteria threshold, activities on the CNIL’s exemption list, processing already covered by an earlier DPIA, and controllers who answer to a different supervisory authority altogether. In every one of those cases, the Article 35 GDPR DPIA obligation may fall away while the risk assessment obligations under Articles 24 and 32 stay exactly where they were. This article maps the scenarios where CNIL criteria don’t apply and what a defensible assessment strategy looks like when they don’t. DPIA vs General Risk Assessment: Core Distinctions Under GDPR These two assessments get conflated constantly, and the mix-up has real consequences. They rest on different legal bases, serve different purposes, and trigger under different conditions. Article 35 GDPR requires a DPIA where processing is “likely to result in a high risk” to people’s rights and freedoms, and it requires the assessment before processing begins. The DPIA looks outward. It evaluates the necessity and proportionality of the processing and the risks it creates for data subjects: discrimination, identity theft, financial loss, reputational damage, loss of control over personal data. The measuring stick throughout is harm to people. Article 32 GDPR requires controllers and processors to put in place technical and organizational measures (TOMs) appropriate to the risk of the processing. You can’t know what’s appropriate without assessing that risk first, so Article 32 carries an implicit risk assessment duty for every processing operation you run, high risk or not. Its focus is security: the confidentiality, integrity, availability, and resilience of the systems handling personal data. Article 24 completes the picture by making the controller responsible for implementing measures proportionate to risk and able to demonstrate compliance. That’s the accountability principle at work. So risk assessment is universal, and the DPIA is the escalated version you reserve for processing that crosses the high-risk line. The real question is which assessment to run and how deep to go. You don’t need a six-figure budget to be GDPR compliant. You need a clear plan and someone to do the work. Affordable GDPR Compliance Services Book a Free GDPR Consultation The CNIL Criteria: A Quick Recap The Article 35(3) Baseline and the 9 Criteria Article 35(3) names three situations where a DPIA is always mandatory: systematic and extensive automated evaluation of individuals, including profiling, with legal or similarly significant effects; large-scale processing of special categories of data (Article 9) or criminal conviction data (Article 10); and large-scale systematic monitoring of a publicly accessible area. Beyond those, the WP29 guidelines on DPIAs (WP248 rev.01), endorsed by the European Data Protection Board (EDPB), list nine criteria that indicate likely high-risk processing: evaluation or scoring, including profiling; automated decision-making with legal or similarly significant effect; systematic monitoring; sensitive data or data of a highly personal nature; processing on a large scale; matching or combining datasets; data concerning vulnerable data subjects (employees, patients, children); innovative use or application of new technological or organizational solutions; and processing that prevents data subjects from exercising a right or using a service or contract. The “Two Criteria” Threshold Rule The CNIL’s position is that processing meeting at least two of the nine criteria requires a DPIA as a general rule. WP248 leaves room on both sides of that line: a controller can conclude that processing meeting two criteria still isn’t high risk, and in some cases a single criterion is enough to trigger the obligation. Either way, the reasoning has to be documented. Where there’s genuine doubt, the CNIL’s advice is simple: do the DPIA. CNIL’s List of Processing Operations Requiring a DPIA The CNIL also maintains a mandatory list under Article 35(4), adopted through Deliberation No. 2018-327 of October 11, 2018. It names 14 types of processing that require a DPIA outright, including systematic employee monitoring, whistleblowing schemes, profiling that can exclude people from a contract, and large-scale processing of health data. If your processing appears on this list, you can skip the criteria math because the DPIA is mandatory regardless. Insider Note: The CNIL’s sectoral “referentials” do more work than most DPOs realize. If your processing fully complies with an applicable referential, the CNIL accepts the position that residual risk isn’t high, which takes Article 36 prior consultation off the table. Checking for a referential before scoping a DPIA can remove the most painful step of the entire process. When CNIL Criteria Don’t Apply: Key Scenarios Processing Falling Below the Two-Criteria Threshold Most B2B processing lives here. A standard CRM, a newsletter list, routine supplier management: these might touch one criterion (large scale, perhaps) without hitting a second. No DPIA is required, but the screening itself is a compliance artifact. Record which criteria you tested, what you concluded, and why. If the CNIL inspects, the absence of a DPIA is defensible only when the screening decision is on paper. Operations on CNIL’s Exemption List Article 35(5) lets supervisory authorities publish “whitelists” of processing that doesn’t require a DPIA. The CNIL adopted one in 2019 after an EDPB opinion, covering categories such as routine HR management in organizations with fewer than 250 employees (without profiling, biometrics, or sensitive data), badge-based physical access control without biometrics, and time management systems that don’t process biometric data. France is one of only a few member states with a formal whitelist, which matters for cross-border groups: the same HR system can be exempt in France and assessable case by case in Luxembourg. Processing Authorized by Specific Legal Provisions Article 35(10) carves out processing based on a legal obligation or public interest task under Article 6(1)(c) or (e), where the legal basis regulates the specific operation and a general impact assessment was already carried out when that law was adopted. It’s a narrow
Only one of these three vendors sells a FedRAMP-authorized identity platform you can buy today as a defense contractor, one sells two of them, and one sells none. Whether that matters for your CMMC Level 2 assessment depends entirely on whether your identity provider stores, processes, or transmits Controlled Unclassified Information (CUI), or provides security protections for the systems that do. That second condition is where most contractors get the analysis wrong. The IdP question is arguably the most argued-about scoping decision in CMMC 2.0 Level 2 preparation, because an identity provider almost never holds CUI directly, yet it controls access to everything that does. This article works through the regulatory requirement, the actual FedRAMP status of JumpCloud, Okta, and Microsoft Entra ID, and how to choose based on your CUI architecture rather than vendor marketing. Understanding the CMMC Level 2 + FedRAMP Requirement What CMMC Level 2 Requires for Cloud Services Handling CUI CMMC 2.0 Level 2 requires contractors to implement the 110 security requirements of NIST SP 800-171 Rev. 2 and, for most contracts, pass a third-party assessment by a Certified Third-Party Assessor Organization (C3PAO). The 48 CFR acquisition rule took effect on November 10, 2025, which means CMMC clauses now appear in new Department of Defense (DoD) solicitations, with third-party assessment requirements expanding through the phased rollout in 2026 and beyond. The cloud piece comes from the CMMC program rule at 32 CFR Part 170. If an Organization Seeking Certification uses a Cloud Service Provider (CSP) to process, store, or transmit CUI, that cloud service offering must be either FedRAMP Authorized at the Moderate baseline or higher or must meet security requirements equivalent to the FedRAMP Moderate baseline. Your C3PAO verifies this during the assessment. If your in-scope CSP fails the test, you fail the assessment. The DFARS 252.204-7012 “FedRAMP Moderate or Equivalent” Clause The requirement predates CMMC. DFARS 252.204-7012 has required since 2016 that any external CSP used to store, process, or transmit covered defense information meet security requirements “equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline.” For years, “equivalent” was undefined, and contractors interpreted it loosely. The DoD CIO closed that door with its December 2023 equivalency memo. To be FedRAMP Moderate Equivalent, a CSP must now demonstrate 100% compliance with the FedRAMP Moderate baseline, validated by a FedRAMP-recognized Third-Party Assessment Organization (3PAO), and hand over a full Body of Evidence to the contractor. No open Plans of Action and Milestones (POA&Ms) against the baseline are permitted. In some ways, it’s stricter than authorization itself, since authorized CSPs are allowed to carry POA&Ms. Important: A vendor telling you they are “NIST 800-171 compliant” or “aligned to FedRAMP controls” does not satisfy DFARS 7012 or the CMMC rule. Either the offering appears on the FedRAMP Marketplace at Moderate or higher, or the vendor gives you a 3PAO-attested Body of Evidence demonstrating full equivalency. Anything else is a gap your C3PAO will find. When an Identity Provider Falls Under This Requirement An IdP is a cloud service. The question is whether it processes, stores, or transmits CUI. In a typical SSO flow, the IdP handles credentials, authentication tokens, session data, and directory attributes. None of that is CUI in most environments. So a literal reading says the FedRAMP mandate doesn’t apply. The complication is the CMMC scoping guidance, which defines Security Protection Assets (SPAs): assets that provide security functions to the CMMC assessment scope even if they never touch CUI. An IdP enforcing multi-factor authentication (MFA), conditional access, and session policy over your CUI enclave is the textbook SPA. SPAs are in scope for your assessment and get evaluated against the relevant NIST SP 800-171 requirements they help satisfy. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Schedule Your Free Assessment Today Schedule A Consultation Does Your Identity Provider Actually Need to Be FedRAMP Authorized? When the IdP Processes, Stores, or Transmits CUI Some architectures do push CUI through the identity layer. If usernames or directory attributes contain CUI (think program names or export-controlled project identifiers), if your IdP proxies application traffic through a gateway that carries CUI payloads, or if CUI-bearing documents get attached to identity workflows, the IdP is now a CSP handling CUI. FedRAMP Moderate or equivalent becomes non-negotiable. When the IdP Provides Security Protections for CUI (SPA Role) This is the common case, and it’s genuinely gray. The FedRAMP requirement in the rule text attaches to CSPs that process, store, or transmit CUI. A pure-play authentication service that does neither is an SPA, not a CUI-handling CSP. Under the final CMMC rule, External Service Providers (ESPs) that handle only Security Protection Data, such as configuration data, logs, and credentials, do not themselves require FedRAMP authorization or a separate CMMC certification. Their services get assessed as part of your assessment. In practice, C3PAOs are not uniform on this. Some accept a well-documented System Security Plan (SSP) showing the IdP never touches CUI. Others take a conservative view that authentication data for CUI systems is sensitive enough that they want FedRAMP-grade assurance behind it, and they will probe hard. DIBCAC’s historical position, given publicly by officials as far back as 2020, is that clouds with management access to CUI systems don’t need FedRAMP unless CUI actually moves into them. That position helps, but you carry the burden of proving CUI never transits the service. Cases Where a Commercial IdP May Be Acceptable A commercial, non-FedRAMP IdP can survive a CMMC Level 2 assessment when all three of the following are true: CUI demonstrably never touches the IdP, the IdP is documented as an SPA with the specific 800-171 requirements it supports, and the data flows in your SSP prove the boundary. This is exactly how many contractors run enclave strategies, keeping a commercial identity stack for the corporate network while the CUI enclave uses its own FedRAMP-authorized identity. The “External Service Provider” (ESP) Classification Under CMMC The final
An AI agent that can read your inbox, query your CRM, and dig through internal documents has more standing access than most of your employees. It handles sensitive data, acts on its own, and often passes that data through sub-processors you’ll never see. Certifications are the quickest way to tell which vendors have let an outsider check their work, and which ones just put the word “secure” on a landing page. No single certificate proves an AI agent is safe. But the right mix of security attestations, privacy certifications, and AI governance standards tells you the vendor has real controls, that an independent auditor has tested them, and that someone is on the hook when the agent misbehaves. This guide covers which certifications to ask for, how to verify them, and which claims should make you walk away. The Core Certifications Every Secure AI Agent Vendor Should Hold SOC 2 Type II SOC 2 Type II is the baseline for any SaaS or AI vendor that handles customer data. A licensed CPA firm audits the vendor against the AICPA’s Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy) and reports on whether its controls actually worked over a review period, usually 3 to 12 months. A Type I report only confirms the controls existed on one particular day. For an AI agent vendor, insist on Type II. Anything less tells you nothing about how the company runs day-to-day. ISO/IEC 27001 ISO/IEC 27001 certifies that the vendor runs a formal information security management system (ISMS): documented risk assessments, defined controls, internal audits, and management review, all verified by an accredited certification body. It’s the most widely recognized security certification outside the US and often a hard procurement requirement in Europe, the UK, and the Gulf. A vendor with international customers should hold it alongside SOC 2, not instead of it. ISO/IEC 27701 (Privacy Information Management) ISO/IEC 27701 extends ISO 27001 with a privacy information management system (PIMS). It maps closely to GDPR concepts like controller and processor obligations, consent, and data subject rights. Almost every AI agent processes personal data at scale, and ISO 27701 is a decent signal that the vendor has built privacy into how it operates instead of delegating it to a policy PDF. ISO/IEC 42001 (AI Management Systems) ISO/IEC 42001 is the first certifiable international standard for AI governance. According to the International Organization for Standardization, it sets out requirements for building and maintaining an AI management system (AIMS): AI risk management, AI system impact assessments, lifecycle management, and oversight of third-party suppliers. For an AI agent vendor, this is the one that covers what SOC 2 and ISO 27001 don’t: how the vendor governs model behavior, training data, and the wider impact of autonomous systems. Worth Knowing: ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Worth Knowing: ISO 42001 Certificates ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Regulatory Frameworks AI Agent Vendors Must Comply With Certifications are voluntary. Regulations aren’t. A credible AI agent vendor should be able to explain, in writing, how it meets
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. 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 tool processes sensitive data, customer personal data, or regulated data; makes or influences consequential decisions (hiring, credit, medical, legal); or operates autonomously
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
Guides and Reports
SOC 2 Hub
All you need to know about SOC 2 compliance
Contrary to popular belief, SOC 2 does not mandate a strict list of cryptographic controls. Instead, it evaluates whether an organization has implemented appropriate encryption controls based on risk. That distinction matters: auditors care less about whether you check a specific box and more about whether your encryption strategy effectively protects sensitive data. This guide breaks down how encryption fits into SOC 2 compliance, where auditors look for it, and how to design encryption controls that hold up during a SOC 2 Type I or SOC 2 Type II audit. What “SOC 2 encryption requirements” really means The System and Organization Controls 2 (SOC 2) framework was created by the American Institute of Certified Public Accountants (AICPA) to help service organizations demonstrate that their systems are secure and trustworthy. SOC 2 assessments evaluate controls against the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. The AICPA’s 2017 Trust Services Criteria (updated with revised points of focus in 2022) is the document auditors reference when evaluating your controls. But here’s the key nuance: SOC 2 is a controls report, not a prescriptive encryption standard. Instead of dictating exact technologies, SOC 2 asks auditors to determine whether controls are appropriately designed and operating effectively to meet the Trust Services Criteria. This means encryption is often expected—especially for sensitive or regulated data—but it’s not universally “required” in every scenario. Scenario Encryption expectation Public marketing website TLS likely required Internal operational logs May depend on risk classification Customer database with PII Encryption almost always expected The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t, even if your encryption is technically sound, expect follow-up questions. How auditors evaluate “appropriate” encryption for your risk profile SOC 2 audits are risk-based. Auditors don’t walk in with a checklist of mandatory algorithms. Instead, they assess whether your encryption posture makes sense given the data you handle. They typically ask questions like: What types of data does the system process? How sensitive is that data? What threats could expose it? What encryption controls mitigate those risks? Organizations that process PII, financial records, or proprietary customer data will be expected to demonstrate stronger encryption controls than a company that only handles non-sensitive internal metrics. Evidence often includes encryption policies, architecture diagrams, key management procedures, configuration evidence from cloud services, and monitoring and audit logs. The point isn’t just having encryption—it’s having evidence that encryption is in place and working as described. If you’re working from a SOC 2 compliance checklist, make encryption evidence a line item, not an afterthought. For a SOC 2 Type I, auditors evaluate control design at a single point in time. They’re asking: “Are these controls designed in a way that should work?” For a SOC 2 Type II, auditors test whether encryption controls operated consistently over time, typically across a 6–12 month period. This is where SOC 2 Type II continuous monitoring becomes essential. It’s one thing to set up encryption correctly on a Tuesday—it’s another to prove it was running properly every day for the last nine months. The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t—even if your encryption is technically sound—expect follow-up questions. Criterion Role of encryption Key focus Security (mandatory) Primary TLS for network communication, secrets protection, key management, access control enforcement Confidentiality Primary Protecting sensitive data at rest (e.g., AES-256, TDE) and in transit Privacy Important Encrypting PII, credentials, and identity documents; works alongside retention and data minimization controls Availability Supporting Encrypted backups, secure recovery data Processing Integrity Supporting Tamper protection during data transmission and processing Security is the only mandatory criterion in every SOC 2 audit, but if you’ve included Confidentiality or Privacy in your scope, encryption becomes a central control,not a supporting one. For organizations weighing SOC 2 against other standards, our comparison of ISO 27001 vs SOC 2 can help clarify the differences. Encryption scope: what auditors will examine Auditors evaluate encryption within the boundaries you define. That means scoping decisions matter as much as the technical implementation. A mature SOC 2 environment classifies data into tiers,public, internal, confidential, and regulated,and applies encryption requirements accordingly. Customer data almost always receives the strictest protections, while internal operational metrics may be risk-based. If you haven’t built a formal data classification policy, expect auditors to flag that gap. Data type Encryption expectation Customer database Mandatory encryption Employee HR records Strong encryption Internal monitoring metrics Risk-based Two scoping pitfalls that auditors flag regularly: production data copied into staging or development environments without encryption (if real data is present, it needs production-grade protections), and unclear cloud shared responsibility. Cloud providers operate under shared responsibility models,infrastructure security may be the provider’s job, but data encryption configuration is almost always yours. Organizations using services like AWS KMS, Azure Key Vault, or Google Cloud KMS must demonstrate what the provider manages, what they manage, and how both are verified. Data in transit and at rest: what you need to encrypt In transit The industry standard is TLS 1.2 or TLS 1.3 for any data crossing a network boundary,external APIs, admin portals, and internal microservices where the risk justifies it. The rule is simple: if sensitive data moves between systems, it should be encrypted. Auditors increasingly ask about internal service-to-service traffic, not just external connections. Organizations using service mesh frameworks or zero-trust models are well positioned here. Don’t overlook remote access (VPNs, bastion hosts, zero-trust gateways), file transfers (SFTP over plain FTP), and certificate lifecycle management,an expired TLS certificate that causes an outage is both an availability problem and evidence that controls aren’t operating effectively. At rest Encryption at rest protects stored data from unauthorized access. The most
SOC 2 compliance can sometimes feel like a needlessly complex Pandora’s box of documentation. But it shouldn’t be. That’s why today, we’ll show you how to easily become compliant with our 12-step SOC 2 compliance checklist.In its simplest form, all the SOC 2 sections point to the same question: Can you prove your controls work? This SOC 2 Compliance Checklist guides you through the process from scoping through audit completion for both SOC 2 Type 1 and Type 2. It is practical, auditor-aligned, and written for teams that want clarity rather than theory. If you want the short version: SOC 2 is not about tools or paperwork. It is about repeatable processes, clear ownership, and evidence that stands up to scrutiny. What is a SOC 2 compliance checklist? A SOC 2 compliance checklist is a structured roadmap that maps your internal controls to the AICPA Trust Services Criteria and prepares your organization for a Type 1 or Type 2 audit. For a full breakdown of SOC 2 requirements, read our detailed SOC 2 guide. How to Use This SOC 2 Compliance Checklist Think of this checklist as a living roadmap, not a one-time document. You should revisit it at four points: before scoping, during readiness, throughout evidence collection, and after the audit for continuous compliance. Type 1 vs. Type 2: Which Checklist Items Change? The core checklist does not change dramatically between Type 1 and Type 2. What changes is time and proof. Type 1 evaluates whether controls are designed correctly at a specific point in time. Type 2 evaluates whether those same controls operated effectively over an observation period, usually 3, 6, or 12 months. This means evidence for Type 2 must show consistency, such as quarterly access reviews, repeated vulnerability scans, and incident response tests that actually occurred. Who Owns Each Workstream SOC 2 is cross-functional by design. Security may lead, but it cannot succeed alone. Engineering typically owns secure SDLC, change management, and logging. IT owns IAM, endpoints, and device management. Legal and HR contribute policies, onboarding controls, and training. GRC or compliance coordinates risk assessment, evidence, and auditor communication. The fastest SOC 2 projects have named control owners with deadlines, not shared responsibility. What “Audit-Ready” Really Means Being audit-ready does not mean “we think we are secure.” It means you can produce clear, dated, and traceable evidence that maps directly to the Trust Services Criteria. Auditors test design, then operation. They expect policies, tickets, screenshots, logs, and approvals. They also expect alignment. If your policy says quarterly, your evidence cannot show annual. The AICPA provides the underlying standard, supported by SSAE 18 and AT-C 205. Pre-Checklist: Confirm You Actually Need SOC 2 Not every company needs SOC 2 immediately. If your customers are SMBs, you may see lighter requirements. If you sell to enterprises, SOC 2 often becomes non-negotiable. Security questionnaires are the strongest signal. When prospects ask about penetration testing, access reviews, and incident response evidence, SOC 2 is usually the cleanest way to respond at scale. Alternatives like ISO 27001, PCI DSS, or HIPAA can be valid. But SOC 2 is uniquely customer-facing, especially in North America. ISO 27001 is excellent for global alignment, while SOC 2 maps directly to buyer trust. The 12-Step Checklist Step 1- Define Scope Scoping mistakes cause more SOC 2 delays than any missing control. Your scope must clearly define the services you provide, the systems that support them, and the access controls. Over-scoping increases cost and complexity. Under-scoping leads to auditor pushback. In-scope systems usually include production cloud environments, CI/CD pipelines, support tooling, and identity providers. In-scope people include employees and contractors with access to customer data. Third parties are addressed as Subservice organization, using either the Carve-out method or Inclusive method. Data classification and flows must identify PII, PHI, or payment data, and how it moves through systems. Action Plan for Scoping Define the Service Commitment List In-Scope Systems Identify In-Scope People Document Third Parties Map Data Flows Validate Scope with Leadership Step 2- Select the Trust Services Criteria All SOC 2 reports include Security (Common Criteria). The others are optional but must be justified. Availability focuses on uptime and disaster recovery. Confidentiality focuses on sensitive data protection. Processing Integrity focuses on system accuracy. Privacy applies when personal data obligations are central. Your report must document why each criterion is included or excluded. Auditors look closely at this rationale. Trust Service Criteria Action Plan Confirm Security (Mandatory) Assess Optional Criteria Document Inclusion Rationale Obtain Executive Sign-Off Step 3- Choose the Audit Path and Timeline Most teams benefit from a readiness assessment before audit. This is often referred to as a Readiness assessment or Gap analysis. Type 1 audits can be completed in weeks once controls are ready. Type 2 timelines depend on the observation period. Six months is the most common balance between speed and credibility. Define control owners early and create an evidence calendar. Late evidence is the enemy of clean audits. Audit Path and Timeline Action Plan Conduct Readiness or Gap Assessment Choose Audit Type Set Observation Period (Type 2) Assign Control Owners Build Evidence Calendar Step 4- Pick an Auditor and Define the Engagement Choose a CPA firm with real SOC 2 experience in your industry. Responsiveness matters more than brand name. Confirm standards, testing approach, sampling expectations, and how subservice organizations are treated. The engagement letter should clearly state scope, period, and deliverables. A clear PBC list process avoids confusion later. Action plan for finding an auditor. Shortlist CPA Firms Review Testing Approach Clarify Subservice Treatment Finalize Engagement Letter Request Preliminary PBC List Step 5- Perform a SOC 2 Gap Analysis Map existing controls to the Trust Services Criteria. Missing policies, undocumented processes, and inconsistent evidence usually surface here. Prioritize high-risk gaps first. Document known exceptions and compensating controls honestly. Auditors prefer transparency over perfection. Gap Analysis Action Plan: Map Controls to Criteria Identify Missing Controls Prioritize by Risk Document Compensating Controls Step 6- Build the Policy and Governance
Drata is a powerful tool. It can transform a slow, resource-draining activity into a value-added automated task. But in order for it to work, it needs to be set up properly. This guide explains how SOC 2 actually works inside Drata, what you need before you begin, and how to avoid the most common mistakes that slow teams down. It is written for founders, CISOs, compliance leads, and non-technical executives who want a semi-automated approach to compliance. Drata does not replace your SOC 2 program. It operationalizes it. The platform helps you manage controls, evidence, and monitoring, but decisions, ownership, and execution still matter. A successful Drata SOC 2 project follows a predictable flow: scoping, setup, automation, validation, and audit. Before You Start: What You Need to Run a SOC 2 Project in Drata Before logging into Drata, your organization needs to be aligned. 1- Decide your SOC 2 target: Type 1 vs. Type 2 and realistic timelines SOC 2 comes in two formats defined by the AICPA. SOC 2 Type I evaluates whether controls are designed correctly at a point in time.SOC 2 Type II evaluates whether those controls operate effectively over a period, usually three to twelve months. Report Type What It Evaluates Timeframe SOC 2 Type I Whether controls are designed appropriately Point in time SOC 2 Type II Whether controls operate effectively 3–12 months With Drata, many of our clients reach Type I readiness in 6 to 8 weeks if controls already exist. Type II timelines depend on the observation period, which can range from 3 months to up to a year. If you’re pursuing SOC 2 compliance due to a client’s request, he will till you which type he requires. If you’re proactively seeking SOC 2 compliance, then we recommend going for type 2 compliance. This allows you to cast a wider net of clients. A successful SOC 2 program follows a predictable lifecycle. While tools and timelines vary, the underlying phases are consistent across most organizations. Scoping: Define the system being audited, select Trust Services Criteria, set the audit period, and confirm the auditor. Good scoping reduces downstream complexity dramatically. Setup: Configure Drata, connect integrations, publish policies, and assign control ownership. This phase turns abstract requirements into operational structure. Automation: Enable continuous evidence collection across identity, infrastructure, code, ticketing, and endpoints. Automation replaces manual tracking, but only when integrations reflect reality. Validation: Run a readiness review. Confirm that controls are operating as described, evidence is complete, and timing aligns with the audit window. This is where most hidden risks surface. Audit: Auditors independently test controls and evidence. Clarifications and minor findings are normal. Clear responses and preparation determine how fast this phase moves. Continuous compliance: After the report is issued, controls continue operating. Monitoring, reviews, and periodic reassessment prevent drift and reduce effort in future audit cycles. 2- Select your Trust Services Criteria Every SOC 2 must include the Common Criteria for Security. Additional criteria are optional and must be justified. These include Availability, Confidentiality, Processing Integrity, and Privacy. The choice of additional criteria is driven by the service agreement with the customer, which may require specific criteria, or by the type of business pursuing SOC 2. If you’re a SaaS that handles a large amount of private financial data, it makes sense to pursue the confidentiality criteria, for example. Availability makes sense if you sell uptime guarantees or SLAs. Privacy should only be selected if you are prepared to meet the additional criteria around notice, consent, and data subject rights. 3- Gather prerequisites: Systems, Owners, and Access Drata works best when you already know what is in scope. This includes cloud infrastructure, identity providers, repositories, ticketing tools, and endpoints. You also need named control owners. Automation cannot replace accountability. 4- Choose or confirm an auditor early An external CPA firm ultimately issues the SOC 2 report. Confirm your auditor before proceeding with deep configuration to avoid mismatches in expectations, evidence formats, or control interpretations. Where Axipro Fits in a Drata-Led SOC 2 Program Drata is excellent at operationalizing SOC 2. It centralizes controls, automates evidence collection, and enforces timelines that matter to auditors. What it does not do is make judgment calls, resolve ambiguity, or design controls in context. That work still belongs to the experts. This is where Axipro fits. In practice, Axipro supports Drata-led SOC 2 programs in four critical areas: Scoping discipline Before configuration begins, Axipro helps validate system boundaries, Trust Services Criteria selection, and audit periods. This prevents over-scoping, which is one of the most common reasons SOC 2 projects slow down or fail testing later. Control ownership and execution clarity Drata can track controls, but it cannot assign accountability. Axipro works with teams to ensure every in-scope control has a clear owner, a realistic execution process, and an evidence strategy that will stand up to auditor scrutiny. Readiness validation before auditor access Many SOC 2 delays happen after auditors are invited. Axipro performs structured readiness reviews to catch weak evidence, misaligned controls, and timing gaps before fieldwork begins. This reduces follow-ups, exceptions, and rework. Audit navigation and exception handling During the audit, Axipro helps teams respond to auditor questions, document compensating controls, and resolve findings clearly. This keeps the audit moving and avoids creating long-term issues that resurface in future cycles. Drata provides the operating system. Axipro helps ensure the program running on top of it is coherent, defensible, and sustainable. Step 1: Scope Your SOC 2 Program in Drata Once your prep work is done, it’s time to open Drata and start the real implementation work. Scoping is the first and most important step. It defines what the auditor will test and, just as importantly, what they will ignore. Create the audit container In Drata, scope becomes “real” the moment you create the audit. Navigate to Audit Hub, then select Create Audit. Choose SOC 2 as the framework and define the audit period. This date range matters more than most teams realize. Drata
If your company sells software, handles customer data, or operates in the cloud, chances are you have already been asked for a SOC 2 report. Sometimes by a prospect, sometimes by a procurement team, sometimes by a very persistent security questionnaire that refuses to go away. And if you are early in your compliance journey, that request can feel confusing, intimidating, or even slightly unfair. What exactly is a SOC 2 report? What does it include? How does the process actually work? And do you really need one right now? This article answers those questions clearly, without legal jargon or unnecessary complexity. Whether you are a startup selling internationally or a SaaS company expanding into enterprise deals, this guide will give you the full picture on SOC 2 compliance. What does SOC 2 stand for? SOC 2 stands for System and Organization Controls 2. It is part of a broader family of SOC reports created to help organisations demonstrate how they manage and protect information. In a nutshell, its a voluntary framework that proves that a company stores and manages data in a safe way. The “2” matters because it distinguishes this report from others in the SOC framework: Report Type Primary Focus Typical Audience SOC 1 Controls relevant to financial reporting Auditors, finance teams, regulators SOC 2 Controls related to security, availability, processing integrity, confidentiality, and privacy Customers, partners, procurement teams SOC 3 High-level public summary of SOC 2 controls General public, marketing, prospects When customers ask for “SOC 2,” they are seeking evidence that your internal systems and processes are designed to protect their data consistently and measurably. And this can be evaluated through a SOC 2 report. SOC 2 vs SOC 1 vs SOC 3: what’s the difference? SOC reports serve different purposes, and choosing the wrong one can create unnecessary work. SOC 1 focuses exclusively on controls related to financial reporting. It is primarily relevant for service providers whose systems impact a customer’s financial statements, such as payroll processors or financial platforms. SOC 2 evaluates controls related to security, availability, processing integrity, confidentiality, and privacy. It is the most commonly requested report for SaaS companies, cloud providers, and B2B service organisations because it directly addresses data protection and operational risk. SOC 3 is a high-level, public summary of a SOC 2 report. It contains far less detail and is typically used for marketing or high-level assurance, not for procurement or vendor risk assessments. If customers, partners, or regulators need detailed evidence of how you protect data, SOC 2 is almost always the correct choice. https://www.youtube.com/watch?si=_Qmle4yusN2cMOJT&v=dueT49f5wNA&feature=youtu.be Benefits of SOC 2 Compliance- Why do Companies Pursue Compliance? Companies invest in SOC 2 compliance for the commercial and operational advantages it delivers. But besides that, being able to produce a SOC 2 report will allow to cast a wider net and work with customers that you would otherwise not be able to work with. Some examples: Cloud service providers, SaaS companies, and Data Centers looking to win big enterprise contracts: These businesses are often required to do Vendor Risk Assessment due to regulations such as GDPR, HIPAA, PCI DSS, SOX, and NYDFS. Companies in tightly regulated industries: Finance, healthcare, and technology are typically regulated by norms that required SOC 2 reports and Vendor Risk Assessment. Companies bidding for government contracts: While not always required, some government bodies will ask for an SOC 2 report or ISO 27001 certification to accept bids. SOC 2 reports are becoming widespread since they cascade down: Most SOC 2 compliant businesses will require vendors to produce a SOC 2 report, and not having an SOC 2 report will often make you lose a compliant client. Besides that, the most immediate benefit is trust. A SOC 2 report reduces friction during sales cycles by answering security questions upfront, rather than repeatedly through bespoke questionnaires. So even when its not strictly required, having a SOC 2 report will be beneficial. It also improves internal discipline. Preparing for SOC 2 forces teams to formalise access controls, incident response, change management, and monitoring processes that often exist informally. Finally, SOC 2 can be a growth enabler. Many enterprise buyers will not progress without it. Having a current report keeps deals moving and prevents compliance from becoming a last-minute blocker. A 2023 procurement study published by Wired noted that vendor security reviews are now standard even for contracts under six figures, reflecting how deeply embedded assurance expectations have become. Who typically needs SOC 2 compliance? SOC 2 is most often pursued by organisations that handle customer data on behalf of others, especially where trust and security influence buying decisions. This commonly includes: SaaS and cloud-based software companies Managed service providers, IT, and security firms Data platforms, infrastructure providers, and APIs Companies selling into regulated or enterprise markets Beyond industry, SOC 2 is often triggered by stage and scale. Startups moving upmarket, companies entering enterprise sales cycles, or vendors undergoing formal vendor risk assessments are frequently asked for a SOC 2 report before deals can progress. Even when not explicitly required, SOC 2 often becomes a commercial necessity. Customers increasingly expect structured, independent assurance that security controls are not improvised, but designed, documented, and consistently followed. What is a SOC 2 report? A SOC 2 report is an independent assurance report that evaluates how well an organisation protects customer data. It is issued by a licensed CPA firm and is based on the Trust Services Criteria (TSC) developed by the American Institute of Certified Public Accountants (AICPA). In simple terms, a SOC 2 report answers one core question: Can this company be trusted to handle sensitive information securely and responsibly? Unlike ISO standards, SOC 2 is not a “certification” in the traditional sense. There is no pass or fail badge. Instead, the report documents: Your control environment How controls are designed How they operate over time Any exceptions or gaps identified by the auditor The result is a detailed report that customers and partners use to assess your
ISO 27001 Hub
The latest resources and guides for ISO 27001 Certification
AI Hub
The latest insights into AI implementation and compliance