Penetration Testing Methodologies and Planning

Introduction

A penetration test is an authorised, controlled security assessment in which a tester evaluates whether weaknesses in people, processes, applications, systems, or networks can be used to violate defined security objectives. It is not simply a vulnerability scan and it is not an unrestricted attempt to “break into” an organisation. A professional penetration test is a governed activity with a documented purpose, agreed boundaries, safety controls, evidence requirements, and reporting obligations.

Planning is the foundation of a useful test. Poorly planned testing can disrupt production services, expose personal data, create legal disputes, or produce results that cannot be reproduced. Well-planned testing produces defensible evidence and helps an organisation prioritise risk reduction.

This chapter introduces several complementary approaches: the Penetration Testing Execution Standard (PTES), NIST Special Publication 800-115, the OWASP Web Security Testing Guide (WSTG), OSSTMM, MITRE ATT&CK, and cyber kill-chain concepts. These frameworks do not compete in every respect. Some describe an engagement lifecycle, some provide technical testing guidance, and others help analysts interpret adversary behaviour.

Learning Objectives

By the end of this chapter, learners should be able to:

• explain why penetration testing requires formal planning and authorisation;
• distinguish PTES, NIST, OWASP, OSSTMM, MITRE ATT&CK, and cyber kill-chain concepts;
• define objectives, scope, exclusions, assumptions, rules of engagement, and success criteria;
• create risk-based test cases and prioritise resources and timelines;
• design an engagement plan that protects people, systems, evidence, and confidentiality;
• interpret findings in relation to business impact and adversary behaviour; and
• identify ethical, legal, governance, and operational limitations of penetration testing.

1. The Role of Methodology

A methodology is a structured way of deciding what to test, how to test it, what evidence to collect, and how to communicate results. Methodologies improve consistency and reduce the likelihood that important areas will be overlooked.

A methodology does not remove professional judgement. Two organisations may use the same framework but require different tests because their assets, threats, regulations, architecture, and risk tolerance differ. Methodologies should therefore be adapted, documented, and approved rather than followed mechanically.

1.1 Penetration testing and related activities

Several security activities are often confused:

A penetration test may use scanners, but a scan alone is not a penetration test. Testing should answer a business or security question, such as whether customer records can be accessed from an internet-facing application or whether a compromised employee account could reach sensitive systems.

2. Major Methodologies and Frameworks

2.1 PTES

The Penetration Testing Execution Standard organises an engagement into seven broad phases:

1. pre-engagement interactions;
2. intelligence gathering;
3. threat modelling;
4. vulnerability analysis;
5. exploitation;
6. post-exploitation; and
7. reporting.

PTES is valuable because it emphasises the complete engagement rather than isolated technical actions. Pre-engagement work establishes authority and boundaries. Intelligence gathering develops an understanding of the target. Threat modelling relates technical weaknesses to likely adversaries and business assets. Vulnerability analysis identifies candidate weaknesses, while exploitation validates their practical significance. Post-exploitation examines what access would permit within the agreed limits. Reporting converts evidence into decisions.

PTES should not be interpreted as permission to conduct any activity that appears in a technical guide. Every phase remains constrained by the signed authorisation and rules of engagement.

2.2 NIST SP 800-115

NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, presents a structured approach to planning and conducting technical security tests. It discusses planning, discovery, attack, and reporting activities, while also addressing test types, rules of engagement, data handling, and analysis.

NIST is particularly useful for organisations that need formal governance. It encourages clear objectives, documented scope, test plans, approvals, safety procedures, evidence management, and remediation tracking. It also distinguishes techniques such as network discovery, vulnerability scanning, password testing, controlled penetration testing, and application assessment.

2.3 OWASP WSTG

The OWASP Web Security Testing Guide provides a systematic approach to testing web applications and web services. Its coverage includes information gathering, configuration and deployment management, identity management, authentication, authorisation, session management, input validation, error handling, weak cryptography, business logic, client-side testing, and API-related concerns.

OWASP guidance is application-focused. It is especially useful for building web-application test cases, but it does not replace engagement-level planning. For example, an OWASP test may identify an authorisation flaw, while the engagement plan determines whether testing may use production accounts, which records may be viewed, and how evidence must be redacted.

2.4 OSSTMM

The Open Source Security Testing Methodology Manual (OSSTMM) emphasises repeatable operational testing and the examination of security controls across channels such as human, physical, wireless, telecommunications, and data networks. It encourages explicit definitions of scope, operational constraints, test conditions, and measurement.

OSSTMM can broaden a test beyond conventional network vulnerability assessment. Its operational perspective is useful when an organisation needs to understand how physical access, human processes, wireless exposure, or communication channels affect security. However, the tester must ensure that social engineering and physical tests have explicit consent, safety controls, and legal review.

2.5 MITRE ATT&CK

MITRE ATT&CK is a knowledge base describing adversary tactics, techniques, and procedures. Tactics represent goals such as initial access, execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Techniques describe ways adversaries may pursue those goals.

ATT&CK is not, by itself, a complete penetration-testing lifecycle. It is useful for threat-informed planning, test-case selection, coverage mapping, detection validation, and reporting. A test plan might map authorised scenarios to techniques relevant to the organisation’s sector and threat model. The mapping should describe the objective and evidence sought, not encourage uncontrolled activity.

2.6 Cyber kill-chain concepts

The Lockheed Martin cyber kill chain describes a sequence commonly presented as reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. It helps analysts understand an attack as a progression rather than as a single event.

The model is useful for explaining where preventive and detective controls operate. Its limitations are equally important: modern attacks may be non-linear, may begin with valid credentials, and may omit several stages. ATT&CK generally offers more detailed behavioural coverage, while the kill chain provides a concise narrative for campaign progression. They can be used together without treating either as a perfect representation of every attack.

2.7 Choosing and combining frameworks

A practical combination may look like this:

The selected references, versions, adaptations, and exclusions should be recorded in the test plan. This makes the assessment transparent and repeatable.

3. Defining the Engagement

3.1 Objectives

An objective states what the engagement must determine. Objectives should be specific enough to guide testing and evaluation. Examples include:

• determine whether an unauthenticated internet user can access customer information;
• assess whether application roles enforce separation of duties;
• evaluate the exposure of externally reachable services;
• determine whether selected security controls detect and respond to authorised attack simulations; or
• validate whether a segmentation boundary prevents access from a user network to a payment environment.

Objectives should not be expressed only as “find vulnerabilities.” They should identify the security property or business concern being assessed.

3.2 Scope

Scope identifies the assets, environments, identities, locations, and techniques included in testing. It may include domain names, IP ranges, cloud accounts, applications, mobile clients, APIs, wireless networks, physical sites, or business processes.

A scope statement should distinguish:

• in-scope assets: targets that may be tested;
• out-of-scope assets: targets that must not be tested;
• in-scope activities: permitted techniques and validation actions;
• prohibited activities: actions such as denial of service, destructive changes, persistence, or access to real personal records unless explicitly approved; and
• third-party boundaries: systems owned by suppliers or hosting providers requiring separate authorisation.

IP ownership alone does not establish permission. Cloud resources, shared hosting, managed services, and third-party platforms require confirmation of contractual and provider requirements.

3.3 Assumptions and constraints

Assumptions are conditions accepted as true for planning purposes, such as the availability of test accounts, the accuracy of an asset inventory, or the presence of a technical contact. Constraints may include testing windows, rate limits, data-residency requirements, production safety restrictions, or limited tester access.

Every important assumption should have an owner and, where possible, a validation method. An incorrect assumption can invalidate conclusions. For example, a conclusion about segmentation is unreliable if the test was performed from a privileged network rather than the user network described in the objective.

3.4 Rules of engagement

Rules of engagement translate authorisation into operational instructions. They commonly specify:

• authorised parties and signatures;
• dates, time zones, and maintenance windows;
• source addresses and tester identities;
• permitted and prohibited techniques;
• handling of credentials and sensitive information;
• limits on automated requests and account lockouts;
• escalation contacts and stop conditions;
• evidence storage, encryption, retention, and destruction;
• incident handling if real compromise or harm occurs; and
• reporting, dispute, and retest procedures.

A stop condition might include unexpected instability, evidence of access to highly sensitive data, interaction with a safety-critical system, or a request from the authorised emergency contact. The tester should stop, preserve minimal necessary evidence, notify the designated contact, and wait for direction.

3.5 Success criteria

Success criteria define what constitutes a sufficiently answered objective. For example, a segmentation test may require evidence that a specified low-privilege position cannot reach a protected service, while also documenting the controls observed and the test limitations. Success is not necessarily the discovery of a vulnerability; a well-supported negative result can be valuable.

4. Risk-Based Engagement Planning

Risk-based planning allocates effort according to likely business consequence and exposure rather than treating every asset equally. A simple qualitative model may classify risk using likelihood and impact categories. If an organisation uses numerical scoring, the meaning and scale must be defined rather than assumed.

A common prioritisation expression is:

Here, likelihood and impact are ordinal or numerical ratings defined by the organisation. The expression is a planning heuristic, not a universal scientific law. Multiplying ordinal categories can imply precision that the underlying judgement does not possess; therefore, the resulting score should be supplemented by expert review and business context.

Factors that may increase priority include internet exposure, sensitive data, privileged functionality, exploitability, weak monitoring, regulatory obligations, business criticality, and evidence of active threats. A lower technical severity may receive high attention when it affects a critical process or combines with another weakness.

4.1 Test-case design

A test case converts an objective into a controlled assessment activity. A useful test-case record includes:

Test cases should be written so another qualified tester can understand what was attempted and why. They should not contain unnecessary secrets or unapproved exploit instructions.

4.2 Resources and roles

An engagement plan should identify the engagement manager, lead tester, specialist testers, client owner, system owners, security monitoring contact, legal or privacy adviser, and emergency contact. It should also list required tools, test accounts, network access, secure evidence storage, communication channels, and backup arrangements.

Independence and competence matter. Testers must understand the technologies being assessed and the consequences of their actions. Where specialist knowledge is absent, the plan should include a qualified reviewer or narrow the scope.

4.3 Timeline and dependencies

A timeline should include preparation, reconnaissance, testing, analysis, draft reporting, client review, final reporting, and retesting. Dependencies may include approval of cloud-provider testing, delivery of test accounts, configuration of monitoring, or completion of a backup.

A short engagement is not automatically efficient. Compressing preparation may increase test risk and reduce coverage. The plan should reserve time for validating findings, removing false positives, documenting limitations, and securely handling evidence.

5. Conduct, Evidence, and Reporting

Testing should follow the approved plan while allowing controlled adjustment when new information appears. Deviations must be recorded with the reason, authorisation, time, affected asset, and consequence for interpretation.

Evidence should be sufficient to support a finding without collecting unnecessary sensitive data. Useful evidence may include timestamps, request and response metadata, affected roles, redacted screenshots, configuration observations, log references, and a clear reproduction description. Credentials, tokens, personal records, and confidential business information should be minimised, encrypted, access-controlled, and destroyed according to the agreed retention schedule.

A finding generally contains:

1. a concise title;
2. affected asset and condition;
3. evidence and reproduction context;
4. security and business impact;
5. likelihood or exploitability assessment;
6. risk rating and rationale;
7. remediation recommendation;
8. references to relevant controls or techniques; and
9. limitations and retest requirements.

Risk ratings should not be copied uncritically from a scanner. Context, privileges, exposure, compensating controls, and business impact must be considered. Where CVSS is used, its published version and metrics should be identified; a CVSS score is a severity measure, not a complete business-risk decision.

6. Applied Scenario: Illustrative Online Retail Assessment

Background

The fictional Northbridge Retail Group operates an online store, customer portal, payment integration, and administrative API. Its security team wants to know whether a low-privilege customer account can reach another customer’s information or administrative functions. The public web application is hosted by a cloud provider, and the payment service is operated by a third party.

Problem

A previous vulnerability scan reported several medium-severity findings, but management could not determine whether the application’s authorisation model prevented meaningful data exposure. The organisation also wanted to improve detection of suspicious account activity.

Analysis and planning

The objective was defined as: assess horizontal and vertical authorisation controls in the customer portal and selected APIs, and evaluate whether relevant events are detected. The customer portal and organisation-owned API endpoints were in scope. The payment provider, denial-of-service activity, destructive actions, real customer records, and persistence were out of scope.

The plan used NIST SP 800-115 for engagement governance, OWASP WSTG for application test coverage, PTES for lifecycle organisation, and ATT&CK to describe the authorised account-abuse scenario. Two synthetic customer accounts and one test support account were created. Testing was restricted to a maintenance window, with request-rate limits and an emergency stop contact.

Approach

The team reviewed the application’s roles and data flows, tested authentication and session controls, compared access decisions between the two synthetic accounts, and checked whether support functions were separated from customer functions. The team recorded request identifiers and timestamps rather than copying customer data. The monitoring team was informed of the window but not given the exact test sequence, allowing detection processes to be evaluated without creating an uncontrolled exercise.

Outcome

The testers found that a customer could view a second synthetic customer’s order summary by changing an object reference in an API request. The response did not contain payment-card data, but it exposed name, delivery address, and order history. A separate administrative function correctly rejected the customer account. Monitoring recorded authentication anomalies but did not generate an alert for repeated cross-account access attempts.

The report classified the authorisation weakness as high priority because it affected personal data and required only a normal customer account. Recommendations included server-side object-level authorisation checks, negative and cross-tenant test cases in the development pipeline, improved alerting, and a retest using synthetic accounts. The payment provider was not reported as vulnerable because it was outside scope.

Learning points

The scenario demonstrates that scope determines the validity of conclusions, test accounts reduce privacy risk, and a technically successful test must be related to business impact. It also shows why prevention and detection should be assessed separately. A control may block an administrative action while failing to detect repeated unauthorised data requests.

7. Ethical, Legal, and Governance Considerations

Authorisation is the central ethical requirement. Testing without permission may constitute unauthorised access even if the tester intends to improve security. Written approval should identify the legal entity, assets, dates, permitted actions, and responsible contacts.

Privacy principles require data minimisation, purpose limitation, secure handling, restricted access, and appropriate deletion. Where personal data, health information, payment information, or employee records may be encountered, privacy and legal advisers should participate in planning.

Professional conduct also requires honesty about limitations. A test is a sample conducted under particular conditions; it cannot prove that no vulnerability exists. Reports should distinguish tested, not tested, blocked, inconclusive, and out-of-scope areas.

Supply-chain and cloud testing require special care. The customer may own a subscription but not the underlying infrastructure. Provider policies, contracts, and notification requirements must be checked before testing. Similarly, testing a shared IP address can affect unrelated tenants.

8. Challenges and Limitations

Penetration testing has important limitations:

• time limits prevent exhaustive coverage;
• production safety restrictions may prevent full validation;
• credentials and network position may not represent every user;
• cloud and third-party boundaries may restrict evidence;
• detection results depend on logging and monitoring configuration;
• testers can miss vulnerabilities or misinterpret business logic;
• a clean result may reflect ineffective test conditions; and
• remediation may change the environment before retesting.

Automation increases coverage but can create false positives, excessive traffic, or unsafe actions. Artificial intelligence may assist with asset classification, log analysis, test-case drafting, and report quality checks, but generated outputs require human validation. Sensitive client data should not be entered into an AI service unless contractual, privacy, security, and organisational requirements permit it. AI does not provide authorisation and cannot replace professional judgement.

9. Best-Practice Engagement Checklist

Before testing, confirm written authorisation, scope, exclusions, contacts, test accounts, provider permissions, data-handling rules, backup and recovery arrangements, monitoring expectations, and stop conditions.

During testing, maintain an activity log, use the least intrusive validation that answers the objective, avoid unnecessary sensitive data, monitor system stability, record deviations, and escalate unexpected events promptly.

After testing, validate findings, remove temporary access, secure and sanitise evidence, deliver a risk-prioritised report, conduct a stakeholder debrief, agree remediation owners and dates, and perform a controlled retest. Map findings to business assets and, where useful, to ATT&CK techniques or relevant application controls.

Chapter Summary

Penetration testing is an authorised and controlled assessment, not an unrestricted attack. Effective planning begins with clear objectives, scope, assumptions, constraints, success criteria, and rules of engagement. PTES provides a lifecycle model; NIST SP 800-115 supports formal technical testing and governance; OWASP WSTG structures web and API testing; OSSTMM broadens operational coverage; MITRE ATT&CK supports threat-informed scenarios and detection validation; and cyber kill-chain concepts help communicate attack progression.

Risk-based plans prioritise assets and test cases according to exposure, business impact, likely adversary behaviour, and organisational context. Evidence must be sufficient, reproducible, proportionate, and securely handled. Ethical and legal authorisation, privacy protection, cloud and third-party boundaries, safety controls, and honest reporting are essential. Finally, penetration testing provides evidence about defined conditions; it cannot guarantee the absence of vulnerabilities.

Key Terms

Methodology: A structured approach for planning, conducting, and reporting an assessment.

Penetration test: An authorised assessment that validates whether security weaknesses can produce defined impacts.

Scope: The assets, environments, identities, locations, and activities included in testing.

Rules of engagement: Approved operational instructions governing how testing is performed.

Objective: The security question an engagement is intended to answer.

Assumption: A condition accepted as true for planning and interpretation.

Stop condition: A situation requiring testing to pause or end.

PTES: A penetration-testing standard organised around seven engagement phases.

NIST SP 800-115: NIST guidance for technical information-security testing and assessment.

OWASP WSTG: A guide for testing web applications and web services.

OSSTMM: A methodology emphasising repeatable operational security testing across multiple channels.

MITRE ATT&CK: A knowledge base of adversary tactics, techniques, and procedures.

Cyber kill chain: A model describing stages commonly associated with cyber attacks.

Test case: A documented assessment activity with prerequisites, expected results, evidence, and safety controls.

Threat model: A structured representation of relevant adversaries, assets, attack paths, and impacts.

Evidence: Information that supports an assessment observation or finding.

Risk: The potential effect of uncertainty on objectives, commonly considered through likelihood and impact.

Retest: A follow-up assessment to determine whether remediation addressed a finding.

Review Questions

Short Answer Questions

1. Why is a penetration test different from a vulnerability scan?

1. Name the seven broad phases commonly associated with PTES.

1. What is the purpose of rules of engagement?

1. How can MITRE ATT&CK support penetration-test planning?

1. Why should test accounts and synthetic data be used where possible?

Long Answer Questions

1. Compare PTES and NIST SP 800-115 as engagement-planning references.

1. Explain how OWASP WSTG and OSSTMM address different testing needs.

1. Describe the essential contents of a professional scope statement.

1. Explain how evidence should be collected, protected, and reported during a penetration test.

1. Discuss the ethical, legal, and operational limitations of penetration testing.

Analytical / Application Questions

1. An organisation wants to test whether a normal employee account can reach a payment environment. Design the objective, scope, assumptions, test cases, safety controls, and success criteria.

1. A tester discovers access to real personal data during an authorised application assessment. Analyse the immediate actions, evidence-handling requirements, escalation path, and reporting implications.

1. A vulnerability scanner reports a high-severity issue on a cloud-hosted service owned by a third party. Develop a risk-based plan for validating the issue without violating provider or third-party boundaries.

Multiple Choice Questions with Answers

Question 1

Which framework is primarily designed to structure the overall phases of a penetration-testing engagement?

A. PTES

B. OWASP WSTG

C. MITRE ATT&CK

D. Cyber kill chain

Correct Answer: A. PTES

Question 2

Which reference is most directly focused on systematic web-application and web-service testing?

A. OSSTMM

B. OWASP WSTG

C. PTES

D. NIST CSF

Correct Answer: B. OWASP WSTG

Question 3

What is the main purpose of a rules-of-engagement document?

A. To guarantee that no vulnerability exists

B. To define approved operational boundaries and procedures

C. To replace written authorisation

D. To assign CVSS scores automatically

Correct Answer: B. To define approved operational boundaries and procedures

Question 4

Which statement best describes MITRE ATT&CK?

A. A database of adversary tactics and techniques

B. A legal contract for cloud testing

C. A vulnerability scanner

D. A backup and recovery standard

Correct Answer: A. A database of adversary tactics and techniques

Question 5

Why should a scope statement identify out-of-scope assets?

A. To increase the number of tested systems

B. To clarify boundaries and prevent unauthorised activity

C. To eliminate the need for evidence

D. To ensure every system is scanned

Correct Answer: B. To clarify boundaries and prevent unauthorised activity

Question 6

Which action is most appropriate when testing causes unexpected production instability?

A. Increase the test intensity

B. Ignore the issue until reporting

C. Follow the stop condition and notify the authorised contact

D. Delete all evidence

Correct Answer: C. Follow the stop condition and notify the authorised contact

Question 7

What is a major limitation of a numerical likelihood-times-impact risk score?

A. It cannot be used for planning at all

B. It may imply more precision than the underlying judgements support

C. It measures only network bandwidth

D. It automatically proves exploitability

Correct Answer: B. It may imply more precision than the underlying judgements support

Question 8

Which practice best protects privacy during an application penetration test?

A. Copying all accessible records for completeness

B. Using synthetic accounts and minimising collected data

C. Publishing raw screenshots in the final report

D. Sharing credentials through ordinary email

Correct Answer: B. Using synthetic accounts and minimising collected data

Question 9

What is the primary value of a test case?

A. It provides a repeatable, bounded assessment activity

B. It removes the need for client approval

C. It guarantees a successful exploit

D. It replaces the final report

Correct Answer: A. It provides a repeatable, bounded assessment activity

Question 10

Why can a clean penetration-test result not prove that an organisation has no vulnerabilities?

A. Testing is conducted under defined conditions and limited coverage

B. Penetration tests never examine evidence

C. Methodologies prohibit reporting negative results

D. All vulnerabilities are necessarily theoretical

Correct Answer: A. Testing is conducted under defined conditions and limited coverage