Penetration-Testing Methodologies and Engagement Planning

Introduction

A penetration test is an authorised, controlled security assessment in which skilled testers examine systems, applications, networks, people, or processes using techniques that resemble those of real attackers. Its purpose is not simply to find vulnerabilities. A professional penetration test determines whether weaknesses can be exploited, what an attacker could achieve, how likely the outcome is, and what controls should be improved.

Effective testing begins before any tool is opened. Poorly defined scope, unclear authority, inadequate communication, or unsafe testing can cause service disruption, privacy violations, legal exposure, and unreliable results. Engagement planning therefore connects technical testing with governance, risk management, business objectives, and evidence-based reporting.

This chapter explains major penetration-testing methodologies and shows how to convert them into a practical engagement plan. It focuses on the Penetration Testing Execution Standard (PTES), NIST guidance, OSSTMM, OWASP approaches, MITRE ATT&CK, and the Cyber Kill Chain. These models are complementary rather than interchangeable: some describe phases, some emphasise testing discipline, and others provide threat or attack perspectives.

Learning Objectives

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

1. Explain the purpose and limitations of major penetration-testing methodologies.
2. Select suitable frameworks for a given engagement.
3. Define objectives, scope, assumptions, exclusions, rules of engagement, and acceptance criteria.
4. Prepare a defensible schedule, resource plan, communication plan, and risk-control plan.
5. Map testing activities to attack stages and adversary behaviours.
6. Distinguish vulnerability discovery from validated exploitation and business-impact analysis.
7. Apply professional, ethical, legal, and safety requirements to an engagement.
8. Produce a concise engagement plan suitable for client approval.

1. The Nature and Purpose of a Penetration Test

A penetration test is an authorised attempt to evaluate security by simulating relevant attack actions. It normally includes reconnaissance, identification of attack paths, controlled exploitation, post-exploitation validation, evidence collection, and reporting. The test is successful when it produces useful and trustworthy information—not when it causes maximum damage.

Penetration testing differs from several related activities:

A vulnerability scanner may report an outdated service, while a penetration tester determines whether it can be exploited in the target environment and whether exploitation permits unauthorised access or data exposure. Neither activity proves that no vulnerabilities exist. Results are limited by time, access, tester knowledge, environmental change, and the selected scope.

A useful engagement begins with a business question, such as:

• Can an external attacker reach sensitive customer data?
• Can a low-privileged employee obtain administrative privileges?
• Can a public web application enforce authorisation correctly?
• Can the organisation detect and respond to a defined attack path?

The question determines the methodology, evidence requirements, depth of testing, and acceptance criteria.

2. Major Methodologies and Frameworks

2.1 PTES

The Penetration Testing Execution Standard provides a practical lifecycle with seven broad phases:

1. Pre-engagement interactions
2. Intelligence gathering
3. Threat modelling
4. Vulnerability analysis
5. Exploitation
6. Post-exploitation
7. Reporting

PTES is particularly useful for organising a complete engagement. Its pre-engagement emphasis supports scope and rules of engagement, while its reporting phase encourages a narrative that explains attack paths and business consequences. PTES is not a checklist that guarantees complete coverage; testers must adapt activities to the technology, threat model, and contract.

2.2 NIST guidance

NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, describes planning, execution, and post-execution activities. It distinguishes techniques such as review, target identification and analysis, vulnerability validation, and penetration testing. NIST is valuable where an organisation needs a formal, risk-managed, auditable process.

NIST guidance commonly encourages:

• defining rules and responsibilities before testing;
• identifying systems, threats, and objectives;
• selecting appropriate assessment techniques;
• controlling risk during execution;
• documenting evidence and limitations; and
• communicating remediation and retesting requirements.

NIST is guidance rather than a rigid sequence. A professional may combine it with PTES or organisational risk-management processes.

2.3 OSSTMM

The Open Source Security Testing Methodology Manual (OSSTMM) promotes systematic testing of operational security. It considers channels such as human, physical, wireless, telecommunications, and data networks. OSSTMM places emphasis on test design, operational metrics, verification, and the distinction between what is known, tested, and assumed.

Its broad perspective is useful when a client wants more than a conventional external network test. For example, a security assessment may need to consider physical access, social engineering, wireless exposure, and technical controls together. The tester must still ensure that every channel is explicitly authorised; the breadth of OSSTMM does not create permission to test unrelated systems.

2.4 OWASP approaches

OWASP materials are central to web application and API testing. The OWASP Web Security Testing Guide provides structured coverage for information gathering, configuration, identity, authentication, authorisation, session management, input validation, error handling, weak cryptography, business logic, client-side testing, and API-related risks.

The OWASP Top 10 is an awareness document describing common categories of web application risk. It is not, by itself, a complete test methodology. A tester should use detailed test cases and application-specific requirements rather than treating the Top 10 as a finite list of all possible defects.

For an application engagement, scope should identify URLs, APIs, mobile clients, test accounts, roles, data classes, third-party integrations, and permitted test hours. Authorisation testing should use accounts with different roles and should avoid modifying real customer data.

2.5 MITRE ATT&CK

MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on observed behaviour. Tactics describe 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 how those goals may be pursued.

ATT&CK is not a contractual scope document and does not prescribe a complete penetration-testing sequence. It is valuable for threat-informed planning, coverage analysis, purple-team work, and detection validation. For example, an engagement may define a controlled objective to test whether endpoint monitoring detects credential-access behaviour, without permitting destructive actions or actual data theft.

2.6 Cyber Kill Chain

The Lockheed Martin Cyber Kill Chain presents an attack as seven stages: reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. It is useful for explaining how an attack progresses and where preventive or detective controls may interrupt it.

The model has limitations. Modern attacks may omit stages, repeat stages, begin with valid credentials, or move directly through cloud services and identity providers. ATT&CK generally provides more detailed behavioural coverage. The Cyber Kill Chain remains useful as a high-level communication model, especially for identifying control points.

2.7 Combining models

The frameworks answer different questions:

A practical engagement may use PTES for lifecycle management, NIST for governance, OWASP for application test cases, ATT&CK for threat-informed coverage, and the Cyber Kill Chain for executive communication.

3. Engagement Planning

3.1 Objectives and success criteria

Objectives must be specific enough to guide decisions. “Test our security” is inadequate. Better objectives include:

• assess whether Internet-facing services permit unauthorised access;
• determine whether a normal employee account can reach restricted records;
• evaluate API authorisation across defined user roles;
• validate monitoring for selected ATT&CK techniques; or
• determine whether a segmented network prevents movement from a user VLAN to a server VLAN.

Acceptance criteria define what the client will regard as a completed engagement. They may include:

• all in-scope assets tested during the agreed window;
• each stated application role assessed;
• evidence captured for confirmed findings;
• no unauthorised production data altered or retained;
• urgent findings communicated within an agreed period; and
• a final report delivered with reproduction guidance and remediation priorities.

Acceptance criteria must not promise that the environment is secure. They define completion and quality, not absolute security.

3.2 Scope

Scope identifies what may be tested. It should be precise and version-controlled. It may include:

• IP addresses, domains, cloud accounts, applications, APIs, repositories, or devices;
• environments such as development, staging, or production;
• identities and roles supplied to the testers;
• physical locations or wireless networks;
• permitted testing techniques;
• test windows and source addresses; and
• data-handling requirements.

A scope register is useful:

Scope should state whether subdomains, cloud resources, third-party services, employee devices, source code, and social engineering are included. Ownership must be verified, especially where hosted services or shared infrastructure are involved.

3.3 Exclusions and assumptions

Exclusions are explicit boundaries. Examples include denial-of-service testing, destructive payloads, persistence, malware deployment, physical entry, phishing, cloud-provider infrastructure, safety-critical systems, and real-data exfiltration. An exclusion is not a weakness in the test; it is a controlled limitation that must be reported.

Assumptions describe conditions believed to be true, such as:

• the client owns or has permission to test the listed assets;
• supplied accounts are valid and appropriately privileged;
• a named emergency contact will be available;
• backups and recovery procedures exist; and
• third-party providers have approved the activity where required.

Unverified assumptions create risk. The plan should assign an owner and a confirmation date to important assumptions.

3.4 Rules of engagement

Rules of engagement (RoE) translate authorisation into operational instructions. They should address:

• authorised source addresses and tester identities;
• start and stop dates and permitted hours;
• allowed and prohibited techniques;
• rate limits and concurrency limits;
• treatment of credentials, tokens, personal data, and secrets;
• evidence storage, encryption, retention, and deletion;
• escalation procedures for critical findings or instability;
• communication channels and reporting frequency; and
• conditions for pausing or terminating testing.

Written authorisation should identify the legal entity, assets, testing team, dates, and approving authority. Verbal permission is not a sufficient substitute for a documented agreement.

3.5 Resources and roles

A small engagement may require a lead tester, specialist tester, client coordinator, system owners, and an incident or operations contact. Larger work may add an application specialist, cloud specialist, social-engineering specialist, report reviewer, and legal or privacy adviser.

A responsibility matrix clarifies accountability:

Testers must have suitable technical competence, secure equipment, approved tools, and a clear method for recording evidence. Tools do not replace judgement: automated results require validation and contextual interpretation.

3.6 Timeline and communications

A schedule should include preparation, access validation, reconnaissance, testing, validation, analysis, reporting, client review, and retesting if contracted. Contingency time is important because access failures, change freezes, or unexpected operational risks can delay work.

Communication should be proportional to risk. A typical plan includes:

• kickoff meeting before testing;
• daily or periodic status updates;
• immediate notification of critical exposure or service instability;
• an agreed emergency telephone channel;
• a preliminary findings discussion; and
• a final report and close-out meeting.

Communication must avoid unnecessarily distributing sensitive evidence. Findings should be sent only to authorised recipients using approved channels.

4. Risk Controls During Testing

Testing can itself create operational and legal risk. Controls should be selected before execution. Examples include rate limiting, non-destructive payloads, synthetic accounts, snapshots, maintenance windows, source-IP allowlisting, test-data tagging, and immediate rollback procedures.

A simple risk assessment can consider likelihood and impact qualitatively. If an organisation uses numerical scoring, it must define its scale consistently. For example, a 1–5 likelihood score multiplied by a 1–5 impact score produces a prioritisation value, but the result is not a probability and should not be presented as one. The scale, definitions, and treatment thresholds must be documented.

Important controls include:

• Safety boundaries: no denial-of-service, destructive commands, uncontrolled malware, or unauthorised persistence unless separately approved.
• Data minimisation: collect the smallest amount of sensitive data necessary to prove a finding.
• Credential protection: store credentials in an approved secret-management system and never place them in ordinary notes.
• Evidence integrity: record timestamps, target identifiers, commands or requests, responses, screenshots where necessary, and tester identity.
• Stop conditions: pause testing if a service becomes unstable, unexpected sensitive data is exposed, a third party is affected, or the activity exceeds scope.
• Change awareness: confirm whether systems changed during the test and record those changes as limitations.

A critical finding should normally be communicated before the final report. The tester should state what was observed, what is confirmed, what remains uncertain, and what immediate containment action is recommended.

5. Executing and Documenting the Test

The execution plan should follow the approved methodology while allowing controlled adaptation. Reconnaissance identifies assets and relationships. Threat modelling connects assets to realistic adversaries and objectives. Vulnerability analysis identifies possible weaknesses. Exploitation validates only what is necessary to answer the engagement question.

Post-exploitation should be tightly bounded. The tester may demonstrate privilege escalation, access a designated proof file, or establish that lateral movement is possible, but should not browse unrelated personal records or remove evidence. A proof of impact should be minimal, reproducible, and safe.

Every finding should contain:

1. A concise title.
2. Affected asset and location.
3. Technical description.
4. Preconditions and attack path.
5. Evidence and reproduction steps.
6. Business or operational impact.
7. Likelihood and severity rationale.
8. Recommended remediation.
9. Residual limitations and retest requirements.

Severity should reflect context. A public remote-code-execution flaw in an Internet-facing system may be urgent, whereas the same technical weakness in an isolated test system may have lower practical impact. CVSS can support severity discussion, but it does not replace environmental analysis or business judgement.

6. Detailed Applied Case: Illustrative Retail Portal Assessment

Background

This fictional case concerns Northbridge Retail, which operates a public online portal and an internal order-management API. The organisation wants to know whether a customer account can access another customer’s order information and whether compromise of the portal could lead to internal administrative access.

Problem and objectives

The client defines two objectives:

1. Test horizontal and vertical authorisation in the portal and API.
2. Determine whether a controlled compromise of the portal provides a route to the internal API.

The test excludes denial-of-service, phishing, physical security, destructive actions, and access to real payment-card data. Synthetic orders are created for testing.

Analysis and plan

PTES is used to structure the lifecycle. OWASP guidance supplies application test areas, especially authentication, session management, access control, input validation, and business logic. ATT&CK is used to describe relevant behaviours such as valid-account use, discovery, credential access, and lateral movement. NIST-style planning supports written authorisation, evidence handling, and risk controls.

The RoE permits testing from two named source addresses between 20:00 and 02:00 on weekdays. API requests are limited to an agreed rate. The client provides customer, support, and administrator test accounts. The test lead may access only synthetic records and must stop if production payment data appears.

Approach and findings

The testers first map portal functions and API endpoints, then compare responses made by the supplied roles. A customer account is able to alter an order identifier and retrieve another synthetic customer’s order. This confirms a broken object-level authorisation issue. No real customer record is accessed.

A separate test shows that the support role can invoke an administrative endpoint because the API checks authentication but does not correctly enforce role authorisation. The testers document the request, response, affected roles, and business consequence without changing account privileges.

Network validation shows that the portal’s hosting segment cannot directly reach the internal order-management API, but a management service exposes an unnecessarily broad trust relationship. The testers do not attempt persistence or data extraction. They provide a controlled evidence chain demonstrating that the segmentation assumption requires review.

Outcome

The client receives immediate notification of the authorisation findings. Remediation includes server-side object-level access checks, centralised role enforcement, negative authorisation tests in the development pipeline, network rule reduction, and monitoring for abnormal object enumeration. A retest confirms that customer identifiers are no longer sufficient to retrieve another customer’s data and that the support role is denied administrative functions.

Learning points

The case demonstrates that a methodology is most useful when translated into decisions. Scope and synthetic data protected customers; OWASP supplied relevant application coverage; ATT&CK helped describe adversary behaviour; PTES organised the work; and acceptance criteria made retesting objective. It also shows why a scanner alone would not establish the business impact of authorisation failures.

7. Ethical, Legal, and Governance Considerations

Penetration testing requires informed authorisation and respect for law, privacy, confidentiality, and professional boundaries. Testing a system merely because it is reachable is not ethical or lawful. Contracts should address ownership, third-party approval, data protection, confidentiality, intellectual property, subcontractors, and incident handling.

Privacy principles require purpose limitation, data minimisation, access control, secure storage, retention limits, and secure deletion. Testers may encounter personal data unintentionally; they should stop unnecessary collection, record only what is needed, and report exposure through the agreed channel.

Cloud environments introduce shared-responsibility issues. A customer may authorise testing of its tenant but not the provider’s underlying infrastructure or other tenants. Provider policies and approval processes must be checked before testing.

AI-assisted security tools can help summarise logs, generate test cases, identify patterns, or draft reports. They also create risks: confidential evidence may be disclosed to an external service, generated commands may be unsafe, and plausible text may contain errors. AI outputs must be reviewed by a qualified tester, and sensitive evidence should not be submitted to unapproved systems.

8. Limitations, Quality Assurance, and Contemporary Practice

No methodology provides complete assurance. Common limitations include incomplete asset inventories, short test windows, unavailable accounts, rate limits, encrypted traffic, third-party dependencies, changing cloud resources, and defensive controls that block particular techniques. Reports should state these limitations clearly.

Quality assurance includes peer review of findings, confirmation that evidence supports each conclusion, duplicate removal, scope verification, severity consistency, and a check that recommendations are practical. A report should distinguish confirmed facts, reasonable inferences, and untested assumptions.

Contemporary engagements increasingly include cloud identity, software supply chains, APIs, containers, infrastructure as code, mobile applications, and continuous delivery pipelines. Traditional network boundaries are less informative when identity providers, SaaS platforms, and application programming interfaces form the principal attack surface. Methodologies remain useful, but the asset model and threat assumptions must evolve.

Best practice is therefore to use a risk-based combination of models, document decisions, test safely, communicate promptly, and treat the final report as an instrument for reducing risk rather than as a catalogue of tools or vulnerabilities.

Chapter Summary

Professional penetration testing is an authorised, evidence-based assessment designed to answer defined security and business questions. PTES provides a practical testing lifecycle; NIST supports formal planning and governance; OSSTMM encourages systematic coverage across operational channels; OWASP guides web and API testing; MITRE ATT&CK describes adversary behaviours; and the Cyber Kill Chain offers a high-level attack progression model.

A sound engagement plan defines objectives, assets, environments, assumptions, exclusions, rules of engagement, resources, schedule, communication routes, risk controls, evidence requirements, and acceptance criteria. Testing must be proportionate, non-destructive, legally authorised, privacy-conscious, and adaptable to limitations. Findings should validate practical impact without unnecessary access to sensitive data. The quality of an engagement depends as much on preparation, judgement, documentation, and communication as on technical skill.

Key Terms

PTES: Penetration Testing Execution Standard, a lifecycle model for organising penetration tests.

NIST SP 800-115: Guidance for planning and conducting technical information-security testing.

OSSTMM: Open Source Security Testing Methodology Manual, a systematic approach to testing operational security.

OWASP: Open Worldwide Application Security Project, a source of application-security guidance and testing methods.

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

Cyber Kill Chain: A model describing stages in a cyber attack.

Scope: The systems, identities, locations, techniques, and time periods authorised for testing.

Exclusion: An explicitly prohibited asset, activity, or technique.

Assumption: A condition accepted as true for planning but requiring appropriate confirmation.

Rules of engagement: Operational instructions governing how testing will be performed.

Acceptance criteria: Conditions used to determine whether agreed engagement work is complete.

Threat modelling: Analysis of relevant adversaries, assets, attack paths, and impacts.

Exploitability: The practical ability to use a weakness to produce an unauthorised outcome.

Post-exploitation: Controlled validation of what access could enable after initial compromise.

Evidence: Recorded information supporting a testing observation or finding.

Lateral movement: Movement from one compromised system or account to another.

Retest: A later assessment to determine whether reported weaknesses were remediated.

Stop condition: A predefined event requiring testing to pause or terminate.

Review Questions

Short Answer Questions

1. What is the main difference between a vulnerability assessment and a penetration test?
2. List the seven broad phases commonly associated with PTES.
3. Why should exclusions be recorded in an engagement plan?
4. What is the purpose of acceptance criteria?
5. State two controls that reduce operational risk during testing.

Long Answer Questions

1. Compare PTES, NIST, OSSTMM, OWASP, MITRE ATT&CK, and the Cyber Kill Chain, explaining how they can be combined in one engagement.
2. Explain the information that should be included in rules of engagement and discuss why written authorisation is essential.
3. Describe how scope, assumptions, exclusions, resources, and communication arrangements influence test quality.
4. Explain how a tester can validate impact while minimising exposure of personal or confidential data.
5. Discuss the limitations of penetration testing and how a professional report should communicate those limitations.

Analytical / Application Questions

1. An organisation wants to test an Internet-facing API, a cloud identity tenant, and employee phishing resistance. Design a high-level methodology combination and identify three exclusions that should be clarified before approval.
2. During testing, a request intended for a synthetic account returns a real customer record. Analyse the immediate actions, communication requirements, evidence-handling obligations, and possible stop conditions.
3. A client claims that passing a vulnerability scan proves that its portal is secure. Use the concepts in this chapter to explain why that conclusion is unsound and propose suitable acceptance criteria for a penetration test.

Multiple Choice Questions with Answers

Question 1

Which framework primarily provides a lifecycle for organising a penetration test?

A. PTES

B. OWASP Top 10

C. Cyber Kill Chain

D. MITRE ATT&CK

Correct Answer: A. PTES

Question 2

What is the main purpose of rules of engagement?

A. To replace written authorisation

B. To define operational boundaries and procedures for testing

C. To guarantee that no vulnerabilities exist

D. To rank all vulnerabilities by CVSS

Correct Answer: B. To define operational boundaries and procedures for testing

Question 3

Which model is especially useful for detailed web application and API test coverage?

A. OSSTMM

B. OWASP Web Security Testing Guide

C. Cyber Kill Chain

D. NIST asset inventory

Correct Answer: B. OWASP Web Security Testing Guide

Question 4

What does MITRE ATT&CK primarily describe?

A. Adversary tactics and techniques

B. Contract pricing models

C. Hardware replacement schedules

D. A legal authorisation form

Correct Answer: A. Adversary tactics and techniques

Question 5

Which activity is normally an exclusion unless separately authorised?

A. Evidence documentation

B. A kickoff meeting

C. Denial-of-service testing

D. Scope verification

Correct Answer: C. Denial-of-service testing

Question 6

Why are acceptance criteria used in an engagement?

A. To prove the organisation is completely secure

B. To define when agreed work is complete

C. To eliminate the need for reporting

D. To permit testing of third-party systems

Correct Answer: B. To define when agreed work is complete

Question 7

A tester finds a critical exposure during an authorised test. What is generally the most appropriate action?

A. Publish it immediately online

B. Continue silently until the final report

C. Notify the agreed client contact promptly and safely

D. Delete all evidence

Correct Answer: C. Notify the agreed client contact promptly and safely

Question 8

Which practice best supports data minimisation?

A. Copying all accessible records for analysis

B. Using synthetic data and collecting only evidence needed to prove impact

C. Keeping credentials in ordinary text files

D. Sending screenshots to unrestricted mailing lists

Correct Answer: B. Using synthetic data and collecting only evidence needed to prove impact

Question 9

What is a key limitation of the Cyber Kill Chain?

A. It cannot describe any attack activity

B. Modern attacks may omit, repeat, or reorder its stages

C. It is exclusively a web application checklist

D. It defines contractual scope automatically

Correct Answer: B. Modern attacks may omit, repeat, or reorder its stages

Question 10

Which statement best describes a penetration-test report?

A. It should distinguish confirmed evidence from assumptions and limitations

B. It should list tools without explaining impact

C. It should omit exclusions to avoid concern

D. It should claim that no undiscovered vulnerabilities exist

Correct Answer: A. It should distinguish confirmed evidence from assumptions and limitations