---
title: "ISO 27001 Penetration Testing: All You Need to Know - Axipro"
description: "ISO 27001 penetration testing: how often to test, what controls require pentesting, and how to integrate security testing into your ISMS."
canonical: "https://axipro.co/iso-27001-pentesting/"
language: "en-US"
modified: "2026-05-11T02:37:17+00:00"
generator: "WordPress 7.1.2"
---

[Home](https://axipro.co)

/ [All Blog](https://axipro.co/category/blog/), [ISO-27001](https://axipro.co/category/iso-27001/), [PENTEST](https://axipro.co/category/pentest/)

/ ISO 27001 Penetration Testing: What Auditors Expect and How to Deliver It

# ISO 27001 Penetration Testing: What Auditors Expect and How to Deliver It

![Picture of Pedro Dias](https://axipro.co/wp-content/uploads/2026/05/pedro-passport-picture-scaled.jpg)

- Pedro Dias
- April 6, 2026

Copy Link

**ISO 27001 does not use the words “penetration test” anywhere**. And yet, auditors conducting Stage 2 assessments **routinely expect to see one**.

Understanding why that gap exists, and how to close it, is what separates organizations that sail through [ISO 27001 certification](https://axipro.co/iso-27001-certification/) from those that get caught off-guard.

This guide covers what the standard actually says about security testing, which controls drive the expectation for penetration testing, what types of testing are relevant, and how to build a testing programme that genuinely supports your ISMS rather than simply ticking a compliance box.

![ISO 27001 Pentesting](https://axipro.co/wp-content/uploads/2026/04/ISO-27001-Pentesting.png)

## **What Is Penetration Testing in the context of ISO 27001?**

ISO 27001 penetration testing refers to structured, simulated attacks conducted against an organization’s systems, networks, and applications in order to identify exploitable vulnerabilities before real attackers do. In the context of [ISO 27001](https://en.wikipedia.org/wiki/ISO/IEC_27001), it serves a specific purpose: providing evidence that the technical controls underpinning your Information Security Management System (ISMS) actually work under real-world conditions.

**The distinction matters.** A vulnerability scan tells you what weaknesses exist whilst a penetration test tells you whether those weaknesses are exploitable, to what degree, and with what consequence. That difference is exactly what auditors are looking for when they ask for testing evidence.

Penetration testing is not an isolated activity in an ISO 27001 programme. Its findings feed directly into three of the most scrutinised documents in your ISMS: the **risk register**, the **risk treatment plan**, and the **Statement of Applicability (SoA)**. A risk listed in your register as “medium” looks very different once a tester has demonstrated they can chain it into a full domain compromise.

## **Is Penetration Testing a Requirement for ISO 27001?**

No, it is not explicitly required. The standard does not mandate it by name.

What ISO 27001 does require is that organisations establish and maintain a functioning ISMS, perform systematic risk assessments (Clause 6.1.2), implement appropriate controls (Clause 8), evaluate the performance and effectiveness of those controls (Clause 9), and pursue continual improvement (Clause 10). [Vulnerability assessment and penetration testing](https://axipro.co/services/vulnerability-assessment-and-penetration-testing/) supports every one of those activities with hard evidence.

Two Annex A controls make it practically impossible to demonstrate compliance without some form of penetration testing: **A.8.8 (Management of Technical Vulnerabilities)** and **A.8.29 (Security Testing in Development and Acceptance)**. Auditors conducting Stage 2 assessments will expect to see testing evidence mapped to both. Organisations that substitute a vulnerability scan report and call it done regularly receive non-conformances.

*The absence of an explicit penetration testing requirement is sometimes misread as permission to skip it. In practice, certified auditors universally expect evidence of testing that goes beyond automated scanning. Relying solely on scan reports is the fastest route to a failed audit.*

## **What ISO 27001:2022 Says About Security Testing**

### **Annex A 8.29: Security Testing in Development and Acceptance**

Annex A 8.29 requires organisations to define and implement security testing processes throughout the development lifecycle and before final acceptance of any system. This applies to both in-house development and outsourced or third-party software.

The control is **preventive in nature**. Its purpose is to ensure that no application, database, or system goes into production with known, unmitigated vulnerabilities. For in-house development, the standard specifically references conducting code reviews, performing vulnerability scans, and carrying out penetration tests to identify weak coding and design. For outsourced environments, organisations must set contractual requirements that ensure suppliers meet equivalent security testing standards, accepting a supplier’s assurance without evidence is not sufficient.

Annex A 8.29 does not prescribe specific tools or techniques. What it demands is that testing is **risk-based, documented, and proportionate** to the sensitivity and exposure of the system. A low-risk internal tool used by five people warrants a different level of scrutiny than a customer-facing payment platform. Security testing should scale with risk, and it should happen throughout development, not only at the end.

*Worth knowing:* Annex A 8.29 consolidates two controls from ISO 27001:2013, specifically A.14.2.8 (System security testing) and A.14.2.9 (System acceptance testing), into a single, clearer requirement. The 2022 version makes the expectation of penetration testing more explicit, particularly for major releases and architectural changes.

Auditors will ask to see signed penetration test reports or independent security audit summaries for recent major system updates. If such evidence does not exist, they have grounds to mark the control as non-compliant.

### **Annex A 8.8: Management of Technical Vulnerabilities**

Annex A 8.8 is the vulnerability management control. It requires organisations to identify, assess, and address technical vulnerabilities in a timely manner, taking a **proactive and risk-based approach** rather than reacting only when something breaks.

Crucially, the control explicitly lists periodic, documented penetration tests, conducted either by internal staff or by a qualified third party, as a method for identifying vulnerabilities. Automated scanners have their place, but penetration tests are recognised here as the mechanism for discovering high-risk weaknesses that scanners routinely miss: logic flaws, chained vulnerabilities, privilege escalation paths, and misconfigurations that only become dangerous in combination.

Annex A 8.8 replaces two controls from ISO 27001:2013: A.12.6.1 (Technical vulnerability management) and A.18.2.3 (Technical compliance review). The 2022 version introduces a broader, more holistic approach, including the organisation’s public responsibilities, the role of cloud providers, and the expectation that vulnerability management is integrated with change management rather than treated as a separate activity.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

[Schedule](https://axipro.co/free-assessment/)

## **The Role of Penetration Testing in ISO 27001 Compliance**

### **Risk Assessment and Treatment**

ISO 27001’s risk-based model sits at the core of everything. Penetration testing feeds that model with real-world evidence rather than hypothetical assumptions. When a tester demonstrates that an attacker can move laterally from a compromised workstation to a production database in four steps, that finding transforms what was previously a theoretical risk into a **documented, evidenced vulnerability** with a severity rating, an exploitability score, and a required remediation action.

This evidence directly informs how risks are treated. ISO 27001 requires organisations to choose one of four treatment options for each risk: mitigate, accept, avoid, or transfer. Without penetration test data, those decisions rest on estimation. With it, they rest on proof. If you haven’t yet mapped your current control gaps against what testers are likely to find, an [gap analysis](https://axipro.co/services/gap-analysis/) is a useful starting point before commissioning a test.

### **Security Controls Validation**

Your ISMS documentation asserts that certain controls are in place and working. Penetration testing verifies whether that is actually true. Network segmentation, multi-factor authentication, access restrictions, encryption in transit: these can all appear correctly configured on paper while being trivially bypassable in practice.

According to [NIST Special Publication 800-115](https://csrc.nist.gov/publications/detail/sp/800-115/final), organisations should conduct analysis and reporting that translates penetration test findings into concrete risk mitigation actions. **Mapping each finding to a specific Annex A control**, and documenting whether that control withstood or failed the test, is precisely the kind of evidence that satisfies an auditor and strengthens your SoA.

**Monitoring and Continual Improvement**

ISO 27001’s Clause 10 requires continual improvement of the ISMS. Penetration testing is one of the most direct mechanisms for driving that improvement. Each test cycle identifies new weaknesses, confirms previous remediations are holding, and adjusts your risk picture to reflect changes in the threat landscape and your own infrastructure. An annual penetration test programme, properly integrated with your risk register, is a **living feedback loop** rather than a point-in-time snapshot.

## **Types of Penetration Testing for ISO 27001**

ISO 27001 · ISMS-Scoped

Penetration Testing Categories

Every asset type within scope is a candidate for testing proportionate to its risk profile

ISMS scope boundary

Network Infrastructure

Routers, firewalls, switches and remote access controls

Annex A 8.20

Web Application Security

Injection attacks, broken auth and business logic flaws

Wireless Testing

Wi-Fi networks, rogue access points and weak encryption

Application & API Security

Auth weaknesses, data exposure and rate-limiting gaps

Annex A 8.29

Social Engineering

Phishing and pretexting to assess personnel controls

Annex A 6.3

Mobile Security

Insecure data storage and transport layer security gaps

Remote Working Assessment

VPN configs, endpoint controls and cloud access paths

Firewall Configuration Review

Rule sets, zone configs and permissive policy drift

Scope: all asset types within the ISMS boundary are candidates for testing

Annex A control mapped

The scope of penetration testing for ISO 27001 should align with the boundaries of your ISMS. Every asset type that falls within scope is a candidate for testing proportionate to its risk profile. The following categories represent the most relevant testing types for organisations pursuing or maintaining certification.

**Network Infrastructure Testing** evaluates routers, firewalls, switches, intrusion detection systems, and remote access controls. Testers attempt to bypass network defences, pivot between segments, and exploit protocol weaknesses. This directly validates Annex A 8.20 (Secure network architecture).

**Web Application Security Testing** assesses internet-facing applications for vulnerabilities including injection attacks, broken authentication, insecure direct object references, and business logic flaws. The [OWASP Top 10](https://owasp.org/www-project-top-ten/) provides a widely accepted reference framework for this type of testing.

**Wireless Testing** examines the security of Wi-Fi networks, including rogue access points, weak encryption configurations, and captive portal bypasses. Wireless environments are frequently underscoped in ISO 27001 programmes despite representing a meaningful attack surface.

**Application and API Security Review** assesses internal and external APIs for authentication weaknesses, excessive data exposure, rate-limiting failures, and injection vulnerabilities. As API-driven architectures become the norm, this testing type has grown in direct relevance to Annex A 8.29 compliance.

**Social Engineering Testing** simulates phishing campaigns and pretexting attempts to assess whether personnel controls are effective. This type directly informs people-focused controls including Annex A 6.3 (Information security awareness, education and training).

**Mobile Security Testing** reviews mobile applications and their backend interactions for insecure data storage, weak authentication, and insufficient transport layer security.

**Remote Working Assessment** evaluates the security of remote access infrastructure, VPN configurations, endpoint controls, and cloud access pathways. Given the permanent shift to hybrid working in most organisations, this assessment type is increasingly relevant to any ISMS scope.

**Firewall Configuration Review** examines rule sets, zone configurations, and egress controls to identify permissive rules, redundant exceptions, and policy drift that may have accumulated over time.

## **Penetration Testing Perspectives and Methodologies**

The perspective from which a penetration test is conducted determines what it can realistically find. Choosing the right methodology for each testing context is part of scoping effectively. For a deeper look at the trade-offs involved, see our guide on [automated vs manual penetration testing](https://axipro.co/automated-vs-manual-penetration-testing/).

**Black Box Testing** provides the tester with no prior knowledge of the target environment. This most closely simulates an external attacker who has done reconnaissance but has no insider access. It is realistic in terms of attack simulation but may miss issues that require architectural understanding to identify.

**Grey Box Testing** gives the tester partial information: network diagrams, application credentials, or high-level architecture documentation. This is often the most practical approach for ISO 27001 engagements because it balances realism with efficiency. The tester can focus on meaningful attack paths rather than spending engagement time on reconnaissance.

**White Box Testing** provides full access to source code, architecture documentation, and configuration details. This is the most thorough approach and is particularly relevant to Annex A 8.29, where the goal is to identify insecure coding patterns and design flaws before deployment.

### Pro Tip

For most organizations pursuing ISO 27001 certification, a combination of grey box external testing and white box application testing offers the best return on investment. The former validates perimeter and infrastructure controls; the latter directly evidences Annex A 8.29 compliance for development environments.

## **What Should an ISO 27001 Penetration Test Plan Include?**

A penetration test without a documented plan produces findings that are difficult to defend in an audit. The plan should define the **scope** (which systems, IP ranges, and applications), the **testing methodology** (black, grey, or white box), the testing window, rules of engagement, and who has authorised the engagement.

The resulting report should include an executive summary that maps findings to business impact, a technical findings section with severity ratings tied to a recognised scoring system such as [CVSS](https://www.first.org/cvss/), remediation guidance for each finding, and a retesting section that confirms whether fixes are effective. **Findings should be explicitly mapped to Annex A controls wherever possible.** An auditor reviewing this report should be able to trace each finding to a specific risk, a treatment decision, and an outcome.

Critically, penetration test documentation should be stored in your organisation’s native ISMS repositories, your SharePoint, Confluence, or equivalent. Findings sitting inside a third-party tool’s dashboard are not visible to auditors and do not demonstrate management ownership or oversight.

## **How Penetration Testing Supports Your ISMS**

### **In-House Development Environments**

For organisations that develop software internally, Annex A 8.29 requires that security testing is embedded in the development lifecycle, not bolted on at the end. Penetration testing is listed specifically as a method for identifying weak coding and design. The practical expectation is that significant releases and architectural changes are subject to an **independent penetration test before promotion to production**. “Independent” is the operative word: internal developers testing their own code does not meet the requirement.

### **Outsourced Development Environments**

Where development is delegated to a third party, the organisation remains responsible for security outcomes. Annex A 8.29 requires that contractual arrangements include security testing requirements, and Annex A 5.20 (Supplier relationships) establishes the broader framework for managing supplier security obligations. **Accepting a vendor’s self-attestation in lieu of test evidence introduces risk that auditors will probe.**

### **Structural and Organisational Changes**

Penetration testing should not be a purely calendar-driven exercise. Any significant change, a cloud migration, a new application, a network rearchitecture, an acquisition, reintroduces risk that existing controls may not adequately address. ISO 27001’s change management requirements (Annex A 8.32) and continual improvement obligations both support the case for **trigger-based testing** in addition to annual cycles.

## **ISO 27001:2022 vs ISO 27001:2013: Changes to Security Testing Requirements**

### **What Changed in Annex A 8.29 for ISO 27001:2022**

The 2022 update consolidated Annex A 14.2.8 (System security testing) and A.14.2.9 (System acceptance testing) from the 2013 standard into a single, clearer control: A.8.29. The consolidation is not merely administrative. The new control is more explicit about the requirement for security testing in both the development phase and at acceptance, for both in-house and outsourced environments.

The 2022 version also places greater emphasis on the idea that **testing must be risk-based and documented**, not performed as a routine checklist exercise. Auditors under the 2022 standard are expected to check not only that testing occurred, but that test plans linked security requirements to test cases, that findings were triaged appropriately, and that remediation was verified before sign-off. This is a meaningful shift from how many organisations approached the 2013 requirements.

### **How ISO 27001:2013 Approached Acceptance Testing**

Under the 2013 standard, acceptance testing (A.14.2.9) was largely focused on confirming that new systems met predefined acceptance criteria before deployment. Security testing (A.14.2.8) addressed systematic testing of systems against defined security requirements. The two controls were related but treated separately, and in practice many organisations satisfied them with functional test results rather than dedicated security testing. The 2022 consolidation closes that gap by making security validation in both development and acceptance a single, unified expectation. Organisations still working toward transition should also review the [common ISO 27001 pitfalls](https://axipro.co/avoiding-common-pitfalls-in-soc-2-iso-27001/) that trip up programmes during this shift.

## **How to Maintain ISO 27001 Certification Through Ongoing Penetration Testing**

Certification is not a destination. Annual surveillance audits and three-yearly recertification audits require ongoing evidence that your ISMS is functioning, including that security testing is current and that findings are being acted upon.

The practical standard for maintaining certification through penetration testing involves testing **at least annually**, with additional targeted tests following material changes to systems or infrastructure. Tests should be completed **six to eight weeks before any scheduled audit** to allow time for remediation. Maintain a **remediation log** that maps each finding to a closure date and a verification test, and formally accept in writing any residual risk that cannot be fully remediated before the audit.

The risk register and Statement of Applicability should always reflect the most recent test cycle. If a penetration test uncovered a weakness in network segmentation six months ago and your SoA still describes segmentation as fully effective, an auditor will notice the inconsistency. For organisations building out or reassessing their current testing programme, starting with an [ISO 27001 gap analysis](https://axipro.co/iso-27001-gap-analysis-a-detailed-guide-for-security-audit/) is an effective way to prioritise where testing effort is most urgently needed.

Organisations that are new to this process or working through a transition to the 2022 standard often benefit from working with an experienced [ISO 27001 consultant](https://axipro.co/iso-27001-consultant/) who can align the testing programme with audit expectations from the outset. Equally, pairing your penetration testing evidence with a rigorous [ISO 27001 internal audit](https://axipro.co/iso-27001-internal-audit/) process, or using dedicated [internal audit services](https://axipro.co/services/internal-audit/), ensures that findings are properly integrated into your ISMS before an external auditor arrives.

If you are ready to build a penetration testing programme that holds up under audit scrutiny, or need support aligning your existing testing evidence with ISO 27001 requirements, [contact us](https://axipro.co/contact/) to discuss your situation. You may also find it useful to [learn more](https://axipro.co/drata-vs-vanta-which-compliance-tool-is-best/) about how compliance automation tools can support your broader ISMS programme.

Axipro Author

![Picture of Pedro Dias](https://axipro.co/wp-content/uploads/2026/05/pedro-passport-picture-scaled.jpg)

### Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

- April 6, 2026
- [All Blog](https://axipro.co/category/blog/), [ISO-27001](https://axipro.co/category/iso-27001/), [PENTEST](https://axipro.co/category/pentest/)

Copy Link

## Blog Highlights

## Explore More Articles

[Read More Blogs](https://axipro.co/blog/)

- [SOC-2](https://axipro.co/category/soc-2-2/)

- September 24, 2026

#### [The SaaS Founder’s 6-Week SOC 2 Readiness Plan (Free Template)](https://axipro.co/soc-2-readiness-plan/)

You can get a SaaS company ready for a SOC 2 audit in six weeks, but you’ll feel every one of them. Most published timelines say three to six months. For a company with no project owner, no identity provider, and nothing written down, that’s about right. A cloud-native startup that already has the basics in place and can protect some time is a different story, and it can fit the work into six hard weeks. This plan walks through that route one week at a time. Each week has an owner, an hour estimate, and a clear test for when it’s finished. The free Google Sheet version turns the plan into a tracker you can hand out to owners and update in your weekly standup. Before you start, know what you’re signing up for. At the end of week 6 you’ll be audit-ready, which isn’t the same as holding a Type II report. Nobody can get you a Type II in six weeks. This is also the do-it-yourself route, and it takes a lot of hours. We’ll show you where those hours go and what the faster option looks like. Is Six Weeks Realistic for Your Company? Six weeks works when most of the plumbing already exists and your job is to formalize it, fill the gaps, and prove it all works. It falls apart when you’re building the foundations and documenting them at the same time. Go through this table honestly before you promise a customer a date. Six weeks is realistic if… Plan for 10 to 16 weeks if… Your product runs on a major cloud provider You host on-premise or across several data centers You already use an identity provider with SSO Every tool has its own login and password You have fewer than about 50 employees You have multiple offices, subsidiaries, or products in scope One named person owns the project with 10 to 15 hours a week Compliance is “everyone’s job,” so in practice nobody owns it An engineer can give you 15 to 20 hours in weeks 3 and 4 Engineering is fully committed to a launch You only need the Security criteria You need Availability, Confidentiality, or Privacy on day one Landing mostly in the right-hand column doesn’t mean you should throw the plan out. Give each week two weeks instead of one and follow the same order. What “SOC 2 Ready” Means at the End of Week 6 SOC 2 doesn’t give you a certificate. An independent CPA firm examines your controls against the AICPA Trust Services Criteria and writes a report, and which of the two report types you go for decides what you can show a buyer after week 6. A Type I report checks whether your controls are designed properly on a single date. Once you’re ready, a Type I audit can start almost right away. A Type II report checks whether those controls kept working over an observation period of at least three months, and usually six to twelve. Most enterprise procurement teams want Type II in the end. Being “ready” at the end of this plan means your in-scope controls are in place, you can pull evidence for any of them on request, and your auditor is booked. From there you either start a Type I audit or open your Type II observation window. Plenty of buyers will sign with a Type I report plus a letter from your auditor saying the Type II period is underway. Important: The Type II clock doesn’t start until your controls are running. If readiness slips by a week, your Type II report slips by a week too. Founders who tell a prospect “we’ll have SOC 2 in Q3” often forget this and end up renegotiating the deal. Before Week 1: Four Decisions to Make First Settle these before the clock starts. If you change any of them halfway through, you’ll redo work. Scope. Decide which systems, teams, and data the report covers. For most SaaS companies that’s the production environment, the code repository, the identity provider, customer data stores, and any support tools that touch customer data. Corporate systems that never see customer data can usually stay out. Trust Services Criteria. Security (also called the Common Criteria) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Report type. Pick Type I if a deal is blocked right now and the buyer will accept it. If there’s no deadline, go straight to Type II. You’ll need it eventually, and skipping Type I saves you an audit fee. Owner and tooling. Name one person who’s accountable for the plan, and decide where your controls and evidence will live. The tooling choice gets its own section below. Pro Tip: Adding Criteria Only add optional criteria when a customer contract or security questionnaire asks for them. Each one brings more controls to set up and more evidence to collect, and you can widen the scope in next year’s audit. Spreadsheet or Compliance Software: Choosing Your Tracking Tool Every SOC 2 program needs a system of record, meaning one place where each control, its owner, its status, and its evidence live. You can run it yourself in a spreadsheet or a GRC platform, or have a consultant implement it for you. The right choice depends mostly on which report you’re after and how much of your team’s time you can spare. A spreadsheet is free and familiar. It also makes you understand your own environment before you automate any of it. For a Type I, or for a small team with a tight scope, a well-built spreadsheet can take you all the way to the audit. Axipro’s free GRC workbook for SOC 2 and ISO 27001 covers all 33 SOC 2 Common Criteria plus the optional criteria, with evidence, risk, policy, and gap trackers built in. It has no macros and opens straight in Google Sheets or Excel. A GRC platform connects to your cloud, identity provider, code repository, and HR system.

[Read more](https://axipro.co/soc-2-readiness-plan/)

- [All Blog](https://axipro.co/category/blog/), [Customer Stories](https://axipro.co/category/stories/), [ISO 42001](https://axipro.co/category/iso-42001/), [ISO-27001](https://axipro.co/category/iso-27001/)

- September 23, 2026

#### [How MetisJean Went From Startup to ISO 27001 and ISO 27701 Certified in Five Months](https://axipro.co/metisjean-iso-27001-27701-42001/)

MetisJean, a technology startup with no governance framework, earned ISO/IEC 27001 and ISO/IEC 27701 certification and implemented ISO/IEC 42001 with Axipro in five months.

[Read more](https://axipro.co/metisjean-iso-27001-27701-42001/)

[![Axipro vs Cognisys vs Eden Data vs Workstreet](https://axipro.co/wp-content/uploads/2026/09/Axipro-vs-Cognisys-vs-Eden-Data-vs-Workstreet-1024x535.png)](https://axipro.co/axipro-vs-cognisys-vs-eden-data-vs-workstreet/)

- [Compliance](https://axipro.co/category/compliance/)

- September 22, 2026

#### [Axipro vs Cognisys vs Eden Data vs Workstreet: Which Compliance Partner Gets You Audit-Ready Fastest?](https://axipro.co/axipro-vs-cognisys-vs-eden-data-vs-workstreet/)

Most SaaS companies that want someone to handle SOC 2 or ISO 27001 for them end up with the same four names on the shortlist: Axipro, Cognisys, Eden Data, and Workstreet. Their published timelines to audit readiness run from under six weeks to twelve months, and pricing differs by a factor of three or more. When an enterprise deal is waiting on a report, that spread can decide whether the deal closes this quarter or next. We should say upfront that we’re Axipro, so we have a horse in this race. We built this comparison from feedback from our clients, each firm’s public website, partner directory listings, and marketplace pages. We also wrote it to be useful even if you hire someone else, and we say so where a competitor is the better fit. There’s one more piece of context. Since the Delve allegations broke in March 2026, buyers have treated the phrase “fast compliance” with suspicion, and they’re right to. So this article answers two questions: who gets you audit-ready fastest, and how you can tell real speed from a rubber stamp. Quick Verdict: Which Compliance Partner Fits Which Company Axipro is our pick for most companies, and the rest of this article shows the reasoning. It gets you audit-ready in under six weeks for a fixed published fee that’s typically about half of competitors’. You also get guaranteed certification on the Achievement Plan, top-tier status with Drata plus a Vanta partnership, and regional frameworks the other three don’t list. Cognisys is the second strongest choice for UK companies that are committed to Vanta and want penetration testing from the same in-house team. Eden Data suits US companies that want a US-based, ex-Big 4 team on a monthly subscription and can live with a longer runway. Axipro vs Cognisys vs Eden Data vs Workstreet at a Glance (Comparison Table) Axipro Cognisys Eden Data Workstreet Base Entities in Bahrain, UK, and US; team distributed across three continents Leeds and London, UK Austin, Texas San Francisco, California GRC platforms Drata (Elite Partner), Vanta, and 10+ others Vanta-centered Drata, Vanta, and others Vanta-centered Published readiness timeline Under 6 weeks 4 to 6 weeks on its DTA program, with prerequisites 3 to 12 months No standing figure published Pricing model Fixed fee per framework, published Quote on request Subscription from $5,000 per month Custom quote Certification guarantee Yes, on the Achievement Plan None published that we found None published that we found None published that we found Penetration testing Yes, with a CREST Pathway+ registered partner In-house Add-on Yes Standout frameworks SOC 2, ISO 27001, NCA ECC, SAMA CSF, ISO 42001, EU AI Act Cyber Essentials Plus, NIS2, DORA HITRUST, FedRAMP, CMMC FedRAMP, CMMC, NIST 800-53 Best for Speed and budget, any region UK companies on Vanta US buyers who want a subscription US startups on Vanta What a Compliance Readiness Partner Does That Your GRC Platform Doesn’t A GRC platform such as Drata or Vanta connects to your cloud, identity, and HR systems and collects evidence automatically. It’ll tell you that 14 laptops lack disk encryption. It won’t encrypt them or write the policy that requires it. It also won’t decide whether the contractor laptops are in scope, or sit in the auditor walkthrough and explain your change management process. That’s the work a readiness partner sells. The partner scopes the audit, writes policies that match how the company really operates, puts the missing controls in place, runs the risk assessment and internal audit, and manages the auditor until the report lands. Companies that buy a platform and skip the partner usually find this out around month three. By then the dashboard is stuck at 60 percent and the engineer who owns it has stopped answering compliance tickets. Platform, Readiness Partner, Auditor: Who Owns Which Part of the Audit Three parties are involved, and each has its own job. The platform collects and monitors evidence. The readiness partner builds the program and gets you to the point where an audit will succeed. The auditor is an independent CPA firm for SOC 2, or an accredited certification body for ISO 27001, and only the auditor forms the opinion. The AICPA’s SOC 2 guidance treats that independence as the whole point of the attestation. The Delve story shows what happens when those jobs collapse into one. In March 2026, an anonymous group of former customers accused the compliance startup of generating fabricated evidence and pre-written auditor conclusions, then routing clients to audit firms that signed whatever arrived. Their analysis of leaked files found that 493 of 494 SOC 2 reports shared near-identical text, down to the same grammatical error. Delve has denied the claims and says independent auditors issue all final opinions. We covered the details in our piece on what the Delve compliance leak means for SOC 2 certification. It wasn’t the first time, either. In 2024 the SEC shut down audit firm BF Borgers for fabricating audit documentation behind more than 1,500 filings, in what its enforcement director called a “sham audit mill.” That was a financial audit and Delve’s were security audits, but the failure was the same: someone signed a report with no work behind it. Important: None of the four firms in this comparison has been implicated in any of this. All four are human-led readiness firms that hand the final opinion to independent auditors. We bring up the scandals because they changed what buyers should ask, and we don’t mean it as a dig at competitors. How We Compared the Four Partners We scored each firm on eight criteria that a founder or CTO would care about with a deal on the line. Every data point comes from material the firms publish themselves. Where a firm publishes nothing, we say so and don’t guess. Time to Audit-Ready Audit-ready means an auditor could start fieldwork tomorrow and you’d pass. Your policies are approved, your controls are running, evidence is flowing, and the risk assessment and internal audit are

[Read more](https://axipro.co/axipro-vs-cognisys-vs-eden-data-vs-workstreet/)

WhatsApp us