CREST penetration testing
CHECK, OVS, STAR, and the defensible engagement
CREST is the international not for profit body that accredits cybersecurity service providers and the individuals who work for them. Run CREST aligned engagements across CHECK, OVS, STAR, and STAR FS scopes with structured scoping, technical execution, peer reviewed reporting, retests, and assessor ready evidence from one platform.
No credit card required. Free plan available forever.
CREST: an accreditation body, a quality standard, and a family of testing schemes
CREST (the Council of Registered Ethical Security Testers, now CREST International) is a not for profit body that accredits cybersecurity service providers and individual practitioners. CREST operates a range of testing schemes including CHECK (UK government), OVS (the OWASP Verification Standard), STAR and STAR FS (intelligence led red team), and the Certified Tester and Simulated Attack Specialist certifications for individuals. CREST member firms commit to an organisational standard covering processes, complaint handling, data protection, and quality assurance, and the people delivering the engagement hold individual certifications appropriate to the scope.
CREST sits comfortably alongside the methodology specifications most testers reach for. The Penetration Testing Execution Standard (PTES) gives the engagement scaffold from pre engagement through reporting. The OWASP Top 10 and OWASP Testing Guide cover the web application phase in depth. OWASP ASVS and MASVS are the underlying standards for CREST OVS engagements. The MITRE ATT&CK framework is the language CREST STAR engagements use to tag what attackers do, and compliance frameworks like ISO 27001, PCI DSS, and NIS2 commonly accept a CREST aligned penetration test as evidence for their technical testing controls.
The CREST testing schemes at a glance
CREST operates several distinct schemes. They are not interchangeable: the scheme governs the scope, the required individual certifications, and the reporting expectations. Pick the scheme first, then build the engagement against it.
CREST CHECK
The UK government penetration testing scheme operated by the National Cyber Security Centre with CREST as the accreditation body. CHECK applies to systems handling government information at protected impact levels and to critical national infrastructure. CHECK engagements require a CHECK Team Leader and CHECK Team Members with current accreditations on the test team and rest on a tightly scoped authorisation document signed by the customer authority.
CREST OVS (OWASP Verification Standard)
A scheme that aligns CREST verification activity directly with the OWASP Application Security Verification Standard (ASVS) and the OWASP Mobile Application Security Verification Standard (MASVS). OVS engagements declare the verification level (Level 1, 2, or 3), name the requirements in scope, and produce a report that maps findings to ASVS or MASVS requirements rather than to a generic vulnerability list. OVS is most useful where the buyer wants comparability across providers and a precise definition of depth.
CREST STAR and STAR FS
Intelligence led red team frameworks. STAR (Simulated Targeted Attack and Response) tests how an organisation detects, responds to, and recovers from a realistic adversary scenario informed by external threat intelligence. STAR FS is the financial services variant operated alongside the Bank of England CBEST programme and the Financial Conduct Authority oversight regime. STAR engagements are scoped at board level, run with white team oversight, and deliver a joint red and blue debrief, not just a finding list.
CREST Penetration Testing of IoT and OT
CREST publishes guidance for penetration testing of Internet of Things and operational technology environments, recognising the safety and availability constraints those systems impose. The methodology is unchanged in shape but tighter on rules of engagement, evidence handling, and exploitation depth so the test does not interrupt a process critical environment.
CREST Cloud Security Services and SOC
CREST also accredits service providers across cloud security services and SOC capability beyond the core penetration testing schemes. The schemes share the same accreditation logic: an organisational standard for the firm, a competence standard for the individuals, and a documented service that can be tested and reported against.
CREST individual certifications: who is allowed to lead what
CREST accreditation rests on the people who deliver the engagement, not just the firm. The practitioner certifications below define who is qualified to lead each scope and which scheme each certification gates.
CRT (CREST Registered Tester)
The entry level CREST examination for penetration testers. CRT validates a tester has the practical and theoretical knowledge required to support a CHECK Team Member or independent CREST engagement. CRT is the minimum technical certification for many UK CHECK engagements.
CCT INF (CREST Certified Tester Infrastructure)
A senior infrastructure penetration testing certification covering host, network, and Active Directory testing. CCT INF holders typically lead infrastructure scopes inside larger engagements and are eligible for CHECK Team Leader status alongside the appropriate scheme requirements.
CCT APP (CREST Certified Tester Application)
The senior application penetration testing certification, covering web, API, and increasingly mobile application testing. CCT APP holders typically lead the application testing portion of a CREST engagement and align directly with the OVS verification levels.
CCSAS and CCSAM (Simulated Attack Specialist and Manager)
The CREST Certified Simulated Attack Specialist and Certified Simulated Attack Manager certifications target intelligence led red team operators and red team leads delivering STAR, STAR FS, and CBEST engagements. These certifications gate participation in the formal STAR programmes alongside the firm level accreditation.
Tracking the certifications held by each tester on the engagement is operationally important. Customers commissioning a CHECK or STAR engagement need to verify the test team holds the required accreditations on the day of the engagement, and the report should cite the lead tester credentials alongside the methodology. The team management capability records the role of each member of the engagement team so this verification is a click rather than an email thread.
The CREST Defensible Penetration Test specification
CREST publishes the Defensible Penetration Test specification as a buyer side guide for what a credible engagement looks like, independent of which scheme the test is delivered under. The specification is short on purpose: it is a checklist of the things a buyer should be able to verify before, during, and after the engagement, and it sets the floor for any CREST aligned delivery.
- Proportional scoping that captures business objectives, asset boundaries, exclusions, testing windows, and the rules of engagement in writing before any technical work begins
- Qualified testers whose certifications and experience are appropriate for the scope, with the test team named on the authorisation document so the customer can verify accreditation status
- A documented methodology that the engagement actually follows, citing CREST guidance, OWASP testing references, and where relevant PTES, NIST SP 800-115, or OSSTMM
- Evidence based reporting that distinguishes vulnerability from exploited risk, ties findings to demonstrated business impact, and includes reproduction steps that the customer can validate independently
- A retest mechanism that is part of the engagement contract, not a follow on procurement, with the retest window defined in the rules of engagement
- A data handling regime that protects customer data through and after the engagement, including secure transfer, retention limits, and clear destruction or return of evidence at engagement closure
- A formal closure step in which the report is signed off, retests are completed where possible, and the engagement record is retained for audit and re engagement purposes
For a longer form treatment of the engagement scope and the contractual mechanics that operate the defensible test, see the penetration testing scope of work template and choosing a security testing provider.
CREST OVS verification levels: pick the level on purpose
CREST OVS engagements declare a verification level drawn from OWASP ASVS or MASVS. The level is a contractual decision: a Level 1 engagement reported as Level 3 is a scope breach, and a Level 3 engagement reported as Level 1 is a value gap. Decide the level during pre engagement, name it in the rules of engagement, and reflect it on every page of the verification report.
Level 1 (opportunistic)
Aligned with ASVS Level 1. Defends against opportunistic attackers using common, low effort attack techniques. Suited to applications with limited sensitive data exposure and no regulated requirement for deeper assurance. The OVS verification report names the requirements in scope and any deviations.
Level 2 (standard)
Aligned with ASVS Level 2. Defends against the majority of risks for applications that handle business critical or sensitive information. The default level for most commercial OVS engagements. Requires evidence based testing of access control, authentication, session management, input validation, cryptography, and business logic, mapped to ASVS requirements.
Level 3 (advanced)
Aligned with ASVS Level 3. Defends against advanced attackers and is appropriate for applications handling life or safety critical data or large volumes of regulated information. Requires substantially deeper testing and evidence, including code review where in scope, and a verification report that justifies the level claim against the OWASP requirement set.
OVS verification depends on traceability between the test cases performed and the ASVS or MASVS requirements they evidence. Findings management with CVSS 3.1 scoring and 300+ templates gives every finding a structured place to live, and OWASP and CWE tags can be carried alongside the finding so the verification report maps cleanly to the requirement set rather than to a generic vulnerability list. The web application testing use case captures the operational mechanics for an OVS aligned web application engagement.
CREST STAR and STAR FS: intelligence led red team for regulated entities
STAR and STAR FS engagements are run as joint exercises with a white team representing the commissioning organisation, a red team executing the scenario, and a blue team observing and responding. STAR FS is the financial services variant operated alongside the Bank of England CBEST programme and the Financial Conduct Authority, and is closely aligned with the ECB TIBER EU framework used elsewhere in Europe. Track the threat intelligence input, the scenario, the rules of engagement, the white team contacts, the red team operators, the blue team observations, and the joint debrief on the same record so the engagement deliverable is a structured workflow rather than a wrapped narrative document.
For the operational shape of an intelligence led engagement on the same platform, see the red team reporting use case and the purple team operations use case for the post engagement detection calibration step. Financial entities operating under DORA threat led penetration testing requirements typically use STAR FS, CBEST, or TIBER EU as the delivery framework, and the same engagement record covers all three with the appropriate evidence retained.
Reporting expectations: the deliverable, not an export
A CREST aligned report is a structured deliverable, not a wrap up. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and evidence density determine whether the engagement was actually useful.
- Executive summary that translates business risk for an audience that will not read the technical body, including a posture statement and the recommended actions ranked by impact
- Scope and methodology statement naming the CREST scheme (CHECK, OVS, STAR, or independent), the verification level if applicable, and the underlying methodology citations
- Authorisation summary referencing the signed authorisation document, the testing window, the rules of engagement, and any pre agreed exclusions
- Intelligence and reconnaissance section describing what was discovered before exploitation began, including external attack surface, exposed services, and any out of scope assets that were identified and excluded
- Vulnerability analysis with each finding scored under CVSS 3.1, mapped to OWASP, ASVS, MASVS, or CWE references where applicable, and tied to the asset and business impact it affects
- Exploitation evidence with reproduction steps, screenshots, and request and response artefacts retained alongside the finding so the customer can independently validate the result
- Post exploitation evidence describing what an attacker could achieve once a foothold existed, including pivoting, data access, and privilege escalation chains where relevant
- Remediation guidance written for the engineering audience that will fix the finding, with concrete actions rather than generic advice and references to CREST and OWASP guidance where relevant
- Retest summary covering each retested finding, the outcome (closed, partially closed, or still open), and any regression notes captured during the retest window
- Appendices for raw scanner output, supporting artefacts, and the engagement timeline, retained inside the engagement record for assessor and re engagement purposes
For a deeper write up on report structure, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the executive summary, technical body, and remediation roadmap from the underlying engagement, intelligence, findings, and exploitation evidence rather than a blank template, so the report cites the methodology and the evidence it actually rests on.
Retests, closure, and the assessor evidence pack
The CREST Defensible Penetration Test specification is explicit that retests are part of the engagement, not a follow on procurement. A retest mechanism that is built into the contract keeps the engagement aligned with verified closure rather than a list of issues, and it gives the assessor a defensible record at audit time. For the operational shape of a closure ready retest workflow, see how to retest vulnerabilities and the remediation tracking use case.
The assessor evidence pack is the bundle a buyer side compliance team or an external auditor needs to see after the engagement closes. It is usually requested months later, often in a hurry, and the operational test of a CREST aligned engagement is whether the evidence pack can be assembled on demand. Engagement records that retain the authorisation, rules of engagement, scanner output, finding history, retest evidence, and the final report inside one workflow pass that test without scrambling.
How CREST compares to PTES, OWASP, NIST SP 800-115, and ISO 27001
CREST is rarely used in isolation. It is the accreditation and quality wrapper around a methodology, a technical reference, and a compliance context. The contrast below is a working view, not a buyer comparison: the practitioner question is which standards to pair CREST with, not which to pick instead of it.
CREST vs PTES
PTES is a methodology specification that describes how to run a penetration test across seven sections from pre engagement to reporting. CREST is an accreditation body that certifies firms and individuals against a quality standard and operates the CHECK, OVS, and STAR schemes. They compose: a CREST member firm typically uses PTES (or an equivalent methodology) to deliver the engagement and the CREST scheme requirements to govern scope, evidence, and reporting.
CREST vs OWASP
OWASP publishes the Application Security Verification Standard, the Mobile Application Security Verification Standard, and the Web Security Testing Guide. CREST OVS adopts ASVS and MASVS as the verification standard. The OWASP guides describe what to test; CREST OVS describes the level, the report, and the firm and individual accreditation that backs it.
CREST vs NIST SP 800-115
NIST SP 800-115 is a US technical guide to security testing and assessment. It covers similar technical territory to PTES but is lighter on engagement scaffolding and reporting. NIST 800-115 is often required by reference in compliance contexts; CREST tends to be the preferred accreditation in the UK and parts of Europe and Asia for both the firm and the individual.
CREST vs ISO 27001
ISO 27001 is an information security management system standard, not a penetration testing standard. ISO 27001 Annex A.8.8 (technical vulnerability management) and clause 6.1 (risk treatment) are commonly satisfied with a CREST aligned penetration test. The two are complementary, and a CREST engagement is one of the most efficient evidence sources for the technical control side of an ISO 27001 audit.
Where SecPortal fits in a CREST aligned engagement
SecPortal is the operating layer for a CREST aligned engagement. The platform handles scope, team accreditation, intelligence and reconnaissance, vulnerability analysis, exploitation evidence, retests, and the final deliverable so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running CREST engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals, and cybersecurity firms and MSSPs get the same record with team and client scaling for larger delivery footprints.
- Engagement management captures the CREST scheme, the verification level for OVS engagements, the authorisation document, the testing window, and the rules of engagement as a structured record so the engagement scaffold is the workflow, not a contract attachment
- Team management records the certifications held by each tester on the engagement so the customer can verify CHECK Team Leader and Team Member status, OVS lead, or STAR red team lead credentials alongside the report
- Findings management with CVSS 3.1 scoring, 300+ templates, and Nessus and Burp Suite imports turns CREST vulnerability analysis into evidence backed records with severity, asset scope, owner, and links to ASVS, MASVS, OWASP, or CWE references
- Authenticated and external scanning produce the raw evidence the report depends on, retained per scan window and linked to the finding it supports so the assessor evidence pack is reproducible
- AI assisted reports compose the executive summary, technical body, and remediation roadmap from the underlying engagement, intelligence, findings, and exploitation evidence, citing the methodology used rather than starting from a blank template
- Client portal delivers the engagement on the consultancy subdomain so the customer sees the live engagement, retests, and remediation status rather than a frozen PDF, with branded styling that matches CREST member firm reporting expectations
- Compliance tracking lets one engagement satisfy CREST alongside framework mappings to ISO 27001, SOC 2, PCI DSS, NIS2, and DORA without rebuilding the bundle for each audit
Looking for the engagement workflow itself, end to end? The penetration testing use case and the pentest project management use case capture how SecPortal turns a CREST shaped engagement into a structured record covering scope, methodology, findings, retests, and the deliverable.
For deeper context on the procurement side, including how buyers should compare CREST aligned proposals on effective day rate, retest policy, reporting depth, and methodology citation, see the pentest pricing models research and the penetration testing methodology guide.
Key control areas
SecPortal helps you track and manage compliance across these domains.
CREST CHECK (UK government and critical national infrastructure)
CHECK is the UK government penetration testing scheme operated by the National Cyber Security Centre with CREST as the accreditation body. CHECK engagements are scoped to test IT systems used to process protected (formerly UK OFFICIAL or above) information for government departments, the wider public sector, and critical national infrastructure. Track CHECK Team Leader and Team Member assignments, the system in scope, the testing window, and the customer authority point of contact alongside the engagement record so the test team is verifiable from kickoff to sign off.
CREST OVS (OWASP Verification Standard for web applications)
CREST OVS aligns directly with the OWASP Application Security Verification Standard (ASVS) and the OWASP Mobile Application Security Verification Standard (MASVS). OVS engagements are explicit about the verification level (Level 1 opportunistic, Level 2 standard, Level 3 advanced) and the test cases mapped to each requirement. Track the OVS verification level on the engagement, tag every finding with the ASVS or MASVS requirement it evidences, and produce a verification report that names the level, the requirements tested, and the requirements not in scope.
CREST STAR and STAR FS (intelligence led red team testing)
CREST STAR (Simulated Targeted Attack and Response) and STAR FS are intelligence led red team frameworks for testing how an organisation detects, responds to, and recovers from a realistic adversary scenario. STAR FS is the financial services variant operated alongside the CBEST programme by the Bank of England and the Financial Conduct Authority. Track the threat intelligence input, the scenario, the rules of engagement, the white team, the red team, the blue team observations, and the joint debrief on a single record so the engagement deliverable is the workflow rather than a wrapped PDF.
CREST CRT and CCT (individual practitioner certifications)
CREST certifies individual practitioners through CRT (Registered Tester), CCT INF (Certified Tester Infrastructure), CCT APP (Certified Tester Application), and the Certified Simulated Attack Specialist tracks. The accreditation rests on the people who deliver the engagement, not just the firm. Capture the certifications held by each tester on the engagement record so the customer can verify the team is appropriately accredited for the scope, and so the report cites the lead tester credentials alongside the methodology.
CREST Defensible Penetration Test (the methodology baseline)
The CREST Defensible Penetration Test specification sets out what a buyer should expect from a credible penetration test independent of the specific scheme. It covers proportional scoping, qualified testers, evidence based reporting, retests, and a data handling regime that protects the customer through and after the engagement. Use the defensible test as the engagement scaffold, then layer the scheme specific requirements (CHECK, OVS, STAR) on top so the engagement satisfies both the scheme and the underlying methodology.
Reporting, retests, and the assessor evidence pack
CREST aligned reports are structured deliverables, not exports. Capture executive summary, scope, methodology citation, intelligence and reconnaissance, vulnerability analysis, exploitation evidence, post exploitation impact, risk per finding, remediation guidance, and retest outcomes. Retain raw scanner output, evidence artefacts, the rules of engagement, the authorisation letter, and the final report inside the engagement record so the assessor evidence pack is a click rather than a forensic exercise.
Related features
Run CREST aligned engagements without spreadsheet sprawl
Bring CHECK, OVS, STAR scoping, testing, reporting, retests, and assessor evidence into one workflow. Start free.
No credit card required. Free plan available forever.