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.

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.

Our Services

G2 Clients Trust AxiPro

Trusted by clients on G2, Axipro stands out for real support, clear communication, and fast results. Our clients’ stories show how we simplify compliance and build lasting trust through genuine partnerships.

Pricing Plans

Choose the perfect plan

Transparent pricing for every stage of your compliance journey.

Compliance Accelerator Plan (CAP)

DIY Starter

Free for 30 Days

Try our compliance services free for 30 days.

What’s included
MOST POPULAR

Achievement Plan (AP)

End-to-end implementation with guaranteed certification.

Startup Package
Starting from $4,000 USD

Less than 50 employees

Growth Package
Starting from $5,000 USD

More than 50 employees

SOC 2
ISO 27001
Everything in CAP, plus

Trust Assurance Plan - (TAP)

Ongoing Compliance Maintenance and Support.

Starting from $500 USD

Monthly subscription

Continuous Support:
Outcomes

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

100 %
Certification Success Rate
6 Weeks
Average Time to Certification
$104M+
Revenue Unlocked for Our Customers

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

When a partner pays for itself

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

For Narva Software, SOC 2 wasn’t just a checkbox, it was about winning trust. Learn how Axipro helped them get audit-ready faster, without disrupting their business.

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.

Contact Us

Prefer to talk directly?

Schedule a quick call with one of our compliance experts to discuss your requirements and next steps.

USA

18121 E Hampden Ave, Unit C #1320 Aurora CO 80013

Bahrain

Block 115, Road 1527, Building 2004, Flat 2229, Hidd Kingdom of Bahrain

UK

Office 13422 182-184 High Street North East Ham, London, United Kingdom, E6 2JA

Portugal

Rua Luis Pinto Moitinho, 7, 1170-201, Lisbon

Compliance Without the Headache.

Ready to start? Get a quote in less than 24 hours.

Latest from the Blog

HIPAA and GDPR are the two most consequential data protection frameworks any healthcare or technology organisation is likely to encounter. They share a common purpose, protecting sensitive personal data, but they differ significantly in scope, enforcement mechanisms, and compliance obligations. For organisations operating across the Atlantic, understanding where they align, where they clash, and how to satisfy both simultaneously is not optional. It is a legal necessity. What Is HIPAA? The Health Insurance Portability and Accountability Act was enacted by the U.S. Congress in 1996. Its original purpose was to modernise the flow of healthcare information and ensure the portability of health insurance coverage. Over time, it became primarily known for its data protection requirements, administered by the U.S. Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR). HIPAA is built around three core rules. The Privacy Rule governs how Protected Health Information (PHI) may be used and disclosed. The Security Rule sets standards for safeguarding electronic PHI (ePHI). The Breach Notification Rule establishes mandatory reporting timelines when PHI is compromised. Who Needs to Be HIPAA Compliant? HIPAA applies to covered entities, healthcare providers, health plans, and healthcare clearinghouses, and to their business associates: any third-party organisation that handles PHI on their behalf. If you build software that processes patient data for a U.S. hospital, you are a business associate. If you store medical records in the cloud for an insurance company, you are a business associate. A Business Associate Agreement (BAA) is the formal contract that governs this relationship. What Types of Data Does HIPAA Protect? HIPAA protects Protected Health Information (PHI): any individually identifiable information relating to a person’s past, present, or future physical or mental health condition, the provision of healthcare, or the payment for healthcare. This includes names, dates of birth, Social Security numbers, medical record numbers, and any data that could be used to identify a patient in connection with their health. Electronic PHI, the subset stored or transmitted digitally, is subject to the Security Rule’s additional technical requirements. What Is GDPR? The General Data Protection Regulation came into force across the European Union on 25 May 2018, replacing the 1995 Data Protection Directive. It is the world’s most comprehensive data privacy law, and its extraterritorial reach means it extends well beyond Europe’s borders. The GDPR is enforced by national Data Protection Authorities (DPAs) and coordinated at the European level by the European Data Protection Board (EDPB). Unlike HIPAA, GDPR is not sector-specific. It applies to any organisation processing the personal data of EU residents, regardless of industry. Who Needs to Be GDPR Compliant? Any organisation that processes the personal data of individuals located in the European Union, regardless of where the organisation is based. A U.S. hospital treating European patients, a SaaS company offering services to German users, or a health app collecting data from French residents all fall within GDPR’s scope. The regulation applies to both data controllers (organisations that determine how and why data is processed) and data processors (third parties that process data on a controller’s behalf). What Types of Data Does GDPR Protect? GDPR protects all personal data: any information relating to an identified or identifiable natural person. Health data is explicitly designated a special category under GDPR Article 9, commanding heightened protection alongside biometric data, genetic data, racial or ethnic origin, religious beliefs, and sexual orientation. HIPAA vs GDPR: Key Differences at a Glance Feature HIPAA GDPR Jurisdiction United States only EU + extraterritorial reach Sector Healthcare only All sectors Regulatory body HHS / OCR National DPAs / EDPB Data covered PHI only All personal data Consent model Treatment-based exceptions Explicit consent required Breach notification 60 days (proposed: 72 hours) 72 hours Max fine $1.9M per violation category/year €20M or 4% of global turnover DPO required No Sometimes Right to erasure Limited Yes Scope and Geographic Reach HIPAA’s reach is defined by entity type: it applies to covered entities and business associates operating within the United States. Whether a patient holds EU citizenship is irrelevant to HIPAA jurisdiction. What matters is whether the organisation providing care or processing health data operates within the U.S. healthcare system. GDPR’s reach is defined by the location of the data subject, not the organisation. Article 3 of the GDPR gives it explicit extraterritorial effect. If your organisation targets or monitors EU residents, GDPR applies, regardless of where you are headquartered, where your servers are located, or what industry you operate in. Types of Data Protected: Personal Data vs Protected Health Information (PHI) This is the sharpest structural difference between the two frameworks. HIPAA is focused exclusively on health data in the context of healthcare delivery or payment. GDPR covers all personal data, from email addresses and IP addresses to medical records and genetic profiles. Health data under GDPR is a subset of the broader personal data category, not the totality of it. An organisation that is fully HIPAA-compliant may still be in violation of GDPR if it mishandles employee data, marketing data, or website analytics. Legal Basis for Data Processing GDPR requires organisations to identify a valid legal basis before processing any personal data. For health data, that typically means explicit consent or one of the specific derogations in Article 9(2), such as processing necessary for medical diagnosis or the provision of healthcare. This is a meaningful threshold; pre-ticked boxes, bundled consent, or vague terms of service do not meet GDPR’s standard. HIPAA takes a different approach. It permits covered entities to use and disclose PHI for treatment, payment, and healthcare operations without obtaining patient consent. Authorisation is required only in specific circumstances, such as disclosures for marketing purposes or release of psychotherapy notes. Important: GDPR’s explicit consent requirement creates real friction for U.S. healthcare organisations treating EU patients. A hospital cannot rely on its standard HIPAA-compliant intake forms to satisfy GDPR. The legal bases must be documented separately, and consent forms must meet the GDPR’s granularity requirements. Regulatory Authority and Enforcement HHS OCR is

31% of organizations have caught former employees accessing SaaS applications after their departure (source). Seventy percent of intellectual property theft happens in the ninety days surrounding a resignation announcement. The pattern is so consistent that auditors now treat termination day as one of the highest-risk windows on the security calendar. This article is a working employee offboarding checklist for IT, security, and HR teams who want to close that window cleanly. It walks through ten steps that revoke access without leaving gaps, then covers edge cases (remote workers, hostile exits, lost devices), the manual-versus-automation tradeoff, and post-offboarding monitoring. Use it as a baseline and adapt it to your environment. What Is Employee Offboarding and Why Does Access Revocation Matter? Employee offboarding is the structured process of separating a person from an organization: removing their access, recovering company property, documenting their exit, and updating records. The access revocation piece is the part where most programs fail quietly. Accounts get disabled in the identity provider but stay active in a dozen SaaS tools. Badges get collected but VPN tokens stay valid. The person is gone; the keys to the building are not. Why Employee Offboarding Is a Critical Security Risk Offboarding fails because access has multiplied faster than the processes designed to manage it. The average enterprise now operates somewhere between 275 and 660 SaaS applications depending on size, with employees touching dozens of them each week. Each application is a separate place that needs to be cleaned up, and each one creates an independent point of failure. The departing employee is a particularly acute version of this risk because the motivation to walk away with something often peaks during the same window that access is supposed to be revoked. The Cost of Leaving Access Open After Departure The financial picture is well documented. The 2025 Ponemon Cost of Insider Risks report puts the average annual cost of insider-related incidents at $17.4 million per organization, with containment taking an average of 81 days. Even when a departed employee never actively misuses their access, the existence of a forgotten account is enough to compromise a SOC 2 audit, trigger a breach notification, or create the credentialed beachhead that an outside attacker eventually exploits. The cases keep appearing. Cash App was breached in 2022 when a former employee accessed the records of 8 million customers after leaving. In May 2024, FinWise Bank disclosed that a former employee accessed internal systems after departure because access had never been fully revoked. Intel sued a former engineer in 2024 for downloading roughly 18,000 sensitive files in the days before he left. Ponemon’s 2025 report found that containment costs scale steeply with time. Incidents resolved in under 30 days averaged about $11 million, while those over 90 days averaged $17 million. The biggest variable is not detection capability. It is how fast access actually came down on day one. Compliance and Legal Implications of Incomplete Offboarding Access revocation is not a “best practice.” It is an explicit control requirement in nearly every framework against which an organization is likely to be audited. NIST SP 800-53 control PS-4 requires that on termination, organizations disable system access within an organization-defined time period, terminate or revoke any authenticators, and retrieve organizational property. ISO/IEC 27001 includes equivalent expectations under its Annex A controls for termination of employment. The AICPA Trust Services Criteria for SOC 2 cover this under Common Criteria CC6.2 and CC6.3, and auditors routinely pull a sample of terminated employees and verify timestamps in the identity provider against the HR system. GDPR adds a separate dimension. If a former employee still has access to the personal data of EU residents, that constitutes unauthorised processing under Article 32, and it is the controller’s responsibility, regardless of intent. HIPAA does the same for protected health information. Whatever the framework, the question an auditor or regulator will ask is the same: how quickly was access revoked, and can you prove it? Who Is Responsible for Employee Offboarding? Offboarding fails most often because no one owns the whole process. Four groups need to be in the loop, and each one has a distinct job. HR and People Operations HR is the source of truth for the termination event. Their job is to capture notice of departure, set the official last day, communicate timing to the rest of the business, and serve as the trigger that starts every downstream task. If HR does not record the termination in the HRIS, nothing automated will fire. IT and Security Teams IT executes the access teardown. They disable accounts in the identity provider, revoke SSO and OAuth tokens, remove SaaS application access, suspend email, and recover devices. Security teams typically run the audit trail and post-offboarding monitoring, and they are the ones answering when an account flagged six months later turns out to belong to a person who left in March. Legal and Compliance Legal handles NDA reminders, IP assignment confirmations, non-disclosure obligations, and any contractual surprises. Compliance owns the documentation: the evidence trail that proves the offboarding actually happened and met the relevant control requirements. For regulated industries this becomes audit evidence; for everyone else it becomes legal cover. Direct Managers Managers know things HR does not. They know which shared drives the person owned, which third-party vendors they had standing access to, which client passwords they may have rotated themselves, and which projects need a transition plan. A solid offboarding process forces the manager into the workflow with a checklist of role-specific items, because no central team can guess them. Employee Offboarding Checklist: 10 Steps to Revoke Access Without Leaving Gaps This is the core sequence. The order matters: starting with notification and inventory before disabling accounts means you do not lock the person out of a system you still need them to hand off. Step 1: Initiate Offboarding Immediately Upon Notice of Departure The moment notice is given — resignation, termination decision, or end of contract — the offboarding workflow should start. This means

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

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.

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.

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.

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.

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.

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.

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.

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.