Two providers can test the same application, charge very different fees, and produce reports that look equally convincing. One may follow tightly controlled methods. The other may rely on little more than a scanner and a polished template. From the outside, the difference is not always obvious.
CREST-approved pen testing gives you a way to judge more than the final report. It reflects how the provider handles testing, protects sensitive information, reviews its work, and manages the engagement. CREST accredits organisations for defined security services, while individual professionals follow a separate certification route.
So, before you treat a CREST logo as proof of quality, you need to know what it actually confirms and what it does not.
Key Takeaways
- Check the provider’s current CREST listing before trusting the logo. Penetration testing must appear under its approved services.
- Company approval does not prove that every tester has the right skills. Their experience should match the system being tested.
- A weak scope can leave important applications, accounts, APIs, or cloud assets outside the assessment.
- Automated tools can flag possible issues. Human review is still needed to confirm real risk.
- The report should help leaders understand the impact and help technical teams fix the problem.
- Retesting shows whether the repair worked and whether the original attack route has been closed.
What Is CREST Approved Pen Testing?
CREST-approved pen testing is an authorised security assessment carried out by a company accredited by CREST for penetration testing services.
Testers examine an agreed scope, such as applications, networks, APIs, cloud environments, or internal systems. They identify weaknesses and, where permitted, use controlled exploitation to confirm whether those issues could lead to unauthorised access, data exposure, higher privileges, or service disruption.
The test should show:
- Which findings are genuine
- Whether they can be exploited
- Which issues create the greatest business risk
- How to fix them
- Whether the fixes prevent further exploitation
A vulnerability scan flags possible weaknesses. CREST penetration testing adds manual analysis, validation, business context, and controlled exploitation.
CREST Accreditation, Certification, and Approved Services: What Is the Difference?
These terms are often treated as interchangeable, but they point to different types of assurance.
1. CREST Accredited Penetration Testing Company
This applies to an organisation and the penetration testing discipline for which it has been approved. Accreditation shows that CREST has assessed areas such as:
- Testing methodology
- Service governance
- Information security
- Quality control
- Personnel management
- Engagement oversight
Always check the provider’s current CREST listing. The company name alone is not enough. Penetration testing must appear within its approved services.
2. CREST Certified Penetration Tester
This applies to the individual carrying out the work. It shows that the tester has passed a CREST examination for a defined technical level or area of expertise.
Relevant qualifications include:
- CREST Practitioner Security Analyst, or CPSA
- CREST Registered Penetration Tester, or CRT
- CREST Certified Tester Infrastructure, or CCT INF
- CREST Certified Tester Application, or CCT APP
The qualification should suit the assessment. Someone certified for infrastructure testing may not be the right lead for a complex mobile application or API review. Ask who will perform the test and whether their certification matches the assets in scope.
3. CREST Approved Service
A CREST-approved service is work delivered within a discipline for which the member company has been accredited.
Do not presume as a matter of default that the cybersecurity service offered by the provider might be accredited by CREST since the company could have gained accreditation in the area of penetration testing alone but not for other services available in its portfolio.
Before signing the contract, confirm that the exact work you are buying falls under the provider’s approved penetration testing discipline.
4. CREST Defensible Penetration Test
A CREST Defensible Penetration Test is a structured engagement model. It sets clear expectations for:
- Scope
- Test execution
- Documentation
- Reporting
- Final sign-off
It forms part of the wider CREST penetration testing framework, but it is not the same as company accreditation or individual tester certification.
What Does CREST Assess in a Penetration Testing Provider?
CREST accreditation looks beyond the technical ability of individual testers. It examines how the company operates and how it manages its penetration testing service from contract stage through delivery and review.
Organisational and Commercial Controls
CREST reviews areas such as:
- Company structure and ownership
- Insurance arrangements
- Contract management
- Defined responsibilities
- Management oversight
- Human resources policies
- Personnel screening
- Background checks
- Quality measurement
- Service review procedures
Information Security and Client Data Handling
Penetration tests produce highly sensitive material. CREST therefore checks how the provider protects client information during the engagement and after the work is complete.
Key areas include:
- Secure handling of credentials and reports
- Protection of screenshots and vulnerability evidence
- Safe storage of logs and exploit data
- Controlled access to assessment records
- Secure file transfer methods
- Defined retention periods
- Clear deletion procedures
- Information security processes based on recognised management principles
Penetration Testing Methodology
CREST expects the provider to follow a documented method that can be applied consistently across engagements. The methodology should include:
- Assessment planning
- Scope control
- Risk checks before intrusive testing
- Rules for controlled exploitation
- Exception handling
- Escalation procedures
- Client communication
- Response to unexpected findings
- Management of operational disruption
Engagement Management and Quality Assurance
CREST also reviews how the provider controls each project and checks the quality of its work. This includes:
- Clear project responsibilities
- Agreed communication channels
- Named escalation contacts
- Oversight by experienced personnel
- Technical review of findings
- Quality checks on reports
- Approval of final deliverables
- Incident handling procedures
These controls matter because testers may handle credentials, internal architecture, configuration details, customer data, and proof of exploitable weaknesses. Accreditation gives you independent assurance that the provider has processes to manage that access responsibly, rather than asking you to rely on marketing claims alone.
How Does a Company Become CREST Accredited for Penetration Testing?
A provider applies for accreditation under CREST’s penetration testing discipline. The application must include documents and supporting evidence that show how the company manages and delivers the service.
CREST reviews the submission against its company requirements and penetration testing standard. When the evidence meets the required criteria, the organisation receives accreditation for that discipline. The company also agrees to follow CREST’s rules on professional conduct.
Approval requires continued compliance. CREST-accredited companies must maintain their standards and complete periodic reassessments as requirements develop.
How Does CREST Approved Pen Testing Work?
A CREST-approved engagement begins before any technical testing takes place and continues through reporting, remediation, and verification.
1. Define the Business Objective
The provider first needs to understand what the test should achieve. You may want to assess an application before launch, review external infrastructure, check security after a cloud migration, support a customer request, meet a contractual requirement, investigate risk after an incident, confirm earlier fixes, or assist with merger and acquisition due diligence.
That purpose determines the scope, test depth, environment, access level, methodology, and reporting format.
2. Define the Scope
The client and provider must agree exactly what can be tested. This may include IP ranges, domains, applications, APIs, mobile apps, cloud environments, wireless networks, user roles, physical sites, and approved testing windows.
The scope should also record what remains off limits. Third-party systems, sensitive data, restricted techniques, and assets that cannot tolerate intrusive testing need clear boundaries. Any assumptions, exclusions, dependencies, and testing limitations should be written down before the assessment begins. Clear rules of engagement reduce the risk of outages, data exposure, or testing beyond the client’s authority.
3. Agree the Rules of Engagement
Before testing starts, both parties set the boundaries in writing. The agreement should cover authorisation, approved source addresses, testing hours, emergency contacts, escalation routes, stop conditions, incident reporting, and third-party permissions.
It should also state what testers cannot do. Common restrictions apply to denial of service activity, social engineering, live data access, evidence handling, and the amount of information that may be extracted. Clear rules protect the client’s systems and give the testing team legal and operational certainty throughout the engagement.
4. Perform Reconnaissance and Attack Surface Analysis
The testing team maps the exposed environment before attempting exploitation. This can include services, technologies, domains, subdomains, application routes, APIs, authentication flows, cloud services, administrative interfaces, user roles, and trust relationships.
The aim is to understand how an attacker could move from one exposed asset to another and which routes deserve closer testing. A complete view of the attack surface helps prevent important entry points from being overlooked.
5. Identify and Validate Vulnerabilities
Possible weaknesses are checked through a mix of automated scans and hands-on investigation. The review may cover login controls, sessions, permissions, inputs, business logic, configurations, network protocols, encryption, and cloud access.
Crest pen testing can use specialist tools to improve coverage. A tester must still examine the results, remove false positives, and confirm whether an issue can be exploited in the target environment.
6. Conduct Controlled Exploitation
Once a weakness is confirmed, the tester may demonstrate its impact within the agreed limits. That could mean bypassing authentication, reaching another user’s data, gaining higher privileges, executing a command, accessing an internal system, proving excessive cloud permissions, or linking several minor flaws into a serious attack route.
Any proof remains limited and only proceeds when it is authorised and safe. During crest penetration testing, controlled exploitation separates a genuine security risk from a scanner alert that has not been proven.
7. Evaluate Technical and Business Risk
A technical score tells only part of the story. The provider should also consider exposure, access needs, data sensitivity, service importance, possible disruption, lateral movement, existing controls, and regulatory impact.
The final priority should reflect the risk to the business, not the vulnerability rating alone.
8. Prepare and Review the Report
The final report should show what was tested, what was found, why each issue matters, and how to fix it. It normally includes:
- Executive summary
- Scope and objectives
- Testing dates
- Methodology
- Exclusions and limitations
- Detailed findings
- Evidence and reproduction steps
- Risk ratings
- Affected assets
- Business impact
- Remediation guidance
- Positive observations
- Unresolved constraints
Before delivery, the findings and report should pass both technical and quality review.
9. Remediate and Retest Findings
After the client fixes the confirmed issues, the provider tests them again. The review checks whether the original attack still works, whether every affected instance was corrected, and whether the change created another weakness.
Compensating controls also need verification before the risk is closed. Root cause analysis can reveal whether the same coding error, configuration problem, or access control failure exists elsewhere.
Types of Systems Covered by CREST Approved Penetration Testing
CREST accreditation applies to the provider’s penetration testing service. Each engagement still needs testers who understand the technology and sector involved.
| Testing Type | What It Covers | Main Areas Reviewed |
| External network penetration testing | Systems exposed to the internet | Firewalls, VPN gateways, remote access systems, public servers, email infrastructure, cloud-hosted services, and exposed administrative interfaces. It shows what an external attacker could discover and exploit without internal access. |
| Internal network penetration testing | Threats that begin inside the network | Credential exposure, privilege escalation, segmentation weaknesses, lateral movement, and access to sensitive systems. It can simulate a compromised account, infected workstation, malicious insider, unauthorised device, or attacker who has crossed the perimeter. |
| Web application penetration testing | Browser-based applications and related controls | Authentication, session management, authorisation, injection, input validation, file uploads, account recovery, business logic, sensitive data exposure, server configuration, and multifactor authentication. |
| API penetration testing | REST, GraphQL, SOAP, and other service interfaces | Object level authorisation, function-level authorisation, token handling, rate controls, excessive data exposure, mass assignment, injection, API inventory issues, server-side request forgery, and business process abuse. |
| Mobile application penetration testing | Android and iOS applications | Local data storage, backend API communication, authentication, certificate validation, permissions, reverse engineering resistance, and sensitive information in logs or backups. A complete review often includes backend APIs because package testing alone can miss server-side weaknesses. |
| Cloud penetration testing | Systems hosted on AWS, Microsoft Azure, Google Cloud, or another cloud platform | Identity and access management, storage permissions, network exposure, secrets management, serverless functions, containers, Kubernetes, logging controls, tenant separation, and privilege escalation routes. Testing must follow the cloud provider’s rules and avoid affecting other customers. |
| Wireless penetration testing | Corporate and guest wireless networks | Encryption settings, guest isolation, rogue access points, weak credentials, enterprise authentication, segmentation, and wireless client attacks. Onsite access may be required. |
