Penetration Testing Services

What a penetration test is

A penetration test is an authorised, simulated attack on your systems. Testers combine automated tools with manual techniques to find vulnerabilities that real attackers could exploit — and, crucially, they verify which issues are genuinely exploitable rather than listing theoretical risks.

Many customers, partners and compliance frameworks require regular penetration tests. More importantly, a good test gives your team a clear, prioritised list of what to fix.

Problems we solve

• An enterprise customer requires a recent penetration test report
• Preparing for SOC 2, ISO 27001, HIPAA or PCI DSS
• A major release, new authentication system or payment flow
• You have never had an independent security test
• You suspect issues but do not know where to start

What’s included

Our testing approach

Tests follow recognised methodologies such as the OWASP Web Security Testing Guide and OWASP API Security Top 10. We agree scope, test accounts and rules of engagement in writing before starting, test against a staging environment where possible, and keep you informed of any critical issue as soon as we find it rather than waiting for the final report.

1. Scope & planDays

   Targets, accounts, timing and contacts agreed.

2. Test1–3 weeks

   Automated and manual testing with focus on access control and business logic.

3. Report3–5 days

   Findings by severity with reproduction steps and recommendations.

4. RetestAfter fixes

   Confirm remediation and update the report.

Black-box, grey-box or white-box?

Grey-box testing gives the best coverage for most budgets, because testers spend time finding real issues rather than guessing at structure.

Timeline and budget

Typical ranges to help you plan. Your written estimate comes after a free discovery call.

How to prepare for a penetration test

A test is only as useful as the environment and information it is run against. A little preparation makes the results more accurate and the engagement smoother:

1. Agree scope in writing

   List the applications, APIs, hosts and user roles in scope, and anything explicitly out of scope such as third-party services you do not own.

2. Choose the environment

   A production-like staging environment with realistic data volumes is usually safest; testing production needs careful timing and monitoring.

3. Provide test accounts

   One or more accounts for each role, so testers can check whether one user can reach another user’s data.

4. Notify the right people

   Tell your hosting provider if required, and make sure your operations team knows not to block test traffic without warning.

5. Name a contact

   A technical contact who can answer questions quickly and be alerted immediately if a critical issue is found.

Reading a penetration test report

A good report is written for two audiences: executives who need to understand risk, and engineers who need to fix issues. Expect each finding to include:

• A severity rating with the reasoning behind it, not just a score
• Clear steps to reproduce the issue
• The business impact if it were exploited
• Specific remediation guidance for your technology stack
• References to standards such as the OWASP Top 10 where relevant

Fix critical and high findings first, then schedule a retest to confirm the fixes work. Medium and low findings often point to patterns — such as missing input validation — that are cheaper to fix systematically than one by one.

How often should you test?

There is no single right frequency, but common practice is to test at least once a year and after significant changes: a new application, a major release, new integrations or a change of hosting. Compliance frameworks and customer contracts often set minimum expectations. Between formal tests, automated scanning and secure development practices keep the baseline healthy, so each penetration test can focus on deeper issues rather than rediscovering the same basic weaknesses.

• Annual test of core applications and external infrastructure
• Targeted test before launching major features or new products
• Retest after critical fixes
• Continuous automated scanning in between

Types of penetration test

Many organisations combine a web or API test with a cloud configuration review, because a secure application can still be exposed by a misconfigured storage bucket or an over-privileged role.

Scoping a test properly

Most disappointing penetration tests are badly scoped rather than badly executed. Before testing begins we agree:

• Exact targets: domains, environments, API versions and mobile builds
• User roles to test with, and accounts for each
• What is out of scope, such as third-party services you do not control
• Testing windows and how to pause testing if something unexpected happens
• Emergency contacts on both sides
• Rules for handling any personal data encountered during testing

After the report: remediation and retesting

1. Triage

   Walk through findings together, confirm business impact and assign owners.

2. Fix

   Address critical and high issues first; we can help your developers with fixes or implement them ourselves.

3. Retest

   Verify each fix and confirm it has not opened a new problem.

4. Prevent

   Add regression tests and pipeline checks so the same class of issue does not return.

A retest of fixed findings is usually far shorter than the original test. We provide an updated summary showing which issues are resolved, which is often what customers and auditors want to see.

Penetration testing versus vulnerability scanning

Automated vulnerability scanners check systems against known issues and are useful to run continuously. A penetration test adds human judgement: testers chain small weaknesses into real attacks, abuse business logic and test authorisation in ways scanners cannot. Use scanning to keep the basics clean between tests, and penetration testing to understand how a determined attacker would actually get in.

Choosing a testing provider

When comparing providers, ask to see a redacted sample report, how findings are rated, whether testers are the same people named in the proposal, how they handle sensitive data found during testing, and whether a retest of fixed issues is included in the price.

Testing pairs well with secure engineering: see application security and identity and access management. Blockchain projects need their own review — see smart contract development.

Related services

Part of cybersecurity engineering. After testing, our application security team can fix the findings for you.

This page is part of Cybersecurity Engineering Services — see the full overview for related services, approach and pricing.