PTES
Penetration Testing Execution Standard
OWASP
Web Security Testing Guide v4.2
NIST
SP 800-115 Technical Guide
CREST
Aligned to CREST testing methodology guidance
CIS Benchmarks
Kubernetes & Cloud Configuration Baselines

The seven phases

Every phase below is documented the same way: what happens, how it stays inside the authorised scope, what it produces, and the capabilities involved. Phases run in order on every assessment, and each one feeds the next.

1

Pre-Engagement

Nothing is scanned until scope is agreed in writing. We define the target list, the testing windows, and the success criteria for the assessment, then record which assets are explicitly in scope and which are out. Legal authorisation, emergency contacts, and the channel used to stop testing at short notice are captured at the same time.

The signed Rules of Engagement is enforced by the platform, not just filed. Scope is held per tenant and checked when work is dispatched, so a scan or exploitation attempt aimed at an asset outside the authorised list is refused rather than reported after the fact. Cloud accounts and Kubernetes clusters are authorised individually before any credential or kubeconfig is used.

What this phase produces
  • A signed Rules of Engagement covering every asset class in scope
  • An in-scope and out-of-scope asset register enforced at dispatch time
  • Named emergency contacts and an agreed escalation path
Scope Definition Legal Authorisation Emergency Contacts Rules of Engagement
2

Reconnaissance & OSINT

Passive and active reconnaissance builds the picture of your attack surface before anything intrusive runs. Subdomain enumeration, DNS and certificate data, exposed services, and published email addresses are collected and correlated, so testing starts from what is actually reachable rather than from the asset list somebody remembered to update.

External reconnaissance runs across 24+ recon modules. Internal reconnaissance adds 18+ modules that execute from the on-premise agent inside your network, reaching segments no external scanner can see. Discovered assets are classified with a criticality rating and re-verified on a 7-day cycle, which keeps the surface map current between scheduled assessments. See external attack surface management for how this runs continuously.

What this phase produces
  • A mapped attack surface: domains, hosts, exposed services, and cloud footprint
  • A classified asset inventory with criticality and ownership
  • A drift record of what appeared or disappeared since the previous sweep
Subfinder httpx DNS Enumeration Attack-Surface Mapping Asset Classification
3

Scanning & Enumeration

Active scanning against the confirmed in-scope targets identifies open ports, running services, and software versions, then probes each service for known weaknesses. Scanning is multi-threaded with intelligent rate limiting, so coverage stays thorough without knocking over the production systems being tested.

Three scan profiles (Stealth, Balanced, and Aggressive) let you trade depth against noise per engagement. Web and API endpoints receive OWASP Top 10 and API Top 10 coverage, including SQL injection, cross-site scripting, SSRF, IDOR, and authentication bypass, across both REST and GraphQL. Findings stream into the portal over a WebSocket as they are raised, so triage can start before the run finishes. See internal network penetration testing and web application penetration testing.

What this phase produces
  • A port, service, and version inventory for every in-scope host
  • A raw finding set with CVE references and observed evidence
  • A live finding stream in the portal while the scan is still running
Port Discovery Service Detection CVE Scanning Web Server Audit OWASP Top 10 API Top 10
4

Cloud & Kubernetes Posture

Beyond the network, we audit cloud accounts and Kubernetes clusters for misconfiguration. Cloud configuration is reviewed across AWS, Azure, GCP, and Microsoft 365 with 800+ automated checks covering identity, storage, network, and configuration against provider baselines and the CIS Benchmarks. Kubernetes is audited agentlessly using a customer-supplied kubeconfig, so there is no permanent agent and no DaemonSet to install. The platform verifies connectivity and detects the distribution before any scan runs.

Two layers run on every onboarded cluster. An API posture review of 83 Kubernetes API and RBAC checks covers roles and bindings, workload security context, privileged and host pods, capabilities, network policy, and image provenance over the kubeconfig. A node-level CIS Kubernetes Benchmark then runs as a short-lived, auto-cleaned job inside the cluster on self-managed, on-prem, and managed nodegroups. On fully-managed runtimes such as GKE Autopilot and EKS Fargate, where host-level pods are not permitted, node and control-plane CIS checks are routed through the cloud configuration audit instead, while the API posture review still runs over the kubeconfig. See cloud penetration testing and Kubernetes security testing.

What this phase produces
  • A CIS Benchmark result set per cloud account and per cluster
  • An RBAC and workload-posture review with the offending manifests identified
  • A prioritised misconfiguration list mapped to the reporting frameworks
Prowler ScoutSuite CloudSploit kubeaudit kube-bench (CIS) kubeconfig (agentless)

Universal cluster support, no agent

GKE (including Autopilot), EKS (including Fargate), AKS, OpenShift, k3s, and self-managed or on-prem clusters onboard one-click as a verified asset. Paste a ServiceAccount-token kubeconfig and the cluster is ready to audit.

5

Vulnerability Analysis

Raw scanner output is not a finding. Every result is correlated against the CVE database, scored with CVSS v3.1, and checked for known exploit availability and CISA KEV listing. False-positive reduction removes results that do not hold up against the evidence actually captured from the service, so the queue handed to your team is a queue worth working through.

PentestOps AI then adds context: risk scoring against the exposure and role of the affected asset, attack-chain prediction where several individually moderate findings combine into one path, and business-impact analysis. The AI is self-hosted by default on infrastructure Extranet Systems operates, so scan data is not sent to third-party model providers; external providers can be enabled per tenant at your discretion. See attack path validation for how chains are assembled.

What this phase produces
  • A deduplicated, severity-ranked finding set scored with CVSS v3.1
  • An exploitability signal per finding: public exploit availability and KEV status
  • Predicted attack chains and business-impact context for the top findings
CVE Database CVSS v3.1 CISA KEV False-Positive Reduction PentestOps AI
6

Exploitation & Validation

Validation is what separates a scanner result from something you have to act on this week. Where a vulnerability is confirmed, safe automated exploitation attempts an auditable proof of exploit against it. A strategy engine picks the technique best suited to that specific finding instead of throwing every available module at the target.

Phased exploit chains show what one weak credential actually buys an attacker: privilege escalation, lateral movement, and the data or systems that become reachable are demonstrated and recorded rather than assumed. Every attempt is gated by the per-tenant Rules of Engagement, with scope enforcement that stops activity outside authorised assets automatically, and every step lands in the evidence trail. This is proof, not guesswork.

What this phase produces
  • Captured proof-of-exploit evidence attached to each validated finding
  • A documented attack path from initial access to escalation and lateral movement
  • A full audit trail of every attempt, including the ones that were refused as out of scope
SQL Injection Validation Credential Testing Vulnerability Verification Web Proxy Inspection Exploit Chaining RoE Scope Enforcement
7

Reporting & Remediation

Reporting serves two audiences in one document: an executive summary that states business risk without jargon, and a technical section carrying reproduction detail, captured evidence, and a remediation order driven by proven exploitability rather than raw severity. Reports are produced as PDF, CSV, and JSON over the API, so findings can flow straight into your existing tracker.

Findings are auto-mapped to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, and SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. These are the frameworks findings map to in reports, not a statement that anyone is certified. AI-guided remediation supplies per-finding fix steps, and on Enterprise a playbook can be deployed through the on-premise agent over SSH and rolled back automatically if validation fails. Re-scan closes the loop and records the fix.

What this phase produces
  • An executive summary plus a technical report in PDF, CSV, and JSON/API
  • Control-level compliance mapping across the 8 frameworks plus CIS Benchmarks
  • Per-finding remediation steps, with re-scan evidence once the fix is applied
PDF Reports CSV Export JSON/API Compliance Mapping AI Remediation

How our phases map to PTES, OWASP and NIST

The seven phases above are our naming, not a new standard. Each one lines up with a phase of the Penetration Testing Execution Standard and a stage of NIST SP 800-115 (planning, discovery, attack, reporting), with the relevant chapter of the OWASP Web Security Testing Guide v4.2 where web and API testing applies. Background reading: PTES explained and NIST SP 800-115.

PentestOps phases mapped to PTES phases, NIST SP 800-115 stages, and OWASP WSTG v4.2 areas.
PentestOps phase PTES phase NIST SP 800-115 stage OWASP WSTG v4.2 area
1.Pre-Engagement Pre-engagement Interactions Planning The OWASP Testing Framework: scope, authorisation, and test planning
2.Reconnaissance & OSINT Intelligence Gathering Discovery Information Gathering (WSTG-INFO)
3.Scanning & Enumeration Intelligence Gathering and Threat Modelling Discovery Configuration and Deployment Management, Authentication, Authorisation, Session Management, Input Validation, API Testing
4.Cloud & Kubernetes Posture Vulnerability Analysis (configuration review) Discovery Configuration and Deployment Management, extended by CIS Benchmarks for cloud and Kubernetes
5.Vulnerability Analysis Vulnerability Analysis and Threat Modelling Discovery (analysis) Analysis of results across the WSTG test categories, including business logic
6.Exploitation & Validation Exploitation and Post Exploitation Attack Verification of identified weaknesses under the WSTG test cases
7.Reporting & Remediation Reporting Reporting Reporting (WSTG chapter 5)

Why Methodology Matters

A structured penetration testing methodology produces comparable, defensible findings. Without one, assessments drift toward whatever looked interesting on the day, and unverified results pile up in the queue and burn remediation effort that should have gone somewhere else.

  • Comprehensive Coverage A fixed phase order means the same ground is covered on every assessment
  • Repeatable Results Consistent methodology produces comparable results over time
  • Compliance Alignment Findings map to the reporting frameworks your auditors already ask for
  • Risk Prioritisation Remediation effort follows proven exploitability, not raw severity counts

Industry Best Practice

Our methodology combines the best elements of PTES, OWASP, and NIST frameworks, so an assessment lines up with the standards your auditors and your board already recognise.

Open-Source Attribution: Our platform integrates industry-standard open-source security tools. All third-party tools remain the property of their respective authors and are used under their original licences. All third-party trademarks are the property of their respective owners and are used solely for identification purposes.

Frequently Asked Questions

Which standards does the PentestOps methodology follow?

Our methodology combines the best elements of the PTES, OWASP and NIST frameworks. Testing follows the Penetration Testing Execution Standard, the OWASP Web Security Testing Guide v4.2 and NIST SP 800-115, and is aligned to CREST testing methodology guidance. Cloud and Kubernetes configuration is measured against the CIS Benchmarks. For the detail behind those standards, read PTES explained and NIST SP 800-115 explained.

What are the seven phases of a PentestOps assessment?

Every assessment runs through the same seven phases: Pre-Engagement (scope, rules of engagement, authorisation and emergency contacts), Reconnaissance and OSINT, Scanning and Enumeration, Cloud and Kubernetes Posture, Vulnerability Analysis, Exploitation and Validation, and Reporting and Remediation. The phases are the same whether you run one asset or an entire environment, which is what makes results comparable between scans.

How do you keep exploitation safe on production systems?

Exploitation is gated by per-tenant Rules of Engagement. Scope enforcement automatically stops activity that falls outside your authorised assets, and every action is recorded against the signed authorisation with a full evidence trail. A strategy engine picks the safest technique that can prove a finding rather than the most damaging one, and the goal is always proof rather than disruption. The scope rules you set are described on our rules of engagement page.

Will scanning disrupt production services?

Scanning is multi-threaded with intelligent rate limiting, and you choose the profile that suits the target: Stealth, Balanced or Aggressive. Stealth is designed for sensitive or latency-critical systems, Balanced is the default for most environments, and Aggressive is for staging or maintenance windows where depth matters more than noise. You can also exclude specific hosts or paths from any scan.

How are cloud accounts and Kubernetes clusters tested?

Phase four reviews cloud configuration across AWS, Azure, GCP and Microsoft 365 against provider baselines and the CIS Benchmarks, with 800+ automated checks. Kubernetes is audited agentlessly using a customer-supplied read-only kubeconfig, so there is no permanent agent and no DaemonSet to install. An API posture review runs on every cluster, and a node-level CIS benchmark runs as a short-lived, auto-cleaned job where the cluster permits host-level pods. See cloud penetration testing and Kubernetes security testing.

How do you decide which findings matter most?

Vulnerability analysis correlates results against the CVE database, removes false positives, and then prioritises by CVSS v3.1 score, exploit availability, CISA KEV status and business impact. Validation adds the decisive input: a finding that has been proven exploitable in your environment outranks a theoretically severe one that is not reachable. Attack path validation explains why that distinction changes remediation order.

What do I get at the end of an assessment?

Reporting covers an executive summary, technical detail, captured evidence and prioritised remediation guidance, in multiple report formats including PDF, CSV and JSON/API. Findings are mapped to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. Those mappings evidence your own posture; they are not a statement of PentestOps' certification.

Does this methodology replace human penetration testers?

No, and we do not claim it does. Automation runs the repeatable, high-volume work continuously so your people can spend their time on the creative testing that automation is poor at, such as complex business logic abuse. Most mature programmes pair continuous platform coverage with a periodic human engagement. We explain that split honestly on automated penetration testing.

Ready to Start Your Security Assessment?

Run the same seven phases against your own environment with a free demo scan.

Launch Security Scan