Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ISO 27001 Gap Analysis: A Step-by-Step Guide to Strengthening Your Information Security

ISO 27001 Gap Analysis: A Step-by-Step Guide to Strengthening Your Information Security

 

Securing sensitive information is a critical priority in today’s data-driven world. Achieving ISO 27001 certification, an international standard for information security demonstrates a robust commitment to safeguarding data. However, before diving into the certification process, conducting an ISO 27001 gap analysis is essential to identify shortcomings in your information security management system (ISMS).

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

ISO 27001 Gap Analysis

What is ISO 27001 Gap Analysis?

 

An ISO 27001 gap analysis is a systematic process used to evaluate an organization’s existing ISMS against the requirements outlined in ISO 27001. The goal is to identify areas where your ISMS falls short, helping you address vulnerabilities and align your processes with ISO 27001 standards.

The analysis often acts as a preliminary step before embarking on a full ISO 27001 implementation or audit, allowing organizations to uncover weaknesses without the pressure of a formal assessment.

What an ISO 27001 Gap Analysis Actually Does

 

An ISO 27001 gap analysis is a practical readiness check that shows how close your organization is to achieving certification and what must be addressed before audit.

Rather than implementing controls blindly, it benchmarks your current ISMS against the ISO/IEC 27001 standard published by the International Organization for Standardization (ISO), helping you focus on what auditors will actually evaluate (ISO.org).

In practice, a gap analysis delivers five core outcomes:

  • Certification readiness: Confirms whether required clauses and Annex A controls are defined, implemented, and supported by evidence expected during a certification audit.

  • Internal audit alignment: Mirrors auditor logic without the pressure of a formal internal audit, reducing surprises later.

  • SoA mapping: Validates that Annex A controls are correctly selected, justified, and reflected in a defensible Statement of Applicability, a common audit failure point.

  • Risk treatment validation: Ensures identified risks are properly assessed and linked to realistic, documented treatment plans, as required by ISO/IEC 27001 clauses 6.1.2 and 6.1.3.

  • Targeted remediation: Produces a prioritized remediation plan so teams address high-impact gaps first, saving time and cost.

In short, an ISO 27001 gap analysis connects the standard’s requirements to real-world implementation, creating a clear, audit-ready path instead of guesswork.

Why Conduct an ISO 27001 Gap Analysis?

 

Conducting an ISO 27001 gap analysis is essential for organizations that aim to strengthen their information security framework and achieve certification. Here’s a detailed explanation of why it’s critical:

  • Avoid Costly Certification Failures:

Identifying non-conformities during a formal ISO 27001 certification audit can lead to delays, increased costs, and reputational risks. A gap analysis helps uncover these issues early, enabling corrective action without the pressure of a formal assessment.

  • Targeted Remediation:

A gap analysis clearly identifies which areas require improvement, allowing organizations to focus their resources where they’re needed most. This targeted approach avoids unnecessary expenses and efforts in areas that are already compliant.

  • Improved Risk Management:

By identifying vulnerabilities and compliance gaps, organizations can address potential security risks before they lead to breaches. Proactive risk mitigation ensures sensitive data remains protected, reducing exposure to threats.

  • Streamlined Audit Preparation:

Addressing gaps in advance ensures a smoother and less stressful experience during formal ISO 27001 audits. It minimizes the likelihood of surprises during the certification process and ensures that your organization is fully prepared to demonstrate compliance.

When to Conduct a Gap Analysis (Pre- vs Post- Implementation vs Audit)

When to conduct an ISO 27001 gap analysis

 

Timing matters. An ISO 27001 gap analysis delivers value at multiple stages, but the outcome changes depending on when it is performed.

Pre-implementation, a gap analysis sets direction. It clarifies scope, highlights existing controls that can be reused, and prevents over-engineering the ISMS. This is where organizations avoid building documentation and processes that do not map cleanly to ISO 27001 requirements.

Post-implementation, the gap analysis becomes a validation exercise. It checks whether policies, controls, risk treatment, and SoA mapping are not just written, but implemented and evidenced. At this stage, it exposes weaknesses that could turn into non-conformities during audit.

Before an audit, a gap analysis functions as an audit-readiness safeguard. It mirrors certification auditor expectations and surfaces last-mile issues early, when remediation is still faster, cheaper, and lower risk.

In practice, the strongest compliance programs treat gap analysis as a strategic checkpoint, not a one-time task.

 

Key Benefits of ISO 27001 Gap Analysis

 

Enhanced Security Posture:

A thorough gap analysis helps organizations identify and resolve weaknesses in their ISMS, resulting in a more robust security framework that protects against internal and external threats.

Cost-Effectiveness:

Instead of indiscriminately investing resources across all areas, a gap analysis allows organizations to allocate time, money, and effort to address specific weaknesses, optimizing overall costs.

Compliance Readiness:

A gap analysis ensures that your organization meets all ISO 27001 requirements by identifying areas of non-compliance and systematically addressing them. This sets the stage for successful certification.

Stakeholder Confidence:

Achieving ISO 27001 certification after addressing gaps demonstrates your commitment to protecting sensitive information. This builds trust with clients, partners, and regulators, enhancing your organization’s reputation.

According to a recent study, organizations with ISO 27001 certification report a 39% reduction in security incidents compared to those without certification. This highlights the importance of using tools like gap analysis to achieve compliance and enhance security.

 

Step-by-Step Guide to ISO 27001 Gap Analysis

 

Step 1: Understand the ISO 27001 Requirements

Familiarize yourself with the key elements of ISO 27001, including:

  • Annex A Controls: These include 93 security controls spanning 14 domains such as access control, incident management, and supplier relationships.
  • Clauses 4–10: These cover context, leadership, planning, support, operations, performance evaluation, and improvement.

Step 2: Define the Scope of the Gap Analysis

Determine which parts of your organization will be included in the analysis. This may encompass specific departments, locations, or IT systems. Clear scope definition ensures focused and relevant assessments.

Step 3: Gather Relevant Documentation

Compile existing ISMS documentation, including:

  • Security policies
  • Risk assessment reports
  • Incident response procedures
  • Training records

Step 4: Conduct the Gap Assessment

Evaluate your current ISMS against ISO 27001 requirements. Common methods include:

  • Interviews with key personnel
  • Reviewing processes and records
  • Technical assessments of IT systems

Step 5: Analyze the Findings

Document all gaps and categorize them based on the following:

  • Criticality: High-priority issues that must be addressed immediately.
  • Compliance: Areas that partially meet the requirements.

Step 6: Create a Roadmap for Compliance

Develop an actionable plan to address the gaps. This should include:

  • Timelines for remediation
  • Resource allocation
  • Assigned responsibilities

Mandatory Documents & Evidence Required for Gap Analysis

 

A gap analysis is only as strong as the evidence behind it. Auditors do not assess intent. They assess documentation, implementation, and proof. This is where many organizations fall short.

At minimum, a credible ISO 27001 gap analysis requires a Statement of Applicability (SoA) that clearly maps selected Annex A controls to your risk posture and justifies any exclusions. Without a defensible SoA, certification readiness cannot be reliably assessed.

Your risk assessment and Risk Treatment Plan (RTP) must show how information security risks are identified, evaluated, and treated, with clear ownership and status. These documents form the backbone of the ISMS and are directly referenced during audits.

Operational evidence matters just as much. This includes incident logs demonstrating how security events are handled, an up-to-date asset inventory showing what is protected, and access control records proving least-privilege enforcement across systems.

Third-party risk is another frequent gap. Vendor due diligence records are required to show how suppliers are assessed and monitored for security risk, especially when they process or access sensitive data.

Finally, auditors expect proof that controls operate in practice. Security training records confirm employee awareness, while audit logs provide technical evidence that systems are monitored and reviewed.

A gap analysis that reviews all of these artifacts does more than identify missing documents. It reveals whether your ISMS can withstand real audit scrutiny.

 

Deliverables & Outputs from a Proper Gap Analysis

 

A proper ISO 27001 gap analysis does not end with observations. It produces clear, usable outputs that move the organization closer to certification.

The primary deliverable is a gap analysis report that maps current practices against ISO 27001 clauses and Annex A controls, clearly distinguishing what is compliant, partially compliant, or missing. This gives leadership and technical teams a shared, factual view of readiness.

Equally important is a prioritized remediation plan. Instead of generic advice, it identifies what must be fixed first, why it matters for audit outcomes, and how remediation should be approached to reduce risk and effort.

A strong gap analysis also validates or corrects critical ISMS artifacts, including the Statement of Applicability and risk treatment decisions. By the end, organizations are not guessing what auditors will flag. They have a focused path forward, grounded in evidence and aligned with certification expectations.

ISO 27001 Gap Analysis Structure

 

An ISO 27001 gap analysis reviews your current security posture against the ISO/IEC 27001 standard to identify what is already in place, what is missing, and what needs improvement before certification. It is a practical exercise focused on clarity and prioritisation rather than audit judgement.

The structure aligns with the ISO 27001 clauses and Annex A controls maintained by the International Organization for Standardization (ISO). A high-level overview of the standard is available here.

1. Context and Scope Review

 

This step checks whether the ISMS scope accurately reflects your business activities, data flows, locations, and regulatory obligations. Gaps often appear where scopes are overly broad, too narrow, or copied from templates rather than tailored to reality.

2. Leadership and Governance Alignment

 

The analysis reviews management involvement, ownership of information security, and defined responsibilities. ISO 27001 expects leadership to actively support and steer the ISMS, not delegate it in isolation.

3. Risk Assessment and Risk Treatment

 

Here, the focus is on whether risks are identified, assessed, and treated using a consistent, documented approach. The gap analysis also checks that selected controls are clearly linked to risk treatment decisions, often informed by ISO 31000 principles.

4. Policies, Procedures, and Documentation

 

Existing documentation is reviewed to confirm it meets ISO 27001 requirements and reflects how security is actually managed day to day. Common gaps include missing policies or documents that exist but are not followed in practice.

5. Annex A Control Coverage

This section assesses which Annex A controls are implemented, partially implemented, or excluded, and whether exclusions are clearly justified. The emphasis is on effectiveness and relevance rather than implementing every control by default.

Studies referenced by the European Union Agency for Cybersecurity (ENISA) consistently show that well-implemented controls reduce risk more effectively than broad but shallow coverage.

6. Monitoring, Measurement, and Internal Audit

 

The final review examines how security performance is monitored through metrics, internal audits, management reviews, and corrective actions. Gaps here often indicate that controls exist but are not actively measured or improved.

Together, these sections form a clear, structured view of readiness, enabling a focused remediation plan and a smoother path to ISO 27001 certification.

Common Challenges in ISO 27001 Gap Analysis

 

Conducting an ISO 27001 gap analysis can be daunting due to several challenges organizations often face. Understanding these hurdles and how to address them is key to a successful outcome.

  •  Lack of Expertise

ISO 27001 is a comprehensive standard that demands specialized knowledge. Organizations without skilled personnel may inadvertently overlook critical gaps, leaving vulnerabilities unaddressed. This can lead to compliance failures during certification audits.

Solution: To ensure an in-depth and accurate analysis, engage internal team members with ISO 27001 training or hire external consultants with proven expertise.

  • Insufficient Resources

Many organizations need more time, budget, or staff for the gap analysis. This can result in incomplete assessments or rushed evaluations, increasing the risk of missed issues.

Solution: Allocate sufficient resources by prioritizing the analysis in your security strategy. Break the process into manageable phases and consider external support to optimize efficiency.

  • Resistance to Change

Employees may refrain from adopting new policies, processes, or technologies introduced as part of ISO 27001 compliance. This resistance can slow down implementation efforts and compromise the effectiveness of the gap analysis findings.

Solution: Foster a culture of security awareness through clear communication, training programs, and involving employees in the compliance journey.

  • Complex IT Environments

Modern organizations often operate in intricate IT ecosystems, including on-premises systems, cloud services, and hybrid setups. Assessing compliance across such environments can be challenging due to varying security configurations and integration issues.

Solution: Use advanced tools and frameworks to assess IT systems comprehensively. To streamline the process, partner with experienced consultants familiar with modern IT environments.

Partnering with an Experienced Consultant

Collaborating with ISO 27001 consultants can help organizations overcome these challenges effectively. Consultants bring specialized knowledge, tools, and experience to guide organizations through the complexities of gap analysis, ensuring a smoother path to compliance.

How to Prepare for the ISO 27001 Certification Audit

 

Once you’ve addressed the gaps identified in your analysis, it’s time to prepare for the ISO 27001 certification audit. A well-prepared organization can ensure a seamless certification process and minimize delays.

1. Internal Audit

Conduct an internal audit to evaluate your compliance with ISO 27001 requirements. This will help identify residual non-conformities and validate the effectiveness of corrective actions taken during the gap analysis.

2. Management Review

Involve leadership in reviewing the ISMS. This step ensures top-level commitment, aligns security goals with organizational objectives, and highlights areas needing further attention before the certification audit.

3. Staff Training

Employees play a crucial role in maintaining compliance. Train them on their responsibilities within the ISMS, emphasizing adherence to new policies, procedures, and controls.

4. Documentation

ISO 27001 heavily relies on documentation. Ensure all required policies, processes, risk assessments, and corrective action records are up-to-date, accurate, and easily accessible for auditors.

The Growing Importance of ISO 27001 Certification

ISO Survey data shows a 20% annual growth in ISO 27001 certifications worldwide, reflecting its increasing relevance in today’s security-conscious business environment. Achieving certification protects your organization’s data and builds trust with clients and partners, offering a competitive edge in the market.

Statistics and Trends in ISO 27001 Compliance

Cost Savings: Effective compliance reduces the average cost of a data breach, which stands at $4.45 million, according to IBM’s 2023 Cost of a Data Breach Report.

 

Conclusion

 

An ISO 27001 gap analysis is foundational for organizations seeking to strengthen their information security systems. By identifying and addressing deficiencies early, businesses can ensure smoother ISO 27001 certification audits and ongoing ISO 27001 audits.

Adopting a systematic approach enhances security and builds trust with stakeholders, giving your organization a competitive edge.

At Axipro, we specialize in efficiently helping businesses achieve ISO 27001 compliance. Contact us today to begin your journey towards robust information security.

 

FAQs

 

  1. What is an ISO 27001 gap analysis, and why is it important?

An ISO 27001 gap analysis evaluates your current information security management system (ISMS) against the requirements of ISO 27001. It helps identify areas for improvement to achieve compliance and strengthen your security posture.

  1. Who should conduct an ISO 27001 gap analysis?

Internal security professionals, an internal audit team, or external consultants specializing in ISO 27001 compliance can conduct a gap analysis. Organizations often choose external experts to gain an unbiased perspective.

  1. How long does an ISO 27001 gap analysis take?

The duration depends on your organization’s size and complexity and the scope of the analysis. It can take anywhere from a few days to several weeks.

  1. What documents are needed for an ISO 27001 gap analysis?

You’ll need existing ISMS policies, risk assessment reports, incident management procedures, access control policies, and other relevant security documentation.

 

Axipro Author

Picture of Abeera Zainab

Abeera Zainab

Blog Highlights

Explore More Articles

For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly. What Agentic AI Actually Changes Traditional AI systems, even generative ones, are advisory. They produce an output such as a summary, a prediction, a draft email, or a classification, and a human remains the last checkpoint before anything happens in the real world. Agentic AI removes that checkpoint. An agentic system doesn’t just produce an answer. It pursues a goal. It decides which tools to call and in what order, then executes those actions directly against live systems: submitting a purchase order, modifying a database record, sending an external communication, or orchestrating a set of sub-agents to complete a broader workflow. Agentic autonomy is the degree to which a system can plan and execute actions without a human explicitly authorizing each step. It’s a spectrum rather than a binary. At one end, the AI drafts and a human approves every action. At the other, the AI operates within broad guardrails and only escalates exceptions. The further an organization moves along that spectrum, the less its exposure looks like software risk and the more it looks like delegated authority risk, the kind normally reserved for employees, contractors, and automated financial systems. Why Existing Risk Registers Miss Agentic AI Risks Most enterprise risk registers were built on a reasonably safe assumption: a human initiates consequential actions, and the technology around that human behaves deterministically. Agentic AI breaks both halves of that assumption at once. A few specific gaps show up quickly when organizations try to map agentic deployments onto existing categories. Operational risk registers assume process failures come from human error or system outages, not from a system independently choosing an unanticipated path to a stated goal. Cybersecurity risk registers are built around unauthorized external access, while an agent problem usually involves an authorized system taking unauthorized internal actions with its own legitimate credentials. Model risk frameworks, borrowed largely from financial services, evaluate output accuracy rather than action consequences, which matters most when those actions can’t be reversed. And third-party risk assessments treat vendors as static entities, not as autonomous agents that might invoke other vendors’ agents on your behalf. See our guide to the NIST AI Risk Management Framework for how output-focused frameworks are structured. The result is a governance blind spot. An organization can be compliant against its AI policy, its cybersecurity policy, and its vendor risk policy, and still have nobody accountable for the specific risk of a system initiating a harmful sequence of actions before anyone notices. Defining Agentic Autonomy Risk Agentic Autonomy Risk is the risk that an AI system, operating with delegated decision-making and execution authority, takes actions that are harmful, non-compliant, or misaligned with organizational intent before adequate human oversight can intervene. Those actions might happen independently or in coordination with other agents. It deserves standing as a named category alongside cybersecurity, operational, legal, financial, and third-party risk because the loss event itself is different. The harm is a completed action in a live system, and it may be difficult or impossible to reverse. The accountability structure is different too: when an orchestrating agent delegates to sub-agents, responsibility for the outcome gets distributed in ways existing ownership models don’t cleanly capture. So is the detection window. Traditional controls assume a human is positioned to catch an error before it compounds, but an agent can execute dozens of dependent actions faster than any human review cycle. 7 Agentic AI Risk Scenarios to Put on Your Register 1. Unauthorized autonomous decision-making. An agent takes an action within its technical permissions but outside its intended business mandate. It adjusts pricing, approves a refund, or modifies a customer record, and no policy ever explicitly authorized that scenario. 2. Goal misalignment. The agent optimizes for a literal interpretation of its objective in a way that diverges from actual business intent, particularly under ambiguous or adversarial inputs. 3. Multi-agent interactions and cascading failures. One agent’s flawed output becomes another agent’s trusted input. A single error can propagate across a chain of agents faster than anyone can detect it, amplifying the original mistake instead of containing it. 4. Excessive tool or system permissions. Agents get provisioned with broad, standing access “to be safe” rather than scoped, least-privilege access tied to specific tasks. A productivity tool quietly becomes a privilege-escalation path. 5. Regulatory non-compliance. Autonomous actions trigger obligations under data protection, financial services, employment, or sector-specific regulation, and they execute without the compliance review a human-initiated process would normally receive. 6. Explainability and accountability gaps. An autonomous action causes harm and the organization can’t clearly reconstruct why the agent chose that path, or establish whether the business owner, the AI governance function, or the vendor is accountable for the outcome. 7. Autonomous third-party actions. A vendor’s agent, integrated into your environment, takes action on your behalf, or your agent acts against a

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing?​ A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance​ SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2?​ Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $1,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the lower end of the market start around $1,000 to $5,000. Deep manual testing from established firms runs $10,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise) Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $1,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure​ A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That