A Guide to CREST Penetration Testing Methodology

The crest penetration testing methodology gives structure to an engagement without forcing every system through the same technical routine. Testing an API is not the same as assessing a mobile application, cloud environment, web application, or network.

Penetration testing is changing fast. AI now supports parts of the process that once depended entirely on manual work. CREST research found that 47% of organisations use AI for reporting and 44% use it for scanning and enumeration. Only 9% use autonomous agent-based testing, so experienced testers still make the important decisions.

A scanner can point to possible weaknesses. A professional tester goes further by checking whether those weaknesses can be exploited and what damage they could cause.

This guide follows the testing process from the first planning discussion to the final remediation check.

Key Takeaways

• A strong test begins with a clear purpose and a realistic scope. Too much coverage in too little time can leave important areas undertested.
• Automated tools help find possible issues. Manual testing is still needed to prove impact and uncover business logic flaws.
• Written permission and clear testing rules protect both the client and the testing team.
• Several small weaknesses can combine into a serious attack path. 
• Tester expertise directly affects the depth of the assessment. Company accreditation does not mean every tester has the same skills for cloud, API, mobile, network, or operational technology testing.

What Is the CREST Penetration Testing Methodology?

The CREST penetration testing methodology is a structured approach to planning, authorising, performing, reviewing, reporting, and retesting a penetration test. It combines clear governance with technical checks selected according to the target, risk, and assessment goal.

CREST does not require one fixed set of commands for every engagement. The focus is on proper authorisation, competent testers, reliable evidence, suitable test depth, limited operational risk, and quality review.

Technical frameworks guide the specific checks. CREST company accreditation applies to providers, while individual crest certification applies to practitioners.

Need a Real Penetration Testing Report Sample Today?

See exactly how security experts document vulnerabilities, risks, and remediation steps in a professional pentest report.

Download Sample Report
→

 What Makes a CREST Penetration Test Defensible?

A defensible penetration test is one whose scope, methods, findings, and limitations can be supported if questioned by management, auditors, customers, regulators, or legal teams. It does not mean every vulnerability will be found.

A defensible engagement should include:

• A clear business or assurance objective
• Explicit legal authority to test
• A scope linked to the identified risk
• Suitably qualified testers
• Proportionate technical depth
• Secure and reproducible evidence
• Documented exclusions
• Immediate escalation of serious findings
• Technical peer review
• Clear assumptions and limitations

Stakeholders should also be able to explain why the test was commissioned, why specific systems and methods were chosen, whether enough time was provided, and whether another qualified tester could understand the evidence.

Defensibility must shape the full testing lifecycle, not only the final report.

CREST Penetration Testing Methodology Step by Step

The stages below represent a complete crest penetration testing methodology engagement. Some may overlap during a complex test, but planning, approval, evidence handling, communication, reporting, and review remain essential throughout.

1. Define the Assurance Objective

The first step is to decide what the test must help you confirm. Requests such as “test everything” are too broad and make it difficult to choose the right depth or use testing time effectively.

Common objectives include:

• Checking an application before launch
• Reviewing an external attack surface
• Testing controls after a system change
• Confirming network segmentation
• Assessing cloud access controls
• Verifying that previous findings were fixed

The objective determines the scope, access level, testing depth, evidence needs, reporting style, and retesting requirements.

You should also record the systems and data being protected, likely threats, acceptable impact, and the level of access the tester may attempt to gain. Broad coverage and detailed attack path testing require different levels of time and effort.

2. Select the Penetration Testing Provider and Team

The provider and assigned testers directly affect the quality of the assessment. Confirm that the company holds relevant crest certification and has experience with the technology in scope.

Check the following before work begins:

• Who will perform the technical testing
• Which qualifications and specialist skills they hold
• Who will peer review the findings and report
• How evidence and sensitive data will be protected
• Whether subcontractors will take part
• What insurance and escalation procedures are in place

Company accreditation does not mean every tester has the same expertise. Cloud, API, mobile, Active Directory, Kubernetes, and operational technology assessments each require different skills.

3. Define the Testing Scope

The scope turns the assurance objective into clear technical boundaries. It should be agreed by the business owner, people familiar with the target, and a representative from the testing team.

Record the following before the assessment begins:

• Assets included and excluded
• Test environment and dates
• Access level and user roles
• Expected testing depth
• Third-party dependencies
• Restricted techniques
• Reporting and retesting needs

The technical detail depends on the target. Web application scoping may cover URLs, login flows, user roles, uploads, payment functions, tenant separation, and integrations. API testing requires endpoints, versions, tokens, rate limits, documentation, and test data. 

Network scopes usually list IP ranges, domains, VPN access, internal segments, and segmentation boundaries. Cloud assessments should identify accounts, identities, storage, containers, serverless services, CI and CD systems, and infrastructure code repositories.

A larger scope does not always mean better coverage. Too many endpoints, roles, integrations, or trust boundaries within a limited testing window can reduce the depth of crest penetration testing.

4. Establish Legal Authority and Rules of Engagement

Active testing must not begin without written permission. Owning an application does not automatically authorise testing of every connected service.

Separate approval will be required for systems such as:

• Shared cloud infrastructure
• Payment processors
• Managed service platforms
• External APIs
• SaaS integrations
• Content delivery networks
• Business partner systems

The rules of engagement should define the approved targets, testing dates, permitted hours, tester IP addresses, allowed techniques, credential use, data access limits, stop conditions, emergency contacts, escalation steps, evidence storage, and deletion requirements.

Restrictions must be specific. The document should clearly ban actions such as deleting database records, interrupting services, sending mass emails, or altering production data.

Testers must not move into an excluded system without formal approval.

5. Prepare the Environment, Access, and Communication Channels

Preparation keeps the assessment moving and prevents tester time from being lost on access problems.

Before testing begins, confirm that:

• Test accounts work for every agreed role
• Multifactor authentication can be completed
• Required features and test data are available
• Tester IP addresses are allowlisted where needed
• Backups and restore procedures are ready
• Logging and monitoring are active
• Rate limits will not block approved activity

An available technical contact should support the tester throughout the engagement.

Testing can be announced, partially blind, or blind. These terms only describe who knows about the cybersecurity assessment. A standard penetration test does not become a red team exercise simply because the defensive team was not informed.

6. Perform Reconnaissance and Map the Attack Surface

Reconnaissance shows what an attacker can discover and reach before deeper testing begins. Passive research uses public sources, while active reconnaissance interacts directly with the target.

Passive work can include DNS records, certificate data, public code repositories, document metadata, exposed cloud assets, and leaked credential references where permitted. Active work can cover ports, services, application paths, API routes, authentication flows, subdomains, network structure, and cloud permissions.

The result should be a clear attack surface map that records:

• Discovered assets and exposed services
• Entry points and authentication boundaries
• User roles and data flows
• Trust relationships and external dependencies

Any asset found outside the approved scope must remain untested until formal approval is given.

7. Develop Threat Hypotheses and Select Test Cases

The tester now decides which attack scenarios deserve the closest attention. A standard checklist alone will not uncover every risk, especially when the system has unusual workflows and sensitive data.

Questions can include:

• Can one customer view another customer’s data?
• Can a normal user gain administrator access?
• Can an API reveal more information than intended?
• Can a compromised employee account reach restricted systems?
• Can secrets be extracted from a build or deployment process?

The chosen checks should reflect the system design, user roles, trust boundaries, previous incidents, known weaknesses, and available testing time.

Web, API, cloud, and network tests will not follow the same priorities. Each one requires test cases suited to its own architecture and risk.

8. Discover Potential Vulnerabilities

Vulnerability discovery uses both automated coverage and manual investigation. Each supports a different part of the assessment.

Automated Activities

Automated tools help review a broad attack surface efficiently. Common checks include:

• Port and service scanning
• Application crawling
• Dependency analysis
• TLS and cryptographic configuration checks
• Content and directory discovery
• Configuration review
• Basic injection detection
• Known CVE identification

Manual Activities

Manual testing looks at issues that tools cannot assess reliably, including:

• Authentication and authorisation bypass
• Session and token abuse
• Business logic flaws
• Privilege escalation
• Race conditions
• File upload abuse
• Cross-tenant access
• Weak trust relationships
• Multi-step attack chains

Automated results must be validated before they are treated as confirmed findings. Human review reduces false positives and helps uncover workflow abuse, pricing manipulation, approval bypass, and complex permission issues.

9. Validate Weaknesses Through Controlled Exploitation

Finding a possible weakness is only the beginning. Controlled exploitation shows whether it can lead to a real security impact without creating unnecessary risk.

Safe validation can involve:

• Opening an approved restricted record
• Running a harmless system command
• Retrieving a test file
• Demonstrating privilege escalation
• Reaching an agreed internal test host
• Capturing a non-sensitive token
• Changing test data instead of production records

The tester should prove only what is needed to confirm the issue, then stop. They must avoid unnecessary access to sensitive information, service disruption, persistence, or changes to live data unless these actions were explicitly authorised.

10. Analyse Post-Exploitation Impact and Attack Paths

Post-exploitation analysis looks at what an attacker could reach after gaining an initial foothold. It should only form part of the assessment when it has been agreed during scoping.

The tester can examine whether that access creates a route to:

• Additional credentials
• Internal systems
• Cloud roles
• Management interfaces
• Sensitive information
• Trusted services

The main goal is to understand attack chaining. Several moderate weaknesses can combine into a serious compromise when one issue opens the way to another.

The analysis can also show where monitoring or detection controls should have identified the activity.

11. Maintain Communication and Escalate Critical Findings

Communication should continue while testing is underway. The provider must notify the client immediately when a finding or event requires urgent action, such as:

• Critical remote code execution
• Unrestricted access to sensitive data
• Exposure of active credentials
• Signs of malware or an existing compromise
• Testing activity that affects system stability
• Access to an excluded asset
• A weakness with a high risk of rapid exploitation

The initial alert should contain enough evidence for the client to begin containment. Full technical details must still appear in the final report.

When testing reveals a new asset or required check outside the agreed scope, work on that area must pause. The business or risk owner then approves or rejects the change in writing, and any resulting limitation is recorded.

12. Rate Technical Severity and Business Risk

A scanner can suggest a score, but it cannot decide how serious a finding is for your organisation. The final rating should reflect the evidence collected during testing and the way the affected system is actually used.

The tester will look at factors such as exploitability, access requirements, attack complexity, data sensitivity, internet exposure, existing controls, potential attack chaining, and regulatory impact. CVSS can support the technical score, but it does not capture the full business consequence.

A high technical score will not always require the highest remediation priority. Strong isolation controls can reduce the practical risk. A medium issue can also become critical when it combines with another weakness and exposes sensitive data.

Any score adjustment should be explained clearly. Inflating severity only makes the report less useful.

13. Document Evidence and Reproduction Steps

Each finding should include enough detail for the client to verify the issue and fix it correctly.

Record:

• Date and time
• Affected asset
• Required user role
• Request or command used
• Relevant response
• Affected parameter or component
• Result of exploitation
• Data accessed
• Testing limit applied
• Screenshot where useful

Evidence should be relevant, reproducible, securely stored, limited to what is necessary, and clearly connected to the correct finding.

Do not expose passwords, personal data, customer records, or confidential information in screenshots unless they are essential to prove the issue.

Reproduction steps should help an authorised developer or security engineer understand the problem without creating an unsafe public exploit guide.

14. Complete Reporting and Technical Peer Review

The report turns the assessment into something executives, security teams, and developers can act on. Before final delivery, another qualified tester should review the draft for accuracy, evidence quality, consistent severity ratings, clear business impact, suitable remediation advice, and correct scope statements.

A complete report should include:

• Executive summary
• Assessment objective and scope
• Testing dates and methodology
• Access and information supplied
• Assumptions, exclusions, and limitations
• Overall security observations
• Findings summary and detailed findings
• Attack path explanation
• Remediation priorities
• Strategic recommendations
• Positive security observations
• Evidence references

Each audience needs different information. Executives need overall exposure and business impact. Security teams need context and priorities. Developers need the affected component, root cause, evidence, and practical remediation steps.

Positive findings should also be included so effective controls are recognised and retained.

15. Plan Remediation, Retest, and Close Findings

Sending the report is not the final step. The provider should discuss the serious findings, connected attack paths, common root causes, successful controls, and testing limitations with the client. The client then decides which fixes take priority and which risks it will accept.

Retesting within Crest Security Services should confirm:

• Whether the original weakness still works
• Whether the root cause was corrected
• Whether every affected component received the fix
• Whether linked attack paths remain open
• Whether compensating controls reduce the risk
• Whether the change introduced another weakness

A retest covers previously reported findings. Regression testing checks other functions affected by the changes. A new penetration test reviews a wider or altered scope, while continuous testing provides ongoing visibility.

The final status can be resolved, partially resolved, risk reduced, not resolved, unable to retest, or accepted risk. A scanner rerun will not confirm remediation when the original finding required manual exploitation.

How Qualysec Delivers CREST Penetration Testing

Qualysec plans each risk assessment around the client’s technology and testing goals. Its CREST-accredited process covers web applications, mobile applications, APIs, cloud environments, networks, and IoT systems.

The team combines:

• Automated checks for broader coverage
  • Manual validation for accuracy
  • Hacker-style analysis for business logic flaws and attack paths
  • Technology-specific test cases

Each engagement includes scoping, controlled testing, technical review, risk classification, remediation guidance, and retesting support. Reports provide affected assets, evidence, reproduction steps, business impact, and recommended fixes.

According to the supplied company information, Qualysec has secured more than 450 assets for over 110 clients across 18 or more countries. You can request a quotation, review a sample report, or discuss the right testing scope with the security team.

Conclusion

Your security position can change soon after a test ends. New code, cloud updates, user access changes, and third-party integrations can all introduce fresh risk.

Working with Crest-approved companies helps you follow a more disciplined testing process, but the report is only useful when you act on it. Fix the issues that matter, confirm the changes through retesting, and include penetration testing in your wider security testing programme rather than treating it as a one-time exercise.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

Q.Does CREST provide one official penetration testing checklist?

No. There is no single CREST checklist for every system. A web application, API, cloud setup, and network all need different checks. CREST is more concerned with how the test is managed, reviewed, and supported by evidence.

Q.How is CREST different from OWASP penetration testing?

CREST covers the wider testing process and the quality of the provider. OWASP gives detailed guidance for testing web applications and web services. A CREST provider can use OWASP during the technical part of the test.

Q.Does a CREST penetration test use automated tools?

Yes, but tools are only one part of the work. They help find known issues and cover more ground. The tester still needs to check whether the issue is real, how it can be abused, and what damage it can cause.

Q.How are vulnerabilities rated during CREST penetration testing?

The tester can use CVSS or another scoring model. The final rating also depends on where the system is exposed, what data is involved, which controls are already in place, and how the issue affects the business.

Q.What happens when a critical vulnerability is found?

The client should be told as soon as the issue is confirmed. There is no need to wait for the final report. The provider will still include the full evidence, impact, and fix in the final document.

Q.Can a CREST penetration test prove that a system is secure?

No. A penetration test only shows what was found within the agreed scope and testing period. It cannot prove that no other weakness exists.