Penetration Testing Methodology: From Scoping to Retesting

A penetration testing methodology provides a structured approach for assessing the security of systems, applications, and infrastructure. Rather than relying on a fixed checklist or a collection of automated tools, it guides penetration testers through a consistent process for understanding the target environment, identifying vulnerabilities, assessing their potential impact, and communicating the results.

A well-defined penetration testing process also needs to remain flexible. The techniques used during an assessment will vary depending on the scope, technology, available information, and type of assessment. Testing a web application, for example, requires a different technical approach from assessing a corporate network or cloud environment, even though the overall methodology follows the same principles.

This guide is intended for security and IT teams, technical leaders, compliance stakeholders, and organizations planning or evaluating a penetration test and looking to understand what a professional pentesting methodology should include. Here, we explain the overall penetration testing methodology we use at Blaze Information Security, the standards that inform it, and the main phases of an assessment.

Why methodology matters

A penetration test is most valuable when it goes beyond simply finding isolated security weaknesses. Without a consistent penetration testing methodology, assessments can become overly dependent on individual tools, checklists, or the tester's experience.

This can result in security gaps, inconsistent coverage, false positives, or vulnerabilities being assessed without sufficient business context. Automated tools and vulnerability scanning are useful parts of the process, but they cannot fully reproduce the reasoning and adaptability required to simulate real-world attacks.

A structured approach also makes the penetration testing process more repeatable and transparent. The scope and testing methods are established in advance, findings are validated according to defined criteria, and the resulting penetration testing report can clearly explain both the technical issue and its potential impact.

At the same time, methodology should not mean following the same checklist for every assessment. Effective penetration testing combines a consistent core process with the flexibility to adapt testing techniques to the organization's systems, technologies, attack surface, and objectives.

Penetration testing standards and frameworks

There is no single penetration testing standard that applies equally well to every type of assessment. Instead, a robust testing methodology draws from established industry standards and technical guidelines, selecting the practices that are most relevant to the target environment and objectives of the engagement.

The Penetration Testing Execution Standard (PTES) provides a useful foundation for the overall testing process, covering activities from pre-engagement and intelligence gathering through vulnerability analysis, exploitation, post-exploitation, and reporting. NIST SP 800-115 provides additional guidance for planning and conducting technical security assessments, while the Open Source Security Testing Methodology Manual (OSSTMM) offers a structured methodology for operational security testing across different environments.

Beyond these general frameworks, more specialized guidance is used depending on what is being assessed. OWASP, for example, provides different standards and testing guides for web and mobile applications, while cloud assessments may also draw on provider-specific guidance, CIS benchmarks, and MITRE ATT&CK.

These resources inform our methodology rather than functioning as rigid checklists. The exact combination depends on the technology, scope, threat model, and security risks of each engagement.

The penetration testing process

The penetration testing process is a structured progression from defining the scope to validating findings and supporting remediation. While the exact techniques vary between engagements, the core phases remain broadly consistent: understand the target, map its attack surface, identify and validate weaknesses, assess their impact, and communicate the results clearly.

This approach reflects established security testing guidance while remaining flexible enough to adapt to the technology, objectives, and risk profile of each assessment.

Scoping and rules of engagement

Every penetration test starts by defining what can be tested, how it can be tested, and what the assessment is intended to achieve. A clear scope identifies the applications, APIs, IP addresses, networks, cloud environments, user roles, or other assets that penetration testers are authorized to assess, as well as anything explicitly excluded from testing. Blaze’s existing guidance similarly emphasizes defining scope boundaries around the systems and sensitive workflows that matter to the organization.

The rules of engagement (ROE) establish the operational constraints for the assessment. These can include permitted testing methods, testing windows, prohibited or potentially disruptive activities, data-handling requirements, escalation contacts, and procedures for responding to unexpected issues or critical findings.

Well-defined scope and rules of engagement give pen testers clear authorization while reducing unnecessary operational risk.

Preparation and information gathering

Once the scope is agreed, the testing team gathers the information and access needed to understand the target environment and conduct the assessment efficiently. Depending on the engagement, this may include architecture diagrams, application or API documentation, test accounts for different user roles, authentication details, VPN or environment access, IP allowlisting, mobile application builds or test devices, sample requests, test data, network information, and other relevant technical constraints.

Good preparation allows penetration testers to spend more time investigating meaningful security weaknesses instead of troubleshooting missing access or incomplete documentation. Blaze’s guidance for web, API, SaaS, and mobile assessments consistently recommends providing appropriate documentation, role-specific accounts, and information about important workflows before testing begins.

The amount of knowledge provided also depends on whether the engagement follows a black-box, gray-box, or white-box approach. Regardless of the model, the goal is to establish enough context to begin systematic security testing without unnecessarily limiting the tester’s perspective.

Attack-surface mapping and threat modelling

With the necessary context in place, penetration testers map the attack surface of the target environment. This means identifying the systems, interfaces, trust relationships, entry points, user roles, data flows, exposed services, and integrations that could potentially be abused. Blaze’s existing guidance emphasizes that effective penetration testing should be scoped around the real attack surface, because different systems expose different types of risk.

Threat modelling adds context to that map. Instead of treating every component equally, testers consider which assets handle sensitive data, where privilege boundaries exist, how users and systems trust one another, and which paths could lead to greater impact if compromised.

This helps focus the assessment on realistic attack scenarios rather than isolated technical checks. In complex environments, the most significant risks often emerge from weaknesses that span multiple systems or trust boundaries rather than from a single vulnerability.

Automated and tool-assisted discovery

Automated penetration testing tools help quickly identify known weaknesses and generate leads for deeper investigation. Depending on the assessment, tools may help enumerate endpoints, detect open ports and network services, identify outdated software or common misconfigurations, crawl applications, and flag potential vulnerabilities across the target systems.

At Blaze, automation supports the pen testing process rather than replacing the tester. Our experience is that automated tools are particularly effective at repetitive tasks and initial vulnerability assessment, but their output still requires manual validation. Scanners can produce false positives, miss business-logic flaws, and struggle to understand complex trust relationships or multi-step attack paths.

The results of this discovery phase therefore provide penetration testers with useful leads that can be investigated, validated, and expanded upon during manual security testing.

Manual security testing

Manual security testing is the core of our penetration tests. At this stage, experienced penetration testers investigate the leads identified earlier, test assumptions about how the system should behave, and look for weaknesses that automated tools are unlikely to understand.

The exact testing methods depend on the target, but common areas include authentication, authorization, session management, input validation, business logic, access controls, cryptography, and exposure of sensitive information. In web applications, for example, testers may assess issues such as broken access control or cross-site scripting, while network penetration testing may focus more heavily on exposed services, trust relationships, privilege escalation, and other network security weaknesses. Blaze’s existing guidance emphasizes that manual testing is particularly important for business logic, authorization boundaries, privilege escalation, and chained attack paths.

Manual testing also allows testers to adapt as they learn more about the target. Rather than following a rigid checklist, they can investigate unexpected behavior, compare different user accounts, and explore how weaknesses interact. This human-led analysis is often what uncovers vulnerabilities that scanners miss and reveals their real impact on the organization's security posture.

Exploitation and attack chaining

Once a vulnerability has been validated, penetration testers may exploit vulnerabilities further to determine what an attacker could realistically achieve. Depending on the scope and rules of engagement, this can include gaining access to restricted functionality or sensitive data, escalating privileges, moving between connected systems, or demonstrating how a compromised account or service could be used to reach additional assets. PTES treats exploitation and post-exploitation as distinct stages for understanding the actual value and impact of a compromise.

The most serious risks do not always come from a single critical flaw. Several lower-severity weaknesses may be chained together to create a much more damaging attack path. Blaze's 2025 penetration testing review also showed that some of the highest-impact findings resulted from combining multiple weaknesses, reinforcing why vulnerabilities should be assessed in context rather than only by their individual severity.

Exploitation should always remain controlled and proportionate: the objective is to gather enough evidence to demonstrate impact without creating unnecessary risk to the target organization.

Risk assessment and reporting

Once testing is complete, the vulnerabilities found are reviewed and assessed in context. Severity should reflect not only the technical characteristics of a weakness, but also factors such as exploitability, required privileges, exposed sensitive information, affected systems, and the potential impact on the target organization. Blaze's reporting guidance similarly recommends combining severity scoring with business context, since frameworks such as CVSS may not fully capture risks such as fraud, data leakage, or chained attack scenarios.

The National Vulnerability Database (NVD), maintained by NIST, uses the Common Vulnerability Scoring System (CVSS) to provide standardized severity assessments for published vulnerabilities. We use CVSS to classify all vulnerabilities identified during our assessments. Each vulnerability is assigned a numerical CVSS score and a corresponding CVSS vector string — a compact code that records the metric values used to calculate that score. This makes the rating transparent and reproducible rather than relying only on a subjective severity label.

The findings are then documented in a comprehensive report that typically includes an executive summary, scope and methodology, technical evidence, affected components, reproduction steps, risk ratings, impact, and practical remediation recommendations. Blaze also includes technical summaries that provide context around attack scenarios and overall test coverage.

Clear reporting turns the results of a penetration test into actionable information for security teams, developers, management, and other stakeholders. NIST likewise recommends documenting testing results together with mitigation actions so they can support corrective and risk-management activities.

Debrief, remediation and retesting

The penetration testing process does not end with delivery of the report. A debrief gives technical and business stakeholders an opportunity to review the most important findings, clarify attack scenarios, discuss remediation priorities, and ask questions about the recommended fixes. Blaze’s web application penetration testing guidance includes both post-pentest debriefing and remediation guidance as part of the assessment lifecycle.

Once vulnerabilities have been addressed, retesting verifies whether the remediation was effective. It is typically narrower than a new penetration test and focuses on previously reported findings, although testers should also consider whether a fix has introduced new security weaknesses. Blaze recommends retesting important findings promptly after remediation rather than assuming that a change has fully resolved the issue.

This final validation turns remediation into evidence and helps the organization demonstrate that identified security risks have been properly addressed.

Tools that support our penetration testing methodology

Penetration testing relies on a broad set of tools for tasks such as attack-surface discovery, traffic interception, vulnerability analysis, reverse engineering, cloud assessment, and exploitation validation. The exact toolkit depends on the technology and scope, and tools are used to support manual analysis rather than replace it.

Examples include Burp Suite Professional, Postman, ffuf, and Kiterunner for web and API testing; MobSF, Frida, Objection, Ghidra, and jadx for mobile assessments; Prowler, ScoutSuite, CloudFox, and Pacu for cloud testing; and hardware-focused tools such as Bus Pirate and JTAGulator for IoT assessments. These categories reflect some of their most common uses in our engagements, but many of these tools can also support other types of penetration testing depending on the target and testing objectives.

The tools vary between engagements, but the objective is consistent: improve efficiency and coverage while relying on tester judgment and manual validation to determine real-world impact.

How Blaze adapts the core methodology to different assessments

The core penetration testing methodology remains consistent across most engagements, but the testing techniques, tools, and areas of focus are adapted to the technology and attack surface in scope.

This article provides a general overview of Blaze’s penetration testing methodology. The exact testing approach varies by engagement type, and readers looking for more detail can explore our dedicated guides to web application, API, mobile application, cloud, SaaS, IoT, LLM and other types of penetration testing, which cover the methodologies, preparation requirements, common findings, and testing considerations specific to each environment.

For a web application, for example, testing typically places greater emphasis on authentication, authorization, session management, input validation, APIs, and business logic. Mobile application penetration testing adds areas such as local data storage, platform security controls, reverse engineering, inter-process communication, and the security of backend API calls.

Cloud and network assessments require a different technical focus. Cloud testing may examine IAM permissions, exposed storage, secrets, workloads, and privilege-escalation paths, while network penetration testing focuses more heavily on exposed services, segmentation, authentication, and trust relationships between systems. Blaze’s existing guidance shows that different types of penetration testing reveal different risk patterns, even when they follow the same overall testing process.

Where social engineering testing is included in the scope, Blaze can also evaluate the human element of security using controlled manipulation techniques, including phishing tests. The objective is to assess employee security awareness and the effectiveness of organizational procedures rather than to single out individual employees. NIST SP 800-115 similarly describes social engineering as a testing technique for evaluating user awareness and identifies phishing as one common digital form of social engineering.

Modern environments also rarely fit into a single category. SaaS platforms, for instance, often combine web applications, APIs, cloud infrastructure, identity systems, and third-party integrations. In these cases, the methodology is adapted around architecture, data flows, and trust boundaries rather than treating each component in isolation.

The goal is not to apply the same checklist everywhere, but to maintain a consistent process while directing testing effort toward the security risks that matter most for each environment.

Final thoughts

Penetration testing methodologies can become highly detailed and vary significantly depending on what is being tested. This article provides an overall view of the methodology that underpins our penetration testing engagements: the core process remains structured and repeatable, but the exact approach is adapted to the technology, attack surface, scope, and security risks of each assessment.

Ultimately, a strong methodology should provide consistency without turning every penetration test into the same checklist.