Vanta automates the process. Axipro makes sure you pass.
We’re a Vanta implementation partner that gets SaaS, fintech, and cloud companies SOC 2, ISO 27001, and HIPAA certified in 6 weeks, with a 100% audit pass rate.
- Vanta Partner
- CREST Certified
- ISO 27001 Certified
Trusted by 4,000+ companies
How the Axipro × Vanta Accelerator Works
Vanta gives you the platform. Axipro gives you the team that runs it. Together, you go from no compliance program to audit-ready in six weeks — with one project plan, one point of contact, and one guaranteed outcome.
1- Scope & gap analysis
We map your business against your target framework (SOC 2, ISO 27001, HIPAA, GDPR) and identify exactly what’s missing
2- Set up Vanta
Policies, controls, integrations, and evidence collection — all configured inside your Vanta workspace.
3- Implement Controls
150+ controls implemented across people, processes, and technology, with hands-on guidance from a dedicated GRC PM and security analyst.
4- Internal audit & remediation
We run the internal audit ourselves, find the gaps before the external auditor does, and close them.
5- External audit coordination
We manage the external auditor relationship end-to-end. You pass. Guaranteed.
Pricing Plans
Choose the perfect plan
Transparent pricing for every stage of your compliance journey.
Compliance Accelerator Plan (CAP)
DIY Starter
Try our compliance services free for 30 days.
- Onboarding and Assessment
- Policies and procedures
- Gap analysis
- System description / statement of applicability
- Tabletop exercise
Achievement Plan (AP)
End-to-end implementation with guaranteed certification.
Less than 50 employees
More than 50 employees
- Timeline: 6 weeks
- Guaranteed
- End to End Implementation
- Dedicated Project Manager
- Facilitating External Audits
- 100% Guaranteed Certification
- Virtual Information Security Team
- Post-Certification Support
Trust Assurance Plan - (TAP)
Ongoing Compliance Maintenance and Support.
Monthly subscription
- Cancel anytime
- Monthly compliance maintenance
- Trust center updates
- Policy creation & refinement
- External audit coordination
- vCISO services
- No headache compliance maintenance
- Human-supervised automated processes
- Ten's of hours per week saved
Axipro was instrumental in helping us reach our compliance goals. They simplified the entire process and made it far easier for us to stay organized and confident. They are responsive, knowledgeable, and make compliance feel manageable.
– CEO, Noon AI
Compliance Without the Headache.
Not sure if you need a partner? Book a free 30-minute scoping call.
Do You Need Just Vanta, or Vanta Plus a Partner?
When you can run it yourself
- You have an in-house lead who has run SOC 2 or ISO 27001 before.
- Your environment is straightforward and your team is small.
- You have 5+ months before your deadline.
- It's a renewal, not a first-time certification.
When a partner pays for itself
- Your engineers can't afford to lose 200+ hours to compliance work.
- It's your first certification and a mistake costs more than the fee.
- A customer deal is blocked and you need to move in weeks.
- You're running multiple frameworks at once.
- Your environment is complex: multi-cloud, regulated, or a large team.
OUR FRAMEWORKS
Frameworks We Implement with Vanta
SOC 2 Type I & II · ISO 27001 · HIPAA · GDPR · PCI DSS · NIST CSF · CMMC · DORA
SOC 2 Type I & Type II
Our most common Vanta engagement. We handle scoping, control mapping, evidence configuration, and audit coordination. Typical timeline: 6 weeks to audit-ready.
ISO 27001
We guide you through Annex A controls, Statement of Applicability, and certification body coordination, all managed within Vanta’s ISO 27001 module.
HIPAA
For digital health and healthtech companies, we configure Vanta’s HIPAA controls and conduct risk assessments aligned to the Security Rule.
GDPR
We map Vanta’s controls to GDPR requirements and help you build a defensible data protection framework for EU operations.
NIST CSF
We align your Vanta controls to NIST Cybersecurity Framework categories for organizations needing federal or enterprise-grade security posture.
Also supported
PCI DSS, CMMC, DORA, ISO 9001, ISO 13485, ISO 14001, ISO 22000, ISO 45001, R2, SOX.
Latest Case Studies
Product ISO 27001 Industry Authentication Company Size 2-10 employees Location Denmark, Højbjer Partner Prescient Security Introduction In digital identity management, trust is everything. Sensitive user data moves through every authentication and authorization flow. Because of this, FoxIDs, a privacy-first identity platform based in Europe, decided it was time to pursue ISO 27001 compliance. FoxIDs delivers secure, developer-focused identity services that improve how organizations manage access and authentication. As the company grew, it required security governance that matched its level of innovation. The mission was clear: to keep identity services seamless while maintaining user data safety. To reach this goal, FoxIDs partnered with Axipro as its advisory partner. They used Drata for automation and worked with Prescient Security as the audit partner. Together, they set an ambitious target: reach ISO 27001 certification in less than 2 months. This required focus, coordination, and proven expertise. About FoxIDs FoxIDs is changing how European companies manage secure, privacy-first digital identity. The platform is built for developers who need smooth integration and support for OAuth 2.0, OpenID Connect, and SAML 2.0. The platform supports complex identity needs and gives organizations full control over data. It also strengthens transparency and helps teams stay GDPR-aligned. Workflows that once required complex setups now run faster and with less friction. As FoxIDs expanded across Europe and beyond, so did its responsibilities. Handling sensitive identity data meant that ISO 27001 compliance was more than a regulatory step. It was a promise to every client: their data would remain secure, private, and protected. Challenge: Scaling Security with a Lean Team FoxIDs wanted to strengthen trust with clients while managing sensitive identity data. With a team of only two people, they needed a process that kept internal workload low but still gave them full ownership of the ISMS. Much of their Drata dashboard was already in place. However, key elements such as the SOA, risk assessments, management reviews, and BCDR still needed work. Explore how Axipro supports ISO 27001 readiness Read more Solution: Advisory & Audit Partnership FoxIDs partnered with Axipro to guide them through compliance step by step. Together, they built a simple roadmap. It included developing missing policies, completing risk assessments, and preparing the team for the audit. Drata powered automation for evidence collection and control monitoring. This reduced manual work and made progress easy to track. The FoxIDs compliance lead stayed engaged and provided evidence fast, which helped ensure strong internal ownership. Prescient Security supported FoxIDs as the audit partner. Minor reporting updates were handled quickly, and the audit closed successfully. Here’s what Anders Revsgaard, Owner of FoxIDs, shared about working with Axipro: Excellent Support Getting ISO 27001 Done! Axipro provided outstanding support throughout our ISO 27001 certification process. Results: ISO 27001 Compliance That Elevated Trust and Security FoxIDs reached a major milestone in only 8 weeks: full ISO 27001 compliance. Here’s what it delivered: A recognized ISO 27001 certification proving their commitment to privacy-first identity management. Stronger trust and confidence from clients and partners across Europe. Improved visibility and control over security risks through Drata automation. A streamlined ISMS that is simple for the small team to maintain. For FoxIDs, certification was not only a requirement. It reinforced their commitment to secure, reliable, and transparent identity solutions. Why FoxIDs Chose Axipro FoxIDs chose Axipro because they needed a partner who could move fast, communicate clearly, and remove complexity from compliance. Top Drata Gold Partner in EMEA: Axipro’s automation expertise helped FoxIDs use Drata to its full potential. Fast, Clear Communication: Short timelines required quick decisions, and Axipro kept the project moving. Guidance from Start to Finish: From roadmap design to audit readiness, Axipro ensured every step was covered Ready to Strengthen Trust with ISO 27001 Compliance? ISO 27001 compliance helped FoxIDs increase client trust, reinforce its credibility, and raise the standard for data protection. Your company can achieve the same. Axipro helps fast-growing companies simplify compliance without slowing down innovation. With clear milestones, Drata automation, and trusted audit partners, we make ISO certification practical and achievable. At Axipro, we help businesses navigate the certification journey, reduce risks, and strengthen trust with clients. Book a call
Serving Clients Globally
Axipro delivers Vanta implementation services to companies across the US, UK, Europe, GCC and APAC.
For UK and EU-based organizations, we bring specific expertise in ISO 27001 and GDPR requirements alongside SOC 2 readiness, ensuring your compliance program meets both international and regional standards.
Compliance Without the Headache.
Ready to start? Get a quote in less than 24 hours.
Latest from the Blog
The Drata Agent is the part of Drata’s compliance stack that actually touches employee devices. It is a lightweight, read-only desktop application that runs in the system toolbar, reads a narrow set of security configuration settings, and reports them back to the Drata platform on a daily schedule. If a SOC 2 or ISO 27001 audit depends on showing that every endpoint has disk encryption, screen lock, antivirus, a password manager, and automatic updates enabled, the Agent is the thing that produces that evidence. This guide covers exactly what it does, how it works, how to install it on macOS, Windows, and Linux, and what to do when it stops syncing. What Is the Drata Agent? The Drata Agent is a desktop application built with Electron, the same framework used by Slack, VS Code, and Discord. It uses osquery, an open-source endpoint instrumentation tool created at Facebook and now maintained as a Linux Foundation project, to query the operating system for specific configuration values. The Agent runs from the system toolbar — the menu bar on macOS, the system tray on Windows, and the indicator area on Linux — and synchronises once per day with Drata’s backend. The full source code of the Agent has been open source since June 2023. Anyone can audit the code on Drata’s GitHub organisation, including security teams that need to validate it before deploying to the fleet. The Agent supports the latest two major versions of each operating system. On macOS, that currently means macOS 26 (Tahoe) and macOS 15 (Sequoia), with Agent version 3.9.0 or higher. On Windows, it covers the two most recent stable versions Microsoft actively maintains. On Linux, only LTS distributions are supported; Ubuntu 22.04 LTS and 24.04 LTS are the current supported targets. What the Drata Agent Does (and Does Not Do) The Agent collects a tightly scoped list of configuration data points — specifically the items that map to typical SOC 2 and ISO 27001 device-level controls. The Agent does read: disk encryption status (FileVault, BitLocker, LUKS); screen lock and screensaver configuration; installed antivirus or endpoint protection software; installed password manager applications; operating system version and update status; the list of installed applications and browser extensions for Chrome, Firefox, and Internet Explorer (used to detect AV and password manager presence); and the operating system identifier and machine serial number for asset attribution. The Agent does not read keystrokes, browsing history, file contents, clipboard data, screen contents, network traffic, or any application data. Access is strictly read-only at the system-preferences level. The Agent cannot make changes to the device, push configuration, or remediate failed controls. If a check fails, the employee or IT team fixes it manually; the Agent simply observes whether the fix worked on the next sync. Important: Read-only does not mean invisible. The Agent enumerates installed applications and browser extensions to detect antivirus and password manager presence, and this list is sent to Drata. If that level of visibility is a concern for privacy or works council requirements, address it before rollout — not after. How Does the Drata Agent Work? Once installed and registered, the Agent runs continuously in the background. It performs scheduled checks, reports results to Drata, and updates itself when new versions ship. Synchronization Process The Agent syncs once per day. The sync runs at the first opportunity each calendar day: typically, the first network connection after the device was off or asleep, the moment the user logs in if the Agent autostarts, or any manual trigger from the toolbar menu. The data sent is small — a structured report of the configuration values the Agent read, plus the Agent version and machine identifier. There is no telemetry of user activity. When the sync succeeds, the device’s compliance status in Drata updates within a few minutes. When it fails, the device may show an Unable to get data status, and the corresponding controls in Drata will appear unconfirmed until the next successful sync. Automatic Updates The Agent updates itself. When a new version is released, the Agent shows a notification asking the user to allow the update. Updates are mandatory — running an outdated Agent eventually causes registration and sync failures. Linux installations through Ubuntu’s package manager auto-update via the system updater starting with version 3.6; AppImage installations and Arch AUR builds need to be updated manually or through the AUR helper. Prerequisites Before Installing the Drata Agent Before installation, three things need to be in place. First, the device user needs an active Drata account with employee onboarding tasks assigned. Second, the operating system must be a supported version. Third, the user needs administrator rights on the device to install the application, since it registers a startup item. The user will also need access to their work email during installation. Registration uses a magic-link verification flow, and the verification email arrives within a minute of clicking Register Drata Agent in the Drata UI. How to Install the Drata Agent on Mac There are two practical paths on macOS: install through Homebrew Cask, or download the signed installer directly from MyDrata. Installation via Homebrew The Drata Agent is published as an official cask in the Homebrew repository, which is the cleanest install method for engineers who already use Homebrew for package management. The cask requires macOS 12 (Monterey) or newer. The install command is: brew install –cask drata-agent After Homebrew finishes, open Drata Agent.app from /Applications, then return to MyDrata and click Register Drata Agent. A magic-link email arrives shortly after. Open the link, copy the token portion of the URL, paste it into the Agent’s register dialog, and confirm. Run or Build the Drata Agent on Mac For organisations that want to build from source rather than use the published package, the GitHub repository contains the full Electron build pipeline. Build prerequisites include Node.js and electron-builder, and the osquery binaries need to be supplied separately. Drata explicitly notes that locally built packages are not signed and that production registration requires an
Most SOC 2 auditors will pick a handful of recent hires from your employee list and request one specific artifact: the completed background check, dated before the start date, sourced from a documented vendor. If you cannot produce it, that is an exception in your report. The control sits inside CC1.4, the Common Criteria provision the AICPA derives from COSO Principle 4, and it is one of the most reliably tested items in a first-year SOC 2 examination. Background screening is not the most technically complex part of SOC 2. It is, however, one of the most procedurally fragile. The policy looks simple on paper. Then a contractor starts a week early because someone needed help shipping a release, the vendor screening gets postponed, and a year later an auditor finds the gap in twenty minutes. This guide explains what SOC 2 actually requires when it comes to background checks, what auditors look for in practice, and how to build a screening programme that holds up under sampling. What Is a SOC 2 Background Check? A SOC 2 background check is the pre-employment screening a service organisation performs to verify that the people it hires can be trusted with access to systems and data inside the SOC 2 scope. It is the operational evidence that supports the abstract principle baked into the Trust Services Criteria: the organisation hires competent people of sound integrity, and it can prove it. In practice, that means a documented check performed by a third party that returns verified information about identity, criminal history, employment history, and, depending on the role, education and credit. The check is run against every new hire before they get logical or physical access to systems within scope. The result is stored, mapped to a named employee, and retrievable on demand. It is worth being clear on one thing: SOC 2 does not prescribe what a background check must contain. The AICPA criteria describe outcomes, not procedures. Your policy is what defines what gets checked, on whom, and how often. The auditor then tests whether you followed your own policy. Why SOC 2 Background Checks Are Important Insider risk is one of the few attack vectors that perimeter security cannot fix. An employee or contractor with legitimate credentials and undisclosed motives sits inside the network from day one. Background checks are how mature security programmes reduce the probability of that scenario before it begins. According to the Verizon 2024 Data Breach Investigations Report, insider threats continue to represent a persistent and costly category of security incidents, reinforcing why personnel vetting remains a foundational control. Auditors care for a related reason. The Control Environment criteria (CC1) sit at the top of the SOC 2 framework because everything else rests on the assumption that the people running the controls are competent and trustworthy. Skip the screening step, and the rest of the audit is built on a weaker foundation. That is why background check evidence is one of the first things auditors sample, and why a missing or late check shows up as an exception even when the rest of your control environment is strong. Insider Note: Auditors do not just check that the screening happened. They check the timing. A background check completed two months into employment is often treated the same as no check at all, because access to in-scope systems was granted before the control was operative. Time stamps matter as much as the document. SOC 2 Background Check Requirements Which Trust Service Criteria Require Background Checks? Background checks are explicitly referenced in the Common Criteria that apply to every SOC 2 engagement, regardless of which optional Trust Services Categories you include. The two controls that matter most are CC1.1 and CC1.4. CC1.1 establishes the entity’s commitment to integrity and ethical values. Background checks support this by demonstrating due diligence in selecting people who meet the organisation’s standards of conduct. CC1.4 is more direct: it derives from COSO Principle 4, which states that the entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. Within CC1.4, evaluating individual backgrounds is named as a specific point of focus. That is the hook auditors use. Because these are Common Criteria, they apply regardless of whether you are scoping Security only or adding Availability, Confidentiality, Processing Integrity, or Privacy. There is no version of SOC 2 that escapes them. Who Needs to Be Background Checked for SOC 2? The short answer: anyone whose role gives them logical or physical access to systems, data, or facilities within your SOC 2 scope. The longer answer requires you to draw the line in your own policy and stick to it. At a minimum, this includes full-time employees who join the organisation after the policy is in place. Most mature programmes extend the requirement to part-time employees, contractors who receive credentials, and outsourced personnel performing in-scope work. Vendors are usually handled differently — through contractual flow-down requirements rather than direct screening — but the principle is the same: people inside the trust boundary must be vetted. Roles with privileged access (engineers with production credentials, finance staff with payment system rights, support personnel handling customer data) often warrant deeper screening than baseline roles. Documenting this risk-based approach in your policy is good practice and helps you defend the design of your control during the audit. What Types of Checks Must Be Performed? The Trust Services Criteria do not specify which checks to run. That decision sits with the organisation, informed by role, jurisdiction, and regulatory context. A common baseline for SOC 2 purposes covers several distinct areas. Identity verification confirms the candidate is who they claim to be. Criminal history — national, state, or county-level depending on jurisdiction — flags relevant offences. Employment verification confirms the work history disclosed during hiring. Education verification matters for roles where credentials are material. For positions touching finance, payments, or fiduciary responsibility, a credit check may be appropriate. For roles with global reach, a global
The AICPA never wrote the words penetration test required into SOC 2. Yet a service organization that walks into a Type II audit without one is almost guaranteed to leave with findings, follow-up questions, or a delayed report. That gap, between what the standard technically demands and what auditors operationally expect, is where most companies trip. This article breaks down the real SOC 2 penetration testing requirements: where they sit in the Trust Services Criteria, what auditors look for during Type I and Type II engagements, how often you should test, and what a good pen test report needs to contain to satisfy your auditor without inflating your budget. Understanding SOC 2 and Its Security Expectations What Is SOC 2? SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that handle customer data. Unlike a certification, SOC 2 is an opinion: a licensed CPA firm reviews your security controls and issues a report stating whether those controls are designed (Type I) or operating (Type II) effectively. SOC 2 reports are read by enterprise procurement teams, security reviewers, and risk officers. Most B2B SaaS contracts in 2026 require one before signing. What Controls Does SOC 2 Require? Rather than dictating specific technologies, SOC 2 requires that you design and operate controls that demonstrably meet each criterion under the Trust Services Criteria (TSC). That gives you flexibility, and it also gives auditors latitude to ask hard questions. Does SOC 2 Require Penetration Testing? The Official SOC 2 Position on Penetration Testing The phrase penetration test appears in the AICPA’s 2017 Trust Services Criteria publication (with 2022 revisions) inside a single Point of Focus under CC7.1, the Common Criterion that requires entities to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. The Point of Focus suggests management uses a variety of ongoing and separate risk and control evaluations to determine whether controls function. Penetration testing is named as one option. That is the entire textual basis. There is no clause that mandates an annual external pentest, no specification of scope, no required methodology. Short Answer: There Are No Mandatory SOC 2 Pen Test Requirements You can technically obtain a SOC 2 report without a penetration test, provided you can show your auditor that you use alternative evaluations to satisfy CC4.1 (ongoing monitoring) and CC7.1 (vulnerability identification). In practice, almost nobody does this successfully. Long Answer: You Still Need SOC 2 Penetration Testing Auditors view penetration testing as the strongest available evidence that your controls work against a determined adversary, not just on paper. CC4.1 asks the entity to perform ongoing monitoring to ascertain whether internal controls are present and functioning; a pen test is the most direct way to evaluate that. CC6.1 asks whether logical access controls can be bypassed; a pen test answers that question directly. CC7.1 ties this together by requiring you to detect newly introduced vulnerabilities. If you skip pen testing, you carry the burden of proving your alternative evidence is at least as good. That is a steeper hill than most organizations realize. What Auditors Expect During Type I and Type II Engagements A SOC 2 Type I report assesses control design at a single point in time. A Type II report assesses operating effectiveness over a defined audit period, typically six to twelve months. Both increasingly assume a recent penetration test exists. For Type II especially, auditors expect the test to fall within the audit window, with documented remediation of any critical or high findings before the period closes. Auditors rarely refuse a Type II report over a missing pentest outright, but they will issue a finding or qualified opinion if they cannot validate CC4.1 evidence. That qualification will be read by every customer reviewing your report. Most CISOs would rather budget $15,000 for a pentest than try to explain a qualified opinion to a procurement team. What Are the Actual SOC 2 Penetration Testing Requirements? Alignment with Trust Services Criteria A pen test that supports a SOC 2 audit must map its findings to specific criteria. Most reputable pentest firms now produce a Trust Services Criteria mapping appendix that ties identified vulnerabilities back to CC4.1, CC6.1, CC7.1, and where relevant CC7.2 through CC7.4. Without that mapping, your auditor has to do the interpretive work themselves, which typically means a follow-up request and a slower report. Scope Definition Requirements Scope should match your SOC 2 system boundary, not your entire infrastructure. If your audit covers a single SaaS product, its API, and its AWS account, that is what should be tested. Auditors look for evidence that the pen test scope was derived from the system description in your SOC 2 report. A mismatch between the two is one of the most common causes of fieldwork delays. Testing Frequency and Timing Requirements SOC 2 does not specify a frequency. Annual testing has become the de facto standard, with additional testing after material changes to architecture, authentication, or hosting. For organizations on continuous deployment, some auditors now accept a combination of annual deep-dive testing and continuous automated assessment as sufficient coverage, but this should be confirmed with your auditor before you rely on it. Remediation Evidence Requirements Findings without remediation are findings against you. Auditors expect documented remediation plans for every critical and high-severity issue, with closed tickets, retest results, or compensating controls recorded before the audit period ends. A finding sitting open in a backlog at audit time is treated almost identically to a finding that was never addressed. Penetration Testing vs. Vulnerability Scans for SOC 2 Both belong in your control set, but they answer fundamentally different questions. Vulnerability scanning is automated and broad, it identifies known CVEs and misconfigurations across your environment quickly and consistently. Penetration testing is manual and adversarial, it simulates what a real attacker would do with the access and information they can obtain. CC7.1 explicitly references both, and your auditor
The CMMC program turned from advisory framework to binding contract requirement on November 10, 2025, when the DoD’s Title 48 acquisition rule took effect. That single date changed the market for CMMC advisory services overnight, and the Cyber AB Registered Practitioner credential moved from a useful business card to a genuine signal of competence. Over 80,000 companies in the Defense Industrial Base now need help interpreting the rule, and the RP is the formal entry-level role in the ecosystem authorized to provide it. This guide explains what a CMMC Registered Practitioner is, how the role fits alongside CCPs, CCAs, RPOs, and C3PAOs, what it takes to earn the designation, and how Organizations Seeking Certification (OSCs) should think about engaging one. What Is a CMMC Registered Practitioner (RP)? A CMMC Registered Practitioner is an individual authorized by the Cyber AB, the official accreditation body for the CMMC ecosystem, to provide non-certified advisory and consulting services to Organizations Seeking Certification. RPs help defense contractors interpret the CMMC model, scope their environments, build documentation, remediate gaps against NIST SP 800-171, and prepare for the formal assessment they will eventually undergo. The credential exists because the CMMC framework is genuinely dense. CMMC Level 2 maps to all 110 controls in NIST SP 800-171, and Level 3 layers on 24 selected requirements from NIST SP 800-172. Most contractors do not have the in-house expertise to implement these controls cleanly, and the Cyber AB needed a way to identify advisors who had at least demonstrated baseline knowledge of the program. An RP does not perform official assessments. That work is reserved for Certified CMMC Assessors (CCAs) operating under a C3PAO. The RP role is strictly advisory, and the Code of Professional Conduct that every RP must sign makes the boundary explicit. How RPs Fit Into the Broader CMMC Ecosystem The Cyber AB structures the ecosystem into two distinct lanes: consulting and implementation on one side, assessment and certification on the other. RPs sit on the consulting side. CCPs, CCAs, and C3PAOs sit on the assessment side. The two are kept deliberately separate so that no firm can audit work it helped configure, a separation that preserves the integrity of the certification process. Registered Practitioners vs. Certified CMMC Professionals (CCPs) The CCP is a more rigorous credential. CCP candidates must complete formal Cyber AB training delivered by a Licensed Training Provider, pass a commercial background check, and sit a proctored exam administered by CAICO. CCPs can participate in actual assessments as part of a C3PAO assessment team, though they cannot lead them. RPs cannot participate in assessments at all. In practical terms, the RP credential is the right starting point for consultants, MSPs, and internal compliance staff who want to demonstrate baseline CMMC fluency. The CCP is the right credential for professionals planning a career in CMMC assessment work. Registered Practitioners vs. C3PAOs A C3PAO (Certified Third-Party Assessment Organization) is the entity authorized to conduct official Level 2 certification assessments and issue formal CMMC status determinations. Fewer than 100 firms held C3PAO authorization as of early 2026, serving an ecosystem of more than 80,000 contractors. C3PAOs are companies. RPs are individuals. They do completely different jobs: the RP prepares the contractor, the C3PAO certifies them. Important: A C3PAO that helps a client implement controls is barred from later assessing that same client. This is a hard line in the Code of Professional Conduct. If you engage a firm for both readiness and certification work, you will end up paying two different organizations regardless, so plan accordingly from the start. What Does a CMMC Registered Practitioner Do? The work of an RP is the work of getting an organization to the starting line of a formal assessment without surprises. That includes interpreting which CMMC level applies to a given contract, scoping the CUI and FCI environments, identifying gaps against NIST SP 800-171, drafting the System Security Plan (SSP) and Plan of Action and Milestones (POA&M), advising on technical remediation, and coaching the OSC through mock assessments before the real one. Who Can a CMMC RP Help? RPs serve any organization in the Defense Industrial Base that needs to achieve a CMMC status. That includes prime contractors, subcontractors at any tier, MSPs, and MSSPs that handle CUI on behalf of defense clients, manufacturers, research universities, and civilian agency contractors whose departments have adopted CMMC-aligned clauses. The flow-down requirements in 32 CFR §170.23 mean that even small subcontractors who process Federal Contract Information (FCI) must hit Level 1, which keeps RP work relevant well past the first wave of large primes. What Services Does a CMMC RP Provide? The core service menu looks consistent across the market: gap assessments against NIST SP 800-171, scope definition, SSP and POA&M drafting, policy and procedure development, technical advisory on encryption, access control and incident response, and pre-assessment readiness reviews. Strong RPs also help clients interpret recent guidance changes, manage their SPRS score, and prepare evidence packages that will survive scrutiny from a C3PAO assessment team. Pro Tip: Evaluating a Registered Practitioner When evaluating an RP, ask whether they have walked a client through a full C3PAO assessment cycle, not just a gap assessment. There is a significant difference between consultants who write SSPs and consultants who have watched assessors actually challenge one. How to Become a CMMC Registered Practitioner The path is straightforward but not trivial. The Cyber AB controls the registration process end-to-end, and every step must be completed in order. Step 1: Complete the Required CMMC Registered Practitioner Training The RP training is delivered online through the Cyber AB’s learning management system. It covers the CMMC model document, the structure of the ecosystem, scoping methodology, FCI and CUI definitions, prime and subcontractor information flow, the assessment process, and the relationship between CMMC and existing DFARS clauses. The course typically takes around eight hours. Candidates should plan for roughly $500 to $600 in combined training and annual registration costs. Step 2: Register with the Cyber AB After training, candidates submit a
A single VS Code extension installed by a single GitHub employee has cost the world’s largest code host roughly 3,800 of its internal repositories. GitHub confirmed the breach in a five-post thread on X on May 20, 2026, attributing the compromise to a poisoned extension that ran on the employee’s machine and gave attackers a foothold inside Microsoft’s flagship developer platform. The threat group TeamPCP, already infamous for a string of supply chain attacks across npm, PyPI, and PHP packages earlier this year, has claimed responsibility on underground forums and is reportedly asking more than $50,000 for the stolen dataset. GitHub’s own assessment is that the attacker’s claim of around 3,800 exfiltrated repositories is directionally consistent with what investigators have found so far. The company says no customer data was touched. What GitHub Disclosed GitHub broke the news in a numbered thread of five short posts on X, with no entry on the official github.blog or githubstatus.com at the time of disclosure. The company said it detected the compromise of an employee device the previous day, removed the malicious extension version from the marketplace, isolated the affected endpoint, and rotated critical secrets overnight, prioritizing the highest-impact credentials first. “Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only,” GitHub wrote, adding that it would continue to monitor logs for follow-on activity and publish a fuller report once the investigation is complete. The phrasing is careful. Saying GitHub-internal repositories only rules out customer repos, enterprise tenants, and organization data hosted on the public platform, but it leaves open what was inside those 3,800 repos: deployment scripts, infrastructure configuration, API documentation, staging credentials, and the architectural blueprints of GitHub itself. Important Note “No customer data” does not mean “no customer risk.” Internal repositories at a platform like GitHub typically contain deployment topology, secret rotation logic, CI workflows, and references to third-party integrations. Even if no customer secrets are inside, the architectural knowledge alone meaningfully reduces the cost of attacking customers downstream. The Attack: A Trojanized Extension Inside a Trusted Marketplace GitHub has not yet named the specific extension. Security researchers tracking TeamPCP’s tradecraft note that the group has spent 2026 weaponizing exactly this surface, planting trojanized code in package registries and development tools that developers trust by default. The mechanism is brutally simple. A developer browses the VS Code Marketplace, installs an extension that looks legitimate, and grants it the same execution privileges as any other process running under their account. From there, the malware can read source files, exfiltrate Git credentials, harvest tokens from ~/.aws, ~/.kube, and password managers, and clone every repository the developer has access to. There is no permission model meaningfully limiting what an extension can do once it executes. A theme can do anything a debugger can do. Browser extensions get treated as a security boundary. IDE extensions, which see your source code, your credentials, and your terminal, do not. That asymmetry is the single largest unaddressed risk in the modern developer toolchain, and the GitHub incident is the most expensive demonstration of it to date. What GitHub Has Done, and What Comes Next The containment steps GitHub described are textbook: detect, isolate, rotate, monitor. The company says it removed the malicious extension version, took the developer’s machine off the network, and rotated the credentials most likely to provide further pivots. The investigation continues, and GitHub has committed to publishing a fuller report later. Where the response is less defensible is in disclosure. Announcing a breach of this scale exclusively on X, a platform that requires a login to view most posts, drew sharp criticism. As of publication, there is no entry on the GitHub Blog and no advisory on the official status page. Customers governed by frameworks such as DORA or NIS2, both of which have hard supplier-incident notification timelines, will be looking for something more substantive than a Twitter thread. Pro Tip: IDE plugins and Cyber Security Treat any IDE plugin like a piece of production software. Pin to specific versions, disable auto-updates on critical machines, restrict the allowed publisher list (in VS Code via the extensions.allowed setting), and ensure that any project containing credentials cannot be opened by an editor that auto-runs .vscode/tasks.json without confirmation. If you maintain CI/CD secrets, assume that any developer machine with both source access and an unverified extension installed is already in the threat model. For organizations downstream of GitHub itself, the immediate hygiene items are clear. Rotate any GitHub personal access tokens or OIDC credentials that were used in conjunction with packages from the TanStack, UiPath, Mistral AI, OpenSearch, or Guardrails AI namespaces during the early May window. Audit .vscode/ and .claude/ directories for files such as router_runtime.js or setup.mjs. Search for the gh-token-monitor daemon, which acts as a dead-man switch and triggers a destructive rm -rf on token revocation if not removed first. An Incident or a Pattern? GitHub has had a rough quarter on availability, with multiple outages drawing public complaints. A confirmed source-code breach by the most prolific supply chain threat actor of 2026 lands at the worst possible moment for that narrative. Independent agencies such as the Cybersecurity and Infrastructure Security Agency and NIST, through its Secure Software Development Framework, have been warning for years that developer tooling and build pipelines are the soft underbelly of every modern company, and the Wikipedia entry for supply chain attack now reads like a chronological list of escalating incidents. The deeper lesson from the GitHub breach is not that one employee made a mistake. It is that the security model of the modern developer workstation has not kept pace with the value of what sits on it. Until IDE extensions are sandboxed with explicit capability grants, until source code repositories are treated as sensitive assets rather than collaboration surfaces, and until the disclosure norms for breaches at platform-level vendors are tightened, the Mini Shai-Hulud playbook will continue to work. GitHub will not be the last victim of this campaign. It is simply, for
Plenty of companies treat an ISO 27001 certificate as proof of GDPR compliance. It is not. The two frameworks overlap heavily, but they answer different questions, and the gap between them is exactly where regulators tend to look. ISO 27001 tells you how to build a defensible security program. GDPR tells you what the law expects when that program touches personal data. Run one without understanding the other, and you will either over-engineer security you do not strictly need, or miss privacy obligations that carry real financial exposure. This article maps where ISO 27001 and GDPR meet, where they part ways, and how to run them as a single coordinated effort rather than two competing projects. What Is ISO 27001? ISO/IEC 27001 is the international standard for an Information Security Management System, or ISMS. The current edition is ISO 27001:2022. It is not a checklist of technical fixes. It is a management framework: a structured, repeatable way to identify information security risks, decide how to treat them, document those decisions, and improve over time. Clauses 4 to 10 of the standard define the mandatory ISMS requirements, covering leadership, risk assessment, internal audit, and management review. Annex A then lists 93 controls grouped into four themes: organisational, people, physical, and technological. You do not implement all 93 by default. You select the controls that address your assessed risks and justify your choices in a document called the Statement of Applicability. Certification against ISO 27001 is voluntary and is granted by an accredited third-party body after an audit. What Is GDPR? The General Data Protection Regulation is European Union law. It has been applied since 25 May 2018, and it applies to any organisation that processes the personal data of people in the EU, wherever that organisation is based. GDPR is fundamentally about the rights of individuals, not just the security of data. It grants people rights over their personal data, including access, correction, erasure and portability. It places obligations on the organisations that decide how data is used (controllers) and those that process it on their behalf (processors). It requires a lawful basis for every processing activity, mandates breach notification, and demands transparency about what happens to people’s information. You do not implement GDPR and receive a certificate. You obey it, and a regulator decides whether you have. Key Differences Between ISO 27001 and GDPR Scope and Purpose ISO 27001 protects all information assets an organisation holds: intellectual property, financial records, operational data, source code and, yes, personal data. Its purpose is the confidentiality, integrity and availability of information in general. GDPR is narrower in one sense and broader in another. It covers only personal data of individuals in the EU, but it protects the person behind the data, not merely the data itself. A system can be flawlessly secure and still violate GDPR. Legal Obligation vs. Voluntary Certification This is the difference that catches people out. GDPR is binding law. If you process EU personal data, compliance is not optional, and there is no opting out. ISO 27001 is a voluntary standard. Organisations pursue it for assurance, for competitive advantage, and because customers increasingly demand it. Crucially, there is no such thing as a GDPR certificate. Regulators assess compliance through investigation and enforcement, not through a badge you can display. Penalties for Non-Compliance GDPR fines run on two tiers under Article 83. Less severe infringements — such as failures around records of processing or breach notification — can reach €10 million or 2% of global annual turnover, whichever is higher. The more serious tier, covering breaches of the core processing principles and data subject rights, can reach €20 million or 4% of global annual turnover. Failing an ISO 27001 audit carries no legal fine at all. The consequence is commercial: you do not get the certificate, or you lose it, and that can cost you contracts. How ISO 27001 and GDPR Align Despite their different purposes, the two frameworks were built on compatible logic, which is why running them together works. Both treat information security as central. GDPR Article 32 requires “appropriate technical and organisational measures” to secure personal data. That phrasing is almost a direct description of what an ISO 27001 ISMS produces. The controls an organisation selects for confidentiality and access already serve the regulation’s security expectations. Both are risk-based. ISO 27001 starts every control decision from a risk assessment. GDPR expects the same proportionality: the measures you apply should match the sensitivity of the data and the likelihood and severity of harm. One risk methodology can serve both, provided you assess personal data processing risks alongside broader security risks. Both demand incident response. ISO 27001’s incident management controls require organisations to detect, assess and respond to security events. GDPR Article 33 requires notifying the supervisory authority of a personal data breach within 72 hours of becoming aware of it. The ISO process is the engine that makes the GDPR deadline achievable. How ISO 27001 Can Help You Comply With GDPR Four areas of an ISMS do direct, practical work toward GDPR compliance. Asset management. ISO 27001 requires an inventory of information and associated assets, with owners assigned. You cannot protect personal data, respond to access requests, or maintain records of processing if you do not know where that data lives. The asset inventory is the foundation for both frameworks. Access control. Identity management, privileged access controls and the principle of least privilege limit who can see personal data. That directly supports the GDPR requirement to ensure confidentiality and to prevent unauthorised access. Operational security. Logging, malware protection, backup and secure configuration keep personal data accurate, available and resistant to compromise. These map cleanly onto the integrity and availability expectations in Article 32. Techniques such as data masking for GDPR and ISO 27001 also sit within this space, reducing exposure without sacrificing operational utility. Incident management. A defined process for detecting and handling security events gives you the evidence trail and the response capability you need to
FAQ
Frequently Asked Questions
Do I need to already have Drata before working with Axipro?
No. If you’re already on Drata, we’ll work within your existing setup. If you haven’t chosen a platform yet, we can help you evaluate whether Drata is the right fit, handle onboarding, and configure it alongside your compliance program from day one. We also work with teams using other platforms, though our deepest expertise is with Drata.
How long does it take to get audit-ready?
A typical SOC 2 engagement takes around 6 weeks from kickoff to audit-ready. The exact timeline depends on your current security posture, the framework(s) you’re pursuing, and how quickly your team can action items on their side. During the free readiness assessment, we’ll give you a realistic timeline based on where you actually stand — not a generic estimate.
What frameworks does Axipro support?
We implement and manage compliance programs across SOC 2 Type I and II, ISO 27001, HIPAA, GDPR, PCI DSS, NIST CSF, CMMC, DORA, ISO 9001, ISO 13485, ISO 14001, ISO 22000, ISO 45001, R2, and SOX. If you need multiple frameworks, we build a unified program so you’re not duplicating effort across certifications.
What happens after we get certified?
Certification isn’t the finish line — it’s the beginning of an ongoing compliance obligation. Axipro offers continuous compliance management so your controls stay effective, your evidence stays current, and renewals don’t turn into fire drills. We can manage your program on an ongoing basis or support you only at renewal time, whichever fits your team.
What does Axipro actually do that Drata doesn't?
Drata automates evidence collection, control monitoring, and audit workflows, and it does that very well. What it doesn’t do is tell you whether your scope is right, whether your controls are appropriate for your business, or whether your evidence will survive auditor scrutiny. Axipro handles the judgment calls: scoping, control design, readiness validation, audit coordination, and remediation. Think of it as Drata runs the engine, Axipro makes sure you’re driving in the right direction.
Do we need to be in the same location?
Engagements are delivered however works best for you. Most clients work with us fully remotely, but we can accommodate hybrid or on-site arrangements depending on your needs and preferences.
Is there a minimum company size?
No. We work with pre-revenue startups preparing for their first SOC 2, mid-market companies adding ISO 27001 for enterprise sales, and established businesses managing multiple frameworks. The engagement is scoped to your size and complexity, not a one-size-fits-all package.
What does the free readiness assessment include?
It’s a 30-minute session where we review your current compliance posture, identify your biggest gaps, and give you a realistic timeline and scope estimate for certification. You’ll walk away with a clear picture of what’s needed — whether you work with us or not. No commitment, no sales pressure.