How to Choose a Pentesting Company

A qualified penetration testing company is selected with a fixed evaluation checklist covering:

• Named testers
• Written methodology
• Sample-report quality
• Retesting terms
• Communication protocol
• Quote completeness
• Compliance reporting

Brand recognition and headline price are not the primary filters. Score every shortlist against the same criteria, including a specialist UK firm such as Pentesting Company, so the engagement actually finds exploitable risk, supports a fix, and protects the assets that matter.

Use this sequence:

• 1. Confirm the vendor does manual exploitation rather than scanning
• 2. Verify the individuals who will test
• 3. Lock methodology and deliverables in the proposal
• 4. Then reject any firm that fails the red-flag checks

Request a sample report and a pre-engagement call with the lead tester before you sign. Those two artefacts tell you more than a logo, a certification wall, or a top 10 list.

What Defines a Qualified Penetration Testing Company

A qualified penetration testing company is one that combines certified, hands-on testers with a defined methodology, transparent reporting, and verifiable experience in your specific technology stack. That baseline stops selection collapsing into a logo contest or a race to the lowest day rate.

A genuine penetration testing company authorises skilled testers to exploit weaknesses, chain findings, and prove business impact. A vulnerability scanning provider runs automated tools that list known issues without proving they are exploitable.

A vendor offering scanning as a pentest substitute is immediately disqualified. Scan output is not exploitation evidence, not an attack narrative, and not a remediation brief your developers can execute.

Certifications are table stakes, not differentiators: they prove a minimum bar, they do not prove the people on your job will go beyond a tool report.

Years in business and number of tests performed are weaker signals than relevant experience. A firm with a long web-application track record may still be the wrong choice for OT, SCADA, or a complex cloud IAM estate. Ask for similar-stack examples, not a generic client count.

Standard penetration testing is also not red teaming: red teaming is an adversarial, objective-led exercise for mature programmes. First-time buyers who need a scoped, reportable test of named assets should buy a pentest, not a red team, unless they already have detection and response they want to stress.

In the UK market, CREST accreditation is the widely recognised commercial standard. NCSC guidance provides additional reference points, and public-sector or Critical National Infrastructure buyers may need a separate CHECK-assured route. Map the vendor to your asset type first (web application, network, cloud, or OT/IT), then to the assurance scheme your sector actually requires.

Tester Qualifications: Certifications That Actually Matter

Tester qualifications that actually matter are CREST CCT, CREST CRT, OSCP, and OSWE, because each validates hands-on exploitation rather than slide-deck theory.

Company-level badges do not tell you who will touch your systems. A CREST-registered firm can still assign an unnamed, junior bench to your window. Quality tracks the person on the keyboard.

CREST is the UK-recognised standard and is particularly relevant for London and UK-based businesses that must justify tester competence to boards, insurers, or auditors. Other letters (for example CISSP) may describe security knowledge, but they do not substitute for a hands-on exploitation exam when you are buying a pentest.

Certifications are necessary but not sufficient. Ask which specific testers will work on your engagement, and request a pre-engagement call with the lead tester. Use that call to test whether they can discuss your stack in concrete terms, not marketing language.

Vendors who refuse to commit to named testers are a red flag. The common failure mode is a sales-team versus delivery-team split: senior consultants win the work, then junior testers execute it. If the people on the call will not be the people on the keyboard, treat the proposal as incomplete. A good vendor welcomes that scrutiny because they are confident in the people they will send.

Methodology and Standards: What Good Testing Looks Like

Good penetration testing follows a written, adaptable methodology aligned to OWASP, NIST 800-53, PTES, and ISO 27001 controls, not an undocumented one-off scan.

A vendor who cannot explain that method in plain language is not ready to test production systems. If the method is not written in the proposal, treat it as a verbal promise you cannot audit.

• OWASP Top 10 sets the baseline risk classes for web applications, including injection and cross-site scripting, but it is a starting map, not a complete test plan.
• NIST 800-53 includes penetration testing under CA-8 as a security assessment control.
• PTES describes an end-to-end testing standard from pre-engagement through reporting.
• ISO 27001 references security testing inside its control set, so the report often becomes audit evidence rather than an informal findings dump.

Pentesting sits inside a wider security programme; it is not a substitute for risk assessment, vulnerability management, or monitoring.

A qualified vendor should articulate their methodology clearly and adapt it to your environment. A one-size-fits-all script that ignores your architecture, identity model, or third-party integrations will miss the paths that matter.

Tools such as Burp Suite, Metasploit, or Nessus may support the work. They are not the methodology. If the sales answer is a tool list, you are still looking at a scan dressed as a pentest.

Match the test type to the risk you actually carry. A product company usually needs web application and API testing. An organisation with significant internal infrastructure needs network testing from an internal perspective as well as an external one. Social engineering and red teaming are separate products with different rules of engagement. Do not let a vendor collapse those into one vague security test.

You should expect these engagement phases:

• 1. Scoping
• 2. Reconnaissance
• 3. Vulnerability analysis
• 4. Exploitation
• 5. Post-exploitation
• 6. Reporting
• 7. Remediation verification

If exploitation and post-exploitation are missing, you are buying a scan. If remediation verification is missing, you are buying an unfinished loop.

For most organisations, grey-box or white-box testing provides better value because testers can go deeper with system knowledge. Black-box still has a place when you need an outside-in view, but it should be a conscious scope choice, not the default because it sounds more realistic.

What a good proposal should include

• A written methodology named against OWASP, PTES, NIST CA-8, or the control set you must evidence
• Named testers, not a generic certified team
• Asset-level scope, exclusions, and testing type (black-box, grey-box, or white-box)
• The seven phases above, with time boxed for exploitation rather than scanning only
• Internal versus external perspective, and which environments will be tested
• Timeline, deliverables, communication cadence, and retesting terms
• Rules of engagement, data-handling, and critical-finding escalation

Report Quality: How to Evaluate the Primary Deliverable

Report quality is evaluated with a 5-point framework: business-risk executive summary, risk-prioritised findings, supporting evidence, honest false-positive handling, and developer-ready remediation steps.

The report is the product you are buying. Request a sample report before you commit. If a vendor will not share a sample, you cannot evaluate the only artefact that will remain after the testers leave.

• 1. Executive summary explains business risk without jargon. A usable summary tells a non-technical reader what could be stolen, disrupted, or abused, and what decision is required. If it only restates CVE names, it will not travel to the board or to procurement.
• 2. Findings are prioritised by risk rating (critical, high, medium, low) with clear remediation steps. Ratings must be tied to impact and exploitability in your environment, not copied from a scanner default. Each finding needs an owner-ready fix path, not a generic control citation.
• 3. Evidence supports each finding (screenshots, request/response pairs). Without reproducible evidence, developers cannot confirm the issue and you cannot defend the rating to an auditor. Look for enough detail to replay the issue, not a cropped screenshot with no context.
• 4. False positives are acknowledged and explained. Silence on false positives usually means the vendor did not verify. A mature report shows what was tested, what was not exploitable, and why. That honesty is a quality signal, not a weakness.
• 5. The report is actionable for developers (specific, reproducible, prioritised). Steps should name the affected component, the reproduction path, and the fix direction. Vague advice such as harden the server fails this test.

The same document must work for two audiences: management reads risk and priority, engineers read evidence and reproduction.

A complete report also states scope, methodology, and residual risk so an auditor can see what was in, what was out, and what remains. If the sample cannot do both jobs, the live report will not either.

Apply the 5 points to the sample in one sitting and score each vendor the same way.

Retesting Policies: What Happens After the Report

Good retesting includes free verification within 30-60 days, coverage of all findings rather than critical-only, and a clear retest report.

Retesting is the step that closes the loop. Without it you have a list, not proof that risk dropped.

Confirm the window, the coverage, and the artefact in the statement of work, because this is where many complete engagements quietly stop.

Confirm retesting terms before signing, not after the initial test is complete.

If the answer is not in the statement of work, it does not exist. Retesting is the verification step that turns TEST. FIND. FIX. PROTECT. into an evidenced cycle rather than a PDF on a share drive.

Communication and Transparency: What to Expect During the Engagement

A vendor’s behaviour during the sales process predicts their behaviour during the engagement, so demand named contacts, critical-finding alerts, and a written rules of engagement document before work starts.

Evasive sales answers become silent testing weeks. Get scope, timeline, deliverables, retesting, pricing, and safety rules in writing. Kick-off slides are not a contract.

During the test you should expect regular check-ins, immediate notification of critical findings, and a named point of contact. Daily or agreed-interval updates stop both sides guessing whether testing is blocked, noisy, or waiting on access.

Production testing needs a live brake: if latency spikes or a service degrades, testers must halt on an agreed signal rather than finish the module anyway.

A rules of engagement document should contain:

• Authorised targets
• Time windows
• Excluded systems
• Permitted techniques
• Data-handling rules
• Emergency stop conditions
• Escalation contacts

It protects both parties: it stops testers wandering into out-of-scope production, and it gives you a contractual brake if something goes wrong. That document is how operational risk is managed, including the risk that testers will break something.

Ask how the vendor stores evidence, who can see screenshots and credentials, and what happens if a test action causes instability. A good answer covers encryption, least-privilege access to engagement data, a rollback or halt procedure, and a client-side incident path. If they cannot describe failure handling, do not give them production access.

Understanding Pentesting Costs: How to Evaluate Quotes

Pentesting costs vary based on scope (asset count and attack surface), complexity (technology stack and custom applications), tester seniority, duration, and retesting terms.

There is no single market rate that makes two unlike quotes comparable. Equalise what is included first, then look at the number.

• Scope: More domains, IPs, APIs, tenants, and user roles increase hours. Unclear scope produces both under-testing and later change requests.
• Complexity: Custom business logic, SSO, cloud IAM, and OT/IT boundaries take senior time. Commodity brochure sites do not.
• Tester seniority: Named CREST CCT or OSWE-level testers cost more than unsupervised juniors for a reason: chaining and exploitation quality.
• Duration: Calendar length and concurrent tester days are different. A short window with no exploitation time is a scan in disguise.
• Retesting terms: Inclusive 30-60 day retesting is part of the real price. Excluding it makes a quote look cheaper than the work you still need.

Get multiple quotes and compare what is included, not just the total.

A transparent quote states defined scope, named testers, methodology, timeline, deliverables, retesting terms, and communication cadence. Anything missing will reappear as an extra or as a gap in coverage.

The cheapest quote is rarely the best value, because low bids often hide automated scanning, junior testers, or a quietly cut scope. The most expensive quote is not automatically the best either: high price does not prove exploitation depth.

Quotes that sit significantly below other credible bids often indicate automated scanning, junior testers, or a quietly limited scope.

The cost of a missed vulnerability, in breach response, downtime, and reputation, far exceeds the saving from choosing the cheaper vendor.

Rank vendors on inclusion and evidence first. Use price as a comparison input after inclusion is equalised, not as the first ranking column.

A transparent quote includes

• Asset list and explicit exclusions
• Testing approach (black-box, grey-box, or white-box) and environments
• Named testers and seniority mix
• Written methodology and report format
• Start date, testing days, and report date
• Retesting window, coverage, and whether it is in the price
• Communication cadence and critical-finding process

Compliance-Driven Pentesting: Meeting Regulatory Requirements

PCI DSS, GDPR, DORA, ISO 27001, and NIST 800-53 CA-8 are the key frameworks that require or recommend penetration testing with defined scope, qualified testers, documented methodology, and an auditor-ready report.

Compliance-driven testing is not the same as a general health check: the artefact must survive scrutiny. A SaaS startup buying a health check and a payments firm buying PCI evidence are not buying the same product, even if both say pentest.

• PCI DSS: Mandates regular penetration testing of the cardholder data environment and after significant changes. Scope accuracy is the usual failure point.
• GDPR: Requires appropriate technical and organisational security measures. A pentest report is evidence of that duty, not a named GDPR certificate. UK GDPR also creates reporting and accountability expectations if testing evidence includes personal data.
• DORA: Raises ICT risk-testing expectations for in-scope EU financial entities. Vendors must understand financial-sector testing discipline, not only generic web apps.
• ISO 27001: Uses testing evidence inside its control set. Auditors look for repeatable method, qualified people, and tracked remediation.
• NIST 800-53 (CA-8): Explicitly includes penetration testing as a security assessment activity. Scope, independence, and reporting quality are part of the control story.

These regimes expect a defined scope, qualified testers, a documented method, and a report you can put in front of an auditor without translating it from tool noise.

Independence matters: the people who built the system should not be the only people attesting that it is safe.

In the UK, CREST certification is widely recognised, and NCSC provides guidance on penetration testing. Public-sector and CNI buyers should confirm whether an NCSC CHECK provider is a separate procurement requirement from commercial CREST assurance.

Red Flags: When to Walk Away from a Vendor

Walk away from a pentesting vendor when they cannot name testers, refuse a sample report, undercut credible quotes, guarantee 100% security, outsource without disclosure, or cannot describe methodology or retesting.

Treat the list as disqualification, not a soft caution. These behaviours indicate structural delivery problems, not gaps you can fix in kick-off.

• Vendor cannot name the specific testers who will work on the engagement. You are buying individual skill. An unnamed bench is how junior substitution happens after signature.
• Vendor refuses to share a sample report. The report is the deliverable. Hiding the format hides weak evidence, empty remediation, and scanner dumps.
• Pricing is significantly below market rates. The missing cost is usually manual exploitation time, senior testers, or retesting. You pay later in residual risk.
• Vendor promises to find everything or guarantees 100% security. No finite test can exhaust every path. That claim is a competence signal, and it is negative.
• Vendor outsources testing without disclosure. You lose control of who holds screenshots, credentials, and architecture detail. Undisclosed subcontracting is a trust failure.
• Vendor’s methodology description is vague or non-existent. If they cannot write the method, they cannot defend the method to your auditor or your engineers.
• Vendor cannot articulate their retesting policy. They are selling a snapshot. You need verification after the fix.
• Vendor is evasive during the sales process. Access, outages, and critical findings require adult communication. Evasion in sales is the preview.

One confirmed red flag is enough to stop the process. Do not offset a refusal to name testers against a friendly price. Do not assume a well-known brand overrides a missing sample report or unnamed delivery staff. The checklist exists so you can walk away with a defensible reason, including to procurement.

How to Plan the Engagement: Timeline, Scope, and Preparation

To plan the engagement, start the vendor search 4-6 weeks before the test is needed, write an asset-level scope, and schedule testing when your internal team can support it.

Most engagements run 2-6 weeks across scoping, testing, reporting, and retesting, depending on scope. Good testers book out. A rushed purchase is how junior substitution and thin scanning enter the shortlist.

• 1. Start vendor search 4-6 weeks early. Named senior testers book out. A last-minute purchase pushes you toward whoever has spare juniors.
• 2. Write the scope before you compare quotes. List domains, IPs, APIs, mobile backends, cloud accounts, and internal systems in scope. State environments (production, pre-production). Name third-party SaaS that is off-limits or needs supplier permission. Under-scoping misses crown jewels. Over-scoping pays for theatre around low-value targets.
• 3. Specify testing boundaries. Define excluded hosts, rate limits, social-engineering rules, denial-of-service prohibitions, and data you must not exfiltrate. Ambiguity here creates either unsafe testing or polite under-testing.
• 4. Define success criteria. Examples: auditor-ready report for a named control, coverage of all internet-facing apps before a launch, or verification of a prior year’s criticals plus new attack surface.
• 5. Agree communication protocols. Named contacts on both sides, critical-finding SLA, out-of-hours halt path, and how credentials are issued and revoked.
• 6. Schedule around delivery reality. Run the test when developers and IT can answer access questions and review findings. Avoid major release freezes, holiday shutdowns, and peak trading windows.
• 7. Plan the retest before you book the initial test. Reserve the 30-60 day verification window in the same statement of work so remediation is not orphaned.

Scoping checklist

• All in-scope hostnames, IP ranges, APIs, and applications, including forgotten staging sites
• Identity providers, admin panels, and privilege tiers testers may use
• Cloud accounts, containers, and management planes, not only virtual machines
• Internal vs external perspective, and whether office or VPN access is provided
• Third-party dependencies and who must approve testing of supplier-hosted assets
• Data sensitivity and evidence-handling constraints
• Change-freeze dates and maximum acceptable operational impact

Ask the vendor how they interpret the scope: will subdomains be included automatically, how they treat related corporate ranges, and what they do when they discover an unknown asset.

A good answer proposes a written change-control step rather than silent expansion or silent ignore. Silent expansion is scope creep. Silent ignore is a missed asset.

What Happens After the Report: Remediation and Follow-Up

After the report, triage findings by risk rating, assign owners, track fixes, then schedule retesting to verify every finding, not only critical ones.

The engagement’s value is realised in remediation, not in PDF receipt. A pentest that ends at delivery is an incomplete control.

• 1. Triage by risk, not by ticket volume. Critical and high items that are exploitable on internet-facing or privileged paths go first. Group duplicates that share one root cause so you do not patch symptoms five times.
• 2. Assign ownership. Application findings go to the product or engineering owner, infrastructure findings to platform or IT, identity findings to whoever owns IAM. Unowned findings do not close.
• 3. Track fixes with the original evidence. Each ticket should link to the finding ID, reproduction steps, and the proposed fix. Status belongs in a tracker your retest can follow.
• 4. Work the vendor during remediation. Ask clarifying questions, request extra evidence where a developer cannot reproduce, and confirm whether a compensating control actually breaks the attack path.
• 5. Book the retest inside the agreed window. Good retesting verifies all agreed findings and produces a retest report stating verified or still open. Critical-only retesting leaves chained medium issues live.

Triage checklist

• Critical / high / medium / low counts agreed with the tester, with any rating disputes written down
• Owner, due date, and environment for every finding
• Dependencies (vendor patches, change board, third-party SaaS) flagged early
• Executive summary sent to management; technical evidence sent to the people who will patch
• Retest date set before the contractual window expires

Use the executive summary for board and budget conversations. Keep the technical appendix for developers. Mixing those audiences in one meeting usually dilutes both.

Once fixes land, the retest is the proof step. Until that report exists, treat the original findings as open risk.

Apply the same evaluation checklist to every provider you invite, then run the engagement as a closed loop: test, find, fix, protect. When you want a UK specialist scored against these criteria, start with Pentesting Company.

Frequently Asked Questions

A pentest purchase still fails if:

• Scanning is confused with exploitation
• The calendar is wrong
• One historic report is treated as a control
• A tool dump is accepted as a report
• Company badges replace named testers
• Black-box testing is chosen for the wrong reason