Our Methodology

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.

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.

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.

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 API posture is audited agentlessly with a customer-supplied read-only 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 read-only kubeconfig. Node-level CIS Kubernetes Benchmark checks then run as a short-lived, least-privilege job with host read access (kube-bench), removed after the run, on self-managed, on-prem, and managed worker nodes. On GKE, EKS, and AKS, control-plane CIS items are reported as not applicable (provider-managed), not as a pass. On fully-managed runtimes such as GKE Autopilot and EKS Fargate, where host-level pods are not permitted, the node CIS job is skipped and API posture still runs over the kubeconfig. See cloud penetration testing and Kubernetes security testing.

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.

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.

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.