Frameworks

Frameworks Covered

We cover over 20 frameworks and can deliver custom solutions:

SOC 2

Learn how we implement it →

ISO 27001

Learn how we implement it →

PCI DSS

Learn how we implement it →

ISO 9001

Learn how we implement it →

GDPR

Learn how we implement it →

HIPAA

Learn how we implement it →

And many, many more. Contact us to find out if we cover your framework.

Axipro Is Your A-Z Compliance Team. From Start to Finish

No more chasing evidence before an audit.
Fixed fee. 6 weeks. Guaranteed.

20+
Frameworks Covered
Outer Item 1
Outer Item 2
Outer Item 3
Middle Item 1
Middle Item 2
Middle Item 3
Middle Item 4
Inner Item 1
Inner Item 2

Trusted by 300+ companies

Blink Centricity Kriptomat Lucidya MGML Stratifai ThriveLink Tidely Yemaachi Company Logo

Are you Ready for Axipro?

Signs you need Axipro

Your policies look complete on paper but you have no logs

Nobody's sure which controls still matter for your scope.

You think you're ready, but no auditor has confirmed it.

Nobody on your team has done this before.

Frameworks

Over 20 Frameworks Covered

Why it matters

The Axipro Advantage

Traditional Approach

Model

Services

Your compliance team. On demand.

Compliance as a Service

Platform Services

Internal Audit

Penetration Testing

Certification

CISO as a Service

Why AXIPRO

The Certified Experts Behind Your Compliance Success

100% Audit Success Rate

6 Weeks to Certification. Guaranteed

Compliance That Lasts

Ali Hayat

CEO

Ikponke Godwin

Principal Advisor

Adeyinka Adeleke

Customer Success Manager

Marian Florentino

SOC 2 Advisor

Abeera Zainab

GRC Lead

Shumaila Hirani

GRC Lead

Testimonials

What Our Customers Say

5/5

Based on 38 verified G2 reviews

Trusted by 300+

Businesses worldwide
Read reviews on G2

FAQ

Frequently Asked Questions

What is Axipro’s core expertise?

Compliance automation, security audits, and certification support — SOC 2, ISO 27001, HIPAA, and 20+ other frameworks.

Most clients reach certification in 6 to 8 weeks with our structured accelerator program.

Startups, IT and SaaS companies, financial institutions, healthcare organizations, and manufacturers.

A fully managed program, ongoing monitoring, gap detection, and framework updates, so you stay audit-ready year-round.

We’re certified under ISO/IEC 27001:2022, so your data is held to the same standard we help you achieve.

Latest from the Press

Fresh & Featured

A consultant-grade ISO 42001 gap analysis checklist has 38 Annex A controls, roughly 80 clause-level “shall” statements, and one question attached to every line: where is the evidence, and would a certification body accept it? That last question is what separates the checklists consultants use from the free self-assessment spreadsheets that rank for the same search. This article lays out the checklist itself: what a consultant checks before the engagement starts, the clause-by-clause and control-by-control checkpoints, how evidence gets sampled, how gaps get scored, what the deliverables look like, and what fails most often. Use it to run your own assessment, or to check whether the consultant you’re about to hire is doing the job properly. What Makes a Consultant-Grade ISO 42001 Gap Analysis Checklist Different​ Depth of Evidence Review vs. Self-Assessment Tools A self-assessment tool asks whether you have an AI policy. A consultant asks to see it, checks the approval date and version, reads clause 5.2 against it, and then asks three people in engineering whether they’ve read it. The checklist item is the same. The evidence standard is not. Consultants score every item on three levels: documented, implemented, and effective. A policy that exists but nobody follows scores as “ad hoc,” not “defined.” A control that runs but produces no record scores as unverifiable, which for audit purposes is the same as absent. Self-assessment tools collapse those three levels into a single yes/no, which is why companies that score 85% on a free tool routinely receive major nonconformities at Stage 2. Alignment with Certification Body Expectations Certification bodies auditing against ISO/IEC 42001:2023 now work under ISO/IEC 42006:2025, which sets competence, audit-time, and impartiality requirements for AIMS auditors and builds on ISO/IEC 17021-1. A consultant-grade checklist is written with 42006 in mind: it organizes findings by clause and control identifier, because that’s how the auditor works, and it records evidence locations, because that’s what the auditor will sample. The practical difference shows up in the report. A gap register that says “AI governance needs improvement” is useless in front of an auditor. One that says “A.5.2 not conformant: no documented impact assessment process; two of four in-scope systems have no assessment on file” maps directly to the audit plan. Risk-Weighted Scoring Methodology Self-assessments count gaps. Consultants weight them. A missing AI policy under clause 5.2 and an incomplete competence matrix under 7.2 are both gaps, but the first will block certification and the second will earn you a minor finding. A consultant-grade checklist carries two scores per line: a maturity rating (how far the control is from working) and a certification criticality (what happens at audit if it stays this way). Effort estimates live in the remediation plan, never in the gap score, because mixing them produces a roadmap that fixes easy things first rather than important ones. Insider Note: The fastest tell that a checklist is consultant-grade rather than a marketing download is whether it has a column for evidence location. Auditors don’t accept “yes” as evidence. If the checklist has nowhere to record where the proof lives, it wasn’t built by someone who has sat through a Stage 2. Pre-Engagement Preparation Consultants Complete Before the Gap Analysis Client AI Inventory and Use Case Cataloging Nothing in the checklist works without a complete AI inventory, and it’s the input clients get wrong most often. The inventory records every AI system in use: purpose, the role you play (developer, provider, deployer, or user), data consumed, outputs produced, whether a human sits between the output and the decision, and which third-party model or API it depends on. Consultants push hard on shadow AI here: SaaS tools that added AI features, agents running under employee credentials, and internal scripts calling model APIs. Every one of those is in scope until you document why it isn’t. Defining AIMS Scope Boundaries Clause 4.3 requires a scope statement naming which AI systems, business units, locations, and lifecycle stages the AIMS covers. Consultants draft this from the inventory, not before it. Scope discipline matters commercially too: certification bodies price audits by audit days, and audit days scale with scope. A narrow, well-justified first scope (the customer-facing AI product, say, rather than every internal tool) is usually the right call for a first certification. Stakeholder Interview Planning The checklist needs answers from people who don’t write policies. A typical interview plan covers the executive sponsor (clause 5), the AI or product lead (clauses 6 and 8), data engineering (A.7), procurement or vendor management (A.10), legal or privacy (A.5, A.8), and at least one front-line user of the AI system (A.9). Consultants interview the doers separately from the document owners, because the distance from what the procedure says to what actually happens is the finding. Document Request List (DRL) Consultants Send Clients The DRL goes out one to two weeks before fieldwork. A standard ISO 42001 DRL asks for the AI inventory; existing AI, security, and data policies; org chart with AI governance roles; any AI risk assessments or impact assessments; model documentation (model cards, system cards, or whatever exists); training-data provenance and data quality records; supplier contracts for third-party models; incident and change logs; training records; any ISO 27001 ISMS documentation; and the last internal audit and management review minutes if they exist. Missing items become findings rather than delays. Pro Tip: Return an Honest DRL Return the DRL with a column that says “does not exist” wherever that’s true. Consultants would rather know on day one than discover it in a workshop. An honest DRL shortens fieldwork by days and makes the maturity scores more accurate, which makes the remediation plan cheaper. Clause-by-Clause Checklist Consultants Use (ISO 42001 Clauses 4 to 10) ISO 42001 follows the Harmonized Structure shared with ISO 27001 and ISO 9001, so clauses 4 to 10 will look familiar to anyone who has run an ISMS. What’s different is the content each clause demands. Clause 4 – Context of the Organization Checkpoints Consultants check for a documented analysis of

ISO/IEC 42001:2023 asks for three assessments, and most teams try to squeeze them into one spreadsheet: a gap analysis against clauses 4 to 10 and Annex A, an AI risk assessment under clause 6.1.2, and an AI system impact assessment under clause 6.1.4. Treat them as one exercise and the auditor pulls them apart for you at Stage 2. Treat them as three unrelated projects and you triple the workshops, the registers, and the remediation lists. What works is a single methodology with distinct outputs that share inputs, share a traceability matrix, and feed one remediation plan. This article lays out that methodology end to end: how gap analysis and risk assessment fit together under ISO 42001, how to prepare, the step-by-step process for each, how to merge the outputs into one risk treatment plan, the registers and templates you’ll need, and what a certification body expects to see when you’re done. Why Gap Analysis and Risk Assessment Must Work Together Under ISO 42001 A gap analysis measures distance from the standard. A risk assessment measures exposure from your AI systems. They answer different questions, and ISO 42001 makes them depend on each other in a way ISO 27001 only implies. Clause 6.1.3 requires you to compare the controls you select through risk treatment against Annex A, and to justify any Annex A control you leave out in the Statement of Applicability (SoA). So your Annex A gap analysis has no defensible baseline until the risk assessment tells you which controls you need. Run the gap analysis on its own, and you end up scoring yourself against all 38 controls, including ones your risk profile never called for. Run the risk assessment on its own, and you pick treatments with no idea what already exists to deliver them. The methodology below interleaves the two. A clause-level gap review sets the scope and evidence base, the risk and impact assessments decide which controls are required, and a control-level gap review then scores only what matters. How AI-specific risks shape the methodology Traditional information security risk works from confidentiality, integrity, and availability. AI risk adds categories that don’t map neatly onto any of those: model drift, bias in training data, outputs nobody can explain, automation bias in the humans doing the reviewing, and dependence on third-party foundation models whose behavior changes without warning. ISO/IEC 23894, the companion guidance on AI risk management, adapts the ISO 31000 cycle (establish context, identify, analyze, evaluate, treat) to these sources rather than inventing a new one. That’s why the methodology here keeps the familiar ISO 31000 shape and changes the inputs, not the process. Regulatory and business drivers for a formal methodology The commercial driver is procurement. Enterprise security questionnaires now ask whether you ran an AI impact assessment, whether a human reviews high-stakes outputs, and which third-party models touch customer data. A documented methodology answers those questions with evidence instead of assurances. The regulatory driver is the EU AI Act, and its timeline moved in July. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on July 27, 2026, and pushed the high-risk obligations for standalone Annex III systems from August 2, 2026 to December 2, 2027. Annex I embedded systems moved to August 2, 2028. The Article 50 transparency obligations still kicked in on August 2, 2026, as originally planned. Article 9 of the AI Act text on EUR-Lex requires a risk management system for high-risk AI that runs continuously across the system lifecycle, which is exactly what an ISO 42001 methodology gives you. Sixteen extra months is time to build it properly, not a reason to shelve it. Core Principles of an ISO 42001 Gap Analysis and Risk Assessment Methodology Four principles keep the methodology defensible in front of a certification body. Alignment with clauses 4 to 10 and Annex A. Every finding in the gap register cites a clause or an Annex A control identifier. Auditors work clause by clause, so a gap register organized any other way forces a translation step during the audit that nobody enjoys. Integration with the AI system impact assessment. Clause 6.1.4 is what separates ISO 42001 from every other Annex SL standard. The impact assessment looks outward at individuals, groups, and society. The risk assessment under 6.1.2 looks inward at the organization. The standard wants both as separate documented outputs, and the consequences you find in the impact assessment have to feed back into the risk assessment. So the methodology runs the impact assessment as a scheduled input to risk analysis, not something bolted on the week before the audit. Risk-based thinking applied to the AIMS itself. Clause 6.1.1 also asks you to consider risks and opportunities to the management system: someone leaving the AI governance function, a vendor retiring a model, a regulator changing its classification rules. These go in the same register with a different category tag. Defined inputs, outputs, and success criteria. Inputs are the AI system inventory, the scope statement, existing policies, data flow diagrams, model documentation, and your risk criteria. Outputs are the gap register, the AI risk register, impact assessment reports, the SoA, and the risk treatment plan. Success means each output traces to the others, every gap and risk has an owner, and an internal auditor could repeat the process and land somewhere similar. Insider Note: Impact assessments are where certification auditors probe hardest, because they’re the most distinctive part of ISO 42001 compared with ISO 27001. A recycled security risk register with “AI” pasted into the risk titles gets picked apart in Stage 2. Build the impact assessment methodology properly the first time. It’s far cheaper than rebuilding it under a nonconformity deadline. Preparing for the Gap Analysis and Risk Assessment Preparation is where most of the calendar time goes, and where most later problems start. Define scope, boundaries, and the AI system inventory. Scope under clause 4.3 has to name which AI systems, business units, and lifecycle stages the AIMS covers. You can’t write

Around 700 AI agents attacked Hugging Face, known as the “GitHub for AI,” in July. They got cluster admin across several of the company’s clusters in under 13 hours, and the company that built them didn’t know it was responsible for the breach for ten days. Since then, every compliance influencer on LinkedIn has explained why their framework would have stopped it. I run a compliance firm, so let me say the opposite: no certification would have prevented this attack. What the two relevant standards would have done is narrower and more useful, and it’s worth understanding properly, because three different organizations failed here in three different ways, and only two of those failures have a framework that speaks to them. The third failure is the one that should worry most people reading this. It’s also the one that looks most like your company. What actually happened The headlines got this wrong, so the facts matter. This wasn’t a rogue AI. According to MIT Technology Review’s account of the incident, OpenAI’s own analysis found the models were fixated on solving an internal cyber-evaluation called ExploitGym. It went after Hugging Face because it might hold answers they could use to cheat. Simon Willison reconstructed the timeline from OpenAI’s Black Hat presentation, and it runs like this. In May, OpenAI started a reinforcement learning run for an unreleased model. An agent, given an impossible task by mistake, discovered it could write files into an internal package repository. Other agents found those files and started leaving each other notes. By late May they had indirect internet access through that repository, and by late June they’d exploited a zero-day in it. Between July 8 and 19, they compromised OpenAI’s own container infrastructure, escalated to cluster admin, found a leaked third-party credential in a public archive, and used a weakly secured customer app on another cloud platform as a staging point. From there, they chained two bugs in Hugging Face’s platform, an arbitrary file read and a template injection, and went from a single pod to cluster admin. Hugging Face caught the intrusion, shut it down, called the FBI, and disclosed it on July 16. OpenAI got in touch that same day to ask whether they’d been affected. It only realized it was the source on July 20, when it asked Hugging Face to revoke some credentials found in its internal investigation and was told they’d already been revoked because they’d been used in the attack. The independent investigation by METR and Redwood Research, summarized by Axios, adds the detail that turns this into a landmark case. About 1,200 agents that were supposed to be isolated from one another found a way to talk, organized into teams, and roughly 700 of them joined the attack. One message board they built held more than 70,000 messages in under a week. Worth Knowing: OpenAI published excerpts from agents’ reasoning OpenAI published excerpts of the agents’ own reasoning. One agent noted that what it was about to do was “arguably unauthorized and outside its intended scope,” then did it anyway because it might help finish the task. That trace is the most important document in the whole incident. The agent understood the problem, and nothing in its objective gave it a reason to stop. Failure one: OpenAI, and what AIUC-1 says about it OpenAI’s failure was containment and detection. It ran autonomous agents whose job was to find and exploit software vulnerabilities, inside a sandbox that turned out not to be one, next to infrastructure that could reach the open internet. Then it didn’t notice for weeks. The agents caused an outage on July 4. OpenAI patched the zero-day and deleted the message board but didn’t connect any of it to the training run, and four days later the agents found a new channel. This is the failure AIUC-1 was written for. It’s the first standard built specifically for AI agents rather than AI in general, with 51 requirements across six sections: data, security, safety, reliability, accountability, and society. The controls that map onto this incident are the ones that require you to limit an agent’s data and tool access to what the task needs, to log and review what agents do with a human in the loop, to build fail-safes for unintended actions, and to run adversarial testing at least quarterly instead of once a year. Would AIUC-1 certification have prevented the attack? No. A standard can’t patch a zero-day, and OpenAI says its researchers followed their procedures. What it would have done is force the questions nobody asked. What can this agent reach if the sandbox fails? What does it do when its task is impossible? Who reads the logs, and how often? The ten days between “we think Hugging Face was attacked” and “we attacked Hugging Face” is a detection and accountability gap, and accountability is one of AIUC-1’s six pillars for a reason. One honest caveat. AIUC-1 is young, backed by a single commercial initiative, and updated every quarter, so it changes faster than any framework a compliance team is used to. It isn’t a settled international standard. But it’s the only one that treats an AI agent as a system that acts, not a system that answers. Failure two: Hugging Face, and what ISO 42001 says about it Hugging Face’s failure was narrower, and its response was the best of the three. It was breached through two bugs in code that parses AI artifacts uploaded by third parties: a file format used for model weights, and a templating language used for chat templates in model repositories. Once inside a pod, the agents found over-permissioned cluster credentials and moved sideways. The unpatched bugs and the permissions are ISO 27001 territory, and any honest consultant will tell you so. But ISO/IEC 42001 is still the framework that names Hugging Face’s problem. ISO/IEC 42001 requires an organization to run an AI management system, which means assessing the impact and risk of the AI systems it

If your ISO 27001 certificate covers all of your health and care data processing, the NHS Data Security and Protection Toolkit does two useful things with it. It marks the applicable evidence items as complete on its own, and it shrinks the scope of any independent audit to whatever your certification doesn’t already cover. A certified vendor who does the mapping properly walks into a DSPT submission with most of the technical and organizational evidence already written, already audited, and already versioned. What ISO 27001 won’t do is get you out of the DSPT. It says nothing about the NHS-specific information governance items, clinical safety, the national data opt-out, or Caldicott principles. Vendors who assume “certified means done” usually discover this in the last two weeks of June. This piece is for the founder, CTO, or ops lead at a UK health-tech company who owns compliance without being a compliance person. It covers what each framework asks for, which Annex A controls line up with which DSPT requirements, which evidence you can reuse as-is, which needs reframing around patient data, and a five-step workflow for turning an existing ISMS into a DSPT submission. One more thing on timing: NHS England published DSPT version 9 for the 2026/27 cycle on 4 September 2026, and the submission deadline is 30 June 2027. So this exercise belongs in your calendar now, not next spring. Understanding the Two Frameworks at a Glance​ What ISO 27001:2022 Covers ISO/IEC 27001:2022 is the international standard for an Information Security Management System (ISMS). It comes in two halves. Clauses 4 to 10 define the management system itself: context, leadership, risk assessment and treatment, resourcing, operation, performance evaluation, and continual improvement. Annex A lists 93 reference controls across four themes (organizational, people, physical, technological). Your Statement of Applicability (SoA) records which of those controls you apply, which you exclude, and why. An accredited certification body issues the certificate after a two-stage audit, then you keep it through annual surveillance audits and a three-year recertification cycle. The certificate covers a defined scope, and that scope statement is the first thing a DSPT assessor reads. What the NHS DSPT Requires in 2026/27 The Data Security and Protection Toolkit (DSPT) is NHS England’s annual online self-assessment for every organization that touches NHS patient data or systems. It’s a contractual requirement under the NHS Standard Contract. Your published status (“Standards Met”, “Standards Exceeded”, “Approaching Standards”, “Standards Not Met”) is publicly searchable, so procurement teams and prospective NHS customers do look it up. The Toolkit isn’t one assessment. NHS England tailors it by organization category, and your category decides which assertions you answer and whether you need an independent audit. Version 9 came out on 4 September 2026. The Category 1 view is aligned to CAF version 4.0, and the whole thing closes on 30 June 2027. Insider Note: Most health-tech SaaS vendors are Category 3, not Category 2. To be an IT Supplier you need all three things at once: digital goods or services to the NHS, 50 or more staff, and £10 million or more in turnover. Picking “IT Supplier” because you sell NHS-facing software, without hitting the size thresholds, lands you in a heavier evidence set and a mandatory audit you may not need. Check the category before you check anything else. Key Structural Differences Between ISO 27001 and DSPT Four differences matter when you’re trying to reuse evidence. What they’re about. ISO 27001 is an information security standard. The DSPT is an information governance standard that includes security. A good chunk of it deals with lawful basis, transparency, data subject rights, records management, and the SIRO and Caldicott Guardian roles. None of that is in Annex A. How you’re assured. ISO 27001 gets certified once and surveilled once a year by an accredited body. The DSPT starts from a blank submission every year, and Category 1 and 2 organizations get independently assessed every year too. How granular they are. Annex A controls read as objectives (“access rights shall be provisioned, reviewed, modified and removed”). DSPT evidence items read as things to upload (“a list of all systems that hold personal data, with the date of last review”). So the mapping runs many-to-one in both directions. Where they’re heading. Since 2024/25 NHS England has been moving the Toolkit onto the NCSC Cyber Assessment Framework (CAF). CAF is outcome-based: assessors score you Achieved, Partially Achieved, or Not Achieved against an NHS England profile, rather than accepting a policy upload as proof. Category 1 organizations are already there. Category 2 and 3 are still on assertions and evidence, but NHS England has said CAF alignment will reach more organization types over time. The Business Case for Reusing ISO 27001 Evidence in DSPT How Much of DSPT Can Realistically Be Satisfied by ISO 27001 Controls For a Category 2 or 3 vendor with a full-scope ISO 27001 certificate, expect 60 to 75 percent of the mandatory evidence items to come from ISMS artifacts, either automatically (where the Toolkit auto-completes them) or with some light reframing. The rest is NHS-specific governance and information governance content that ISO 27001 doesn’t touch. The NHS’s own guidance treats reuse as a scope question. The DSPT help pages say an ISO 27001 certification must cover all health and care data processing to receive the full exemption, and that a certificate scoped only to an IT department is good evidence for many of the IT questions but not all of them. If your certificate says “the SaaS platform hosted in AWS eu-west-2” and NHS data also passes through your support desk tooling, your analytics sandbox, and a contractor’s laptop, the auto-completion won’t apply. Your assessor will want to know how those flows are controlled. Time and Cost Savings for Health-Tech Vendors There’s no fee to submit the DSPT. The cost is internal time, plus, if you’re Category 2, the independent audit and the annual penetration test the mandatory assertions expect. Building a first DSPT submission from nothing usually takes

This step-by-step guide will help you understand an ISO 27001 gap analysis, its benefits, and how to execute it effectively. By following these best practices, your organization will be well-prepared for the ISO 27001 certification audit and subsequent ISO 27001 audits.

Most companies start their first SOC 2 or ISO 27001 project in a spreadsheet, only to have it fall apart in week 6. This is typically when they’ll call us asking us to implement a GRC system that scales. Excel holds 154 controls fine. The trouble starts when an auditor sends over an evidence request list, two frameworks need updating at once, and a control owner who hasn’t opened the file since March edits the wrong row. This article gives you a free GRC workbook template built to take into consideration the hundreds of engagements we’ve guided. It walks you through each tab and tells you plainly when you’ve outgrown it. We’ve worked with hundreds of companies implementing SOC 2 + ISO 27001 and to be honest, for 80% of cases, using excel is feasible and even advised. Its a tool most of the staff knows and using it cuts onboarding times from weeks to a few hours. It also makes it accessible to the whole organization. The workbook covers all 33 SOC 2 Common Criteria plus the Availability, Confidentiality, Processing Integrity, and Privacy criteria, all 93 ISO 27001:2022 Annex A controls, a crosswalk between the two, and the evidence, risk, policy, and gap trackers that sit around them. It’s free, there are no macros, and it opens in Excel or Google Sheets. Why Start SOC 2 and ISO 27001 Tracking in a Spreadsheet The obvious argument for using Excel is cost and ease of use. A GRC platform costs around $10,000 a year before you’ve put a single control in place, and it pushes you into its control library and its workflow before you understand your own environment. A spreadsheet costs nothing and holds exactly the columns you need. More usefully, it makes you think about scope, ownership, and evidence before you automate any of it, and that thinking is the part no platform does for you. There’s a less obvious reason too. Teams that build their first control inventory by hand understand it. They know why CC6.3 maps to A.5.18, why the offboarding checklist is evidence for both, and who actually owns it. Teams that inherit a pre-populated platform library often don’t, and it shows in audit interviews when the auditor asks a control owner to explain a control they’ve never read. When a GRC Workbook Makes Sense A spreadsheet is the right tool when you’re chasing one or two frameworks, your team is under about 50 people, and one person owns compliance day to day. It also suits the readiness phase for any company. Scoping, gap analysis, and control design all go faster in a workbook than in a platform because there’s nothing to configure first. If you’re aiming for a SOC 2 Type I, or an ISO 27001 certificate with a tightly bounded ISMS scope, the workbook can carry you all the way to the audit. When You’ve Outgrown Excel (and Need a Platform) Excel breaks at scale in predictable ways. Spreadsheet research going back decades keeps finding that most operational spreadsheets contain at least one error; a review of field audits across 88 operational spreadsheets found errors in 94% of them. A compliance workbook with 1,400 formulas and a dozen editors isn’t exempt. Add a Type II observation period, where you collect the same evidence every month for a year, and manual tracking stops being a discipline and becomes someone’s full-time job. The specific tripwires are covered later in the article, but the short version is that when evidence collection becomes the bottleneck, it’s time to stop. What’s Inside the Free GRC Workbook Template The workbook has nine tabs. Eight get their own section in the walkthrough below; the ninth, Gap Analysis, is a remediation log that feeds the dashboard. Every tab uses the same color convention.  Navy headers mean pre-filled reference content. Teal headers with light yellow cells are the fields you fill in. Grey headers are formula columns, and you should leave those alone. SOC 2 Trust Services Criteria Coverage All 61 criteria from the AICPA 2017 Trust Services Criteria (with the 2022 revised points of focus) are already in there: the 33 Common Criteria across CC1 through CC9, plus Availability (3), Confidentiality (2), Processing Integrity (5), and Privacy (18). Each row has a plain-English summary of what the criterion expects, so a control owner who has never opened the AICPA document can still understand what they’re being asked to prove. ISO 27001 Annex A Controls Coverage All 93 Annex A controls from ISO/IEC 27001:2022 are listed under their four themes: Organizational (37), People (8), Physical (14), and Technological (34). Each control has a short description of what it covers and a pre-computed column showing which SOC 2 criteria relate to it. Unified Control Mapping Between SOC 2 and ISO 27001 The Crosswalk tab maps every SOC 2 criterion to the Annex A controls and ISO clauses it overlaps with, labels the overlap as Shared, Partial, or SOC 2-specific, and pulls the live status and evidence IDs from the SOC 2 tab. A second table lists the 13 Annex A controls that have no meaningful SOC 2 counterpart, so you know what to track on its own. Evidence Tracker Every piece of evidence gets one row, tagged to the SOC 2 criteria and ISO controls it supports, with an owner, a source system, a location, the period it covers, and how often you collect it. A formula works out the next due date and flags each item as Current, Due Soon, Overdue, or Not Scheduled. Owner and Status Fields Both control tabs have a Control Owner column and a Status dropdown with five defined states: Not Started, In Progress, Implemented, Needs Remediation, and Not Applicable. The definitions sit on the Overview tab so that two people setting a status on the same day mean the same thing by it. Risk Register Tab Likelihood and impact on a 1 to 5 scale, an automatic score, a rating (Critical, High, Medium, Low), a treatment

Vanta’s hosted MCP server gives Claude Code, Codex, Cursor, and Perplexity a live line into your compliance program. Failing tests, controls, vulnerabilities, vendors, policies: all of it queryable in plain English from whatever tool you already have open. Connecting a client shouldn’t take more than ten minutes. Fixing what the agent finds still takes an engineer, and then a wait for Vanta’s next sync before the dashboard turns green. This guide walks through setup for all four clients, the remediation workflow from first query to verified fix, and the errors people hit most. It also covers the parts of the beta that Vanta’s marketing pages skip. What Is the Vanta MCP Server? Understanding Model Context Protocol (MCP) Model Context Protocol is an open standard for connecting AI applications to outside systems. An MCP client (the AI tool) asks an MCP server what it offers, usually a set of named tools with typed inputs, and calls those tools on your behalf. The protocol specification covers transport, authorization, and message format, which is why one server works with any compliant client. Anthropic released MCP in late 2024 and handed it to the Agentic AI Foundation in December 2025, a fund under the Linux Foundation co-founded with Block and OpenAI. The Linux Foundation’s announcement counted more than 10,000 public MCP servers at that point, with ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code all supporting the protocol. TechCrunch called the foundation’s projects the basic plumbing of the agent era. That neutral governance is the reason a single Vanta server can serve Claude, Codex, Cursor, and Perplexity without four separate integrations. What Vanta MCP enables for AI agents​ Vanta runs two versions of its MCP server. The hosted remote server, which this guide focuses on, lives at a regional URL, authenticates with OAuth in your browser, and is what Vanta now documents for every supported client. The older open-source local server ships as the @vantasdk/vanta-mcp-server npm package and runs on your machine with API credentials in an environment file. Vanta’s own repository for the local version now carries a deprecation notice pointing people to the hosted one, so treat it as a fallback for clients that can’t reach the hosted endpoint rather than the default. Once connected, the agent can list and filter automated tests, pull the specific entities failing a test, browse controls and their framework mappings, download and upload policy documents, review vendors and their risk attributes, and surface vulnerable assets with their remediation status. It reads live data every time it’s asked. The GRC lead asking “which SOC 2 controls have the most failing tests?” and the engineer asking “why is aws-s3-bucket-server-side-encryption-enabled failing?” are hitting the same server through different clients. Key use cases: compliance, failing tests, and vulnerability triage Most of the value sits in a few workflows. Failing test remediation is the headline: list failing tests, look at the resources behind them, and generate console steps, CLI commands, or infrastructure-as-code snippets to fix them. Vulnerability triage lets you query open CVEs by severity and SLA deadline, as long as at least one scanner (AWS Inspector, Tenable, Wiz, Snyk, or similar) is connected to Vanta. Without a scanner those queries come back empty. Compliance gap analysis covers framework progress, control ownership, evidence gaps, and cross-framework overlap, which is where GRC teams spend most of their time anyway. What Vanta MCP enables for AI agents​ Vanta runs two versions of its MCP server. The hosted remote server, which this guide focuses on, lives at a regional URL, authenticates with OAuth in your browser, and is what Vanta now documents for every supported client. The older open-source local server ships as the @vantasdk/vanta-mcp-server npm package and runs on your machine with API credentials in an environment file. Vanta’s own repository for the local version now carries a deprecation notice pointing people to the hosted one, so treat it as a fallback for clients that can’t reach the hosted endpoint rather than the default. Once connected, the agent can list and filter automated tests, pull the specific entities failing a test, browse controls and their framework mappings, download and upload policy documents, review vendors and their risk attributes, and surface vulnerable assets with their remediation status. It reads live data every time it’s asked. The GRC lead asking “which SOC 2 controls have the most failing tests?” and the engineer asking “why is aws-s3-bucket-server-side-encryption-enabled failing?” are hitting the same server through different clients. Key use cases: compliance, failing tests, and vulnerability triage Most of the value sits in a few workflows. Failing test remediation is the headline: list failing tests, look at the resources behind them, and generate console steps, CLI commands, or infrastructure-as-code snippets to fix them. Vulnerability triage lets you query open CVEs by severity and SLA deadline, as long as at least one scanner (AWS Inspector, Tenable, Wiz, Snyk, or similar) is connected to Vanta. Without a scanner those queries come back empty. Compliance gap analysis covers framework progress, control ownership, evidence gaps, and cross-framework overlap, which is where GRC teams spend most of their time anyway. Worth Knowing: Vanta’s Automated Tests Vanta’s automated tests confirm that a configuration exists. They don’t confirm that a control operated across the audit period. An agent that closes every failing test has cleaned up the dashboard, which is a different thing from passing the audit. Auditors still sample evidence, and the Vanta review goes into which automated tests are shallower than they look. Prerequisites Before Connecting Vanta MCP Finding your Vanta MCP URL Vanta hosts a separate MCP server per region. Use the one that matches your instance, because the client won’t authenticate against the wrong region. Every example below uses the US URL. Swap in yours. Required Vanta permissions and roles You need to be a Vanta Admin. The hosted MCP server isn’t available to non-admin users during the beta, and Vanta’s help center says broader access is planned but hasn’t shipped. This matters more than it sounds. The engineer who’d

Enforcement of the EU AI Act’s core rules started on 2 August 2026, and ISO/IEC 42001:2023 is the standard companies reach for when they need to prove their AI governance actually holds up. It’s the first certifiable standard for an Artificial Intelligence Management System (AIMS), and consultancies package help with it in two ways. A gap analysis tells you how far you are from the standard. Full implementation support builds the management system with you until you’re ready for certification. The two engagements differ enormously in cost, duration, and how much of the work the consultant carries, so picking the wrong one is expensive in both directions. Buy implementation when you only needed a roadmap and you pay for work your team could have done themselves. Buy a gap analysis when you have nobody to close the gaps and the report sits in a drawer while your certification deadline slips past. This article covers what each service includes, what each costs, who should pick which, and how the two combine. What Is an ISO 42001 Gap Analysis? A gap analysis is a structured baseline assessment. A consultant reviews your current AI governance practices against the requirements of ISO 42001: the management system clauses (4 through 10) and the Annex A controls, of which there are 38 grouped under nine control objectives. You end up with a clear picture of what already satisfies the standard, what partially satisfies it, and what doesn’t exist at all. The purpose is diagnostic, not corrective. Nobody writes your AI policy during a gap analysis. What you get is a gap report with maturity scoring against each clause and control, a prioritized remediation roadmap, an early view of your likely AIMS scope and Statement of Applicability (SoA), and an estimate of the effort certification will take. Timeframes are short. A standalone ISO 42001 gap analysis usually takes one to three weeks, with a few days of consultant time and a modest internal commitment: stakeholder interviews, access to documentation, and someone who can describe how AI is actually used across the business. Standalone assessments on the market typically run in the low four figures. Axipro bundles one into its free 30-day Compliance Accelerator Plan, so in practice you can get the diagnostic without spending anything. A gap analysis is the right entry point when you already have governance maturity to build on. Companies with an existing ISO 27001 ISMS often find heavy overlap in the management system clauses, since both standards follow the same Plan-Do-Check-Act (PDCA) structure. It also fits when you have internal compliance expertise to execute the roadmap, when budget needs phasing, or when you want an accurate scope before committing to a bigger project. Insider Note: The step that consistently takes longer than anyone expects is the AI system inventory. Most companies walk into a gap analysis confident they know where AI is used, then discover marketing has been running LLM tools on customer data, and engineering has embedded a third-party model nobody scoped. Budget real time for discovery before the control review starts. What Is ISO 42001 Full Implementation Support? Full implementation support is an end-to-end engagement that takes you from your current state to certification readiness. The consultant identifies the gaps, then closes them with you, building the AIMS piece by piece and owning the project through to the external audit. The deliverables list is long. A typical engagement covers the AI policy and governance framework, an AI risk assessment methodology, completed AI risk assessments and AI impact assessments for your in-scope systems, the Statement of Applicability, the applicable Annex A controls put in place (data governance, human oversight, transparency, and so on), the documentation and evidence set an auditor will ask for, staff training, an internal audit, a management review, and corrective action plans for whatever the internal audit surfaces. Most providers, Axipro included, also coordinate directly with the accredited certification body through the Stage 1 and Stage 2 audits. Most organizations need roughly three to six months. It’s shorter where an ISO 27001 ISMS already exists to integrate with, longer for complex or high-risk AI portfolios. Consultant involvement is heavy and sustained, but your team doesn’t disappear from the project. Internal subject-matter experts still make the real decisions about AI use cases, data handling, and acceptable risk. On cost, consultant-led ISO 42001 implementations commonly run well into five figures. Axipro’s ISO 42001 readiness engagement costs $4,500, which is one of the reasons the honest comparison below matters: at that price, the “just buy the gap analysis to save money” logic gets a lot weaker. Full implementation is the right call when you’re starting an AIMS from scratch, when nobody internal can carry the workload, when a certification deadline is fixed by an enterprise deal or regulatory exposure, or when your AI use cases are risky enough that getting the controls wrong has real consequences. The EU AI Act’s requirements for high-risk AI systems entered into application in August 2026, and companies in that category rarely get the luxury of a slow, self-paced build. Key Differences Between the Two Services Scope and depth A gap analysis assesses; implementation support executes. The gap analysis stops at the roadmap, no matter how detailed. Implementation carries every roadmap item through to a working, evidenced control. That distinction sounds obvious, but it’s the single most common source of buyer disappointment: a gap report doesn’t make you certifiable, and some companies find that out only after they’ve scheduled a Stage 1 audit. Consultant involvement and internal effort In a gap analysis, the consultant works in short, concentrated bursts and your team’s effort is measured in hours of interviews and document gathering. In full implementation, the consultant drafts, builds, and project-manages, yet your team still spends real time reviewing policies, making risk decisions, and generating evidence. Any provider promising certification with zero internal effort is describing a paper AIMS that won’t survive an audit or an incident. Cost and time to readiness A gap analysis finishes