Skip to content

CH2: Pre-Engagement, Scoping, Agreements, and Communication

Introduction

Before you scan a single port, exploit a single vulnerability, or send a single packet toward a target, you must negotiate and document an agreement that defines precisely what you are authorized to do. This chapter covers pre-engagement in depth: how to define scope, manage client expectations, establish legal protection, and set up communication channels that keep both you and the client safe.

This is not bureaucratic overhead. Scope creep, ambiguous rules, and missing sign-off are the primary causes of failed engagements and legal disputes in the consulting world. A penetration test that starts without a clear scope is a risk to you, the client, and the organization's security posture. This chapter teaches you to build that foundation with precision.

You will learn how to define scope at technical and legal levels, understand the regulations and frameworks that constrain what you can test, establish rules of engagement that protect both parties, and communicate findings in ways that drive decisions. By the end, you will be able to scope a real engagement and structure a conversation with a prospective client that identifies risks before they become crises.

Learning Objectives

After completing this chapter, you will be able to:

  1. Define penetration test scope using CIDR notation, IP addresses, URLs, domains, and assessment types; identify scope inclusions and exclusions.
  2. Analyze how compliance frameworks, regulations, and shared responsibility models constrain or shape testing scope.
  3. Craft rules of engagement that define test windows, escalation procedures, testing methods, and acceptable risk.
  4. Distinguish between NDA, MSA, SoW, and ToS documents and identify which are required for a legal engagement.
  5. Evaluate communication strategies, risk articulation, and reporting mechanisms that align technical findings with business decision-making.

2.1 Scope Definition: What You Can Touch and When

Scope is the contract's technical nucleus. It specifies exactly which systems, networks, applications, and services you are authorized to test. Without a clear scope, you have no legal protection, and the client has no way to know what you will do.

Scope Components

A complete scope document includes:

Target Systems

Express targets in concrete technical terms:

  • IP address ranges (CIDR notation): 192.168.1.0/24 means you can test the 256 addresses from 192.168.1.0 to 192.168.1.255. This is precise and unambiguous. Avoid phrases like "all servers in the east building", specify the CIDR blocks or explicit IP addresses.
  • Fully qualified domain names (FQDNs): api.company.com, staging.app.company.com. Use explicit domain names, not wildcards unless you explicitly intend to include all subdomains.
  • URLs and paths: https://webapp.company.com/dashboard, /admin, /api/v2/*. Be specific about which paths and endpoints are in scope.
  • Hostnames: web-server-01.internal.company.com. If you receive credentials, ensure they map to systems in scope.
  • Cloud resources: AWS ARN (Amazon Resource Name) like arn:aws:s3:::company-prod-bucket/* or Azure resource IDs.

Analyst Perspective

In practice, clients often provide loose descriptions: "test our web app" or "scan our network." Your job in pre-engagement is to translate this into technical precision. If they say "web app," ask: What is the domain? Are subdomains in scope? Are staging and production both included? What about APIs the app calls? Get specific. Write it down. Have them confirm.

Assessment Types

Specify which types of testing are permitted:

  • Network infrastructure testing (scanning, enumeration, exploitation).
  • Web application testing (input validation, authentication, authorization).
  • Wireless assessment (WiFi security, Bluetooth enumeration).
  • Cloud infrastructure testing (IAM, storage, compute).
  • Mobile application testing (dynamic analysis, static analysis).
  • Social engineering or phishing (requires explicit written consent; often excluded).
  • Physical penetration (building access, badge cloning; usually excluded for liability).

A statement like "network and web application testing only" is clear. A statement like "general security testing" is dangerously vague.

Exclusions

State what is explicitly off-limits:

  • "Production database servers are excluded" (you can test web servers but not the core database).
  • "Payment processing systems are excluded" (PCI compliance constraints may apply).
  • "Customer data backups are excluded" (no accessing archives).
  • "VoIP infrastructure is excluded" (different skillset, different liability).
  • "Physical access to data center is excluded" (testing happens remotely).

Exclusions are as important as inclusions. They protect the client's critical systems and your legal standing.

Test Windows

Define when testing can occur:

  • "Monday–Friday, 9 AM–5 PM Eastern time only."
  • "Weekends and off-hours only (avoid customer-facing peak times)."
  • "November 2026, 2-week engagement."

This prevents you from accidentally testing during a production outage, a major customer event, or a time-sensitive migration. It also sets client expectations about when they will see test traffic in their logs.

Constraint Matrix

For complex engagements, a matrix clarifies what is tested where and when:

System Scanning Enumeration Exploitation Post-Exploitation Notes
Web App (prod) Yes Yes Limited (no data exfil) No Staging instead if possible
API (prod) Yes Yes Yes Yes Auth testing focused
Internal Network Yes Yes Yes Yes But not the finance subnet
Database Servers No No No No Excluded entirely
WiFi Yes Yes Limited No WPA2 crack only; no client devices

This clarity prevents the awkward moment halfway through testing when you find a critical vulnerability on the finance database and realize it was excluded from scope.

2.2 Compliance, Regulations, and Shared Responsibility

Penetration testing does not occur in a vacuum. Regulations, compliance frameworks, and vendor agreements may constrain what you can test and how you can test it.

Regulatory Constraints

PCI DSS (Payment Card Industry Data Security Standard)

If the target organization handles credit card data, PCI DSS applies. It mandates penetration testing at least annually. However, it also restricts certain testing activities:

  • Testing on payment processing systems is heavily restricted. You cannot execute exploits that could disrupt card transactions.
  • Authorized testing must be documented in writing.
  • Third-party testers must be PCI-certified vendors or approved assessors.

Implication for scope: A PCI-regulated organization will typically exclude payment processing systems from your scope and specify "scanning only" for systems that directly touch card data.

HIPAA (Health Insurance Portability and Accountability Act)

Healthcare organizations fall under HIPAA, which requires security testing but tightly controls access to protected health information (PHI):

  • You cannot access, copy, or exfiltrate patient data during testing.
  • Testing windows may be constrained to avoid interference with patient care.
  • Specific testing methods (like denial-of-service) may be prohibited.

Implication for scope: Scope typically excludes clinical systems and production databases containing PHI. Testing focuses on infrastructure and application layers.

FERPA (Family Educational Rights and Privacy Act)

Education institutions must protect student records. Similar constraints apply:

  • Do not access student data.
  • Testing of student-facing systems is restricted.
  • Timing matters (avoid testing during add/drop periods or grade submission).

Implication for scope: Like HIPAA, scope excludes data and focuses on infrastructure and controls.

GDPR (General Data Protection Regulation) and Privacy Laws

If the target organization processes data from European residents (or any jurisdiction with privacy regulations), you must be careful not to exfiltrate, copy, or retain personal data discovered during testing.

Implication for scope: Scope should explicitly state "no data exfiltration" or "no personal data copying." If you find data, document it but do not store it locally.

Shared Responsibility Model

In cloud environments (AWS, Azure, GCP), the cloud provider is responsible for infrastructure security, and the customer is responsible for configuration, access control, and application security. This shapes what you can test.

Example (AWS):

  • You ARE responsible for testing: EC2 instance configuration, S3 bucket permissions, IAM policies, security groups, application code, credentials stored in systems.
  • AWS IS responsible for: hypervisor security, physical data center access, network infrastructure.
  • You CANNOT test: The underlying AWS infrastructure, AWS APIs themselves, or anything outside of your customer account.

Critical Constraint

Shared responsibility model means you cannot test infrastructure you do not own or control. If your scope includes "test our cloud infrastructure," clarify whether this means customer account configuration or includes testing the provider's actual infrastructure (which you cannot do without permission from the provider).

Implication for scope: Cloud penetration testing scope should specify "customer-owned resources in AWS account ABC-123" rather than "test our AWS infrastructure."

AWS Customer Service Policy for Penetration Testing

AWS permits customers to perform security assessments of their own AWS resources without prior approval when the testing follows the AWS Customer Service Policy for Penetration Testing. The policy identifies permitted services, which include common customer-controlled targets such as Amazon EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. Always check the current policy because the permitted-service list and requirements may change.

Permitted when authorized and in scope:

  • Test the customer's applications, instances, APIs, and configurations running on permitted AWS services.
  • Conduct testing only against resources owned or controlled by the customer, using identified accounts, regions, IP addresses, domains, and test identities.
  • Obtain AWS approval when the service or activity is not covered by the policy's permitted list.

Prohibited or restricted activities:

  • Do not test AWS-owned infrastructure, the underlying hypervisor, other customers' resources, or AWS services themselves.
  • Do not perform denial-of-service (DoS/DDoS) testing, simulated DDoS, port or protocol flooding, request flooding, or login-request flooding.
  • Do not conduct testing that could degrade AWS availability or affect other customers; coordinate any potentially disruptive activity with the client and follow the policy's restrictions.

The AWS policy does not replace the client's authorization or the rules of engagement. Record the AWS account and resource ownership, testing window, source addresses, approved techniques, escalation contacts, and stop conditions before beginning.

Third-Party Vendor Agreements

If the target organization uses third-party services (SaaS, PaaS, managed databases), those vendors' terms of service may prohibit or constrain penetration testing.

  • SalesForce's ToS prohibits penetration testing of their infrastructure (but you can test your customer instance configuration).
  • AWS requires explicit approval for certain vulnerability scanning activities.
  • Some vendors prohibit exploitation outright; scanning only is allowed.

Implication for scope: Before testing any third-party service, check their terms. Ask the client if they have authorization from the vendor. Build vendor approval into your timeline and budget.

2.3 Rules of Engagement: Boundaries and Escalation

Scope defines what you can test. Rules of engagement define how you test it and what you do when you find something serious.

Testing Methods

Specify which techniques are permitted:

Permitted methods: - Network scanning with Nmap, Nessus, Qualys. - Vulnerability scanning. - Manual exploitation of identified vulnerabilities. - SQL injection, XSS, CSRF testing. - Credential testing (with provided credentials). - Lateral movement testing.

Prohibited methods: - Denial-of-service attacks (DoS, DDoS). These disrupt service and are often illegal even in authorized testing. - Phishing or social engineering (unless explicitly authorized; requires separate legal language). - Physical access (badge cloning, break-ins; unless explicitly authorized). - Data exfiltration beyond what is necessary to document the vulnerability. - Testing on systems outside of scope (even adjacent systems).

Escalation Procedures

Define what you do when you discover something serious that falls outside normal reporting:

Active compromise: "If the tester discovers evidence of active malware infection, unauthorized access, or ongoing attack, the tester will immediately notify [Client Contact Name] at [phone] or [email] and [Incident Response Manager] at [phone] or [email]. Testing will pause pending incident response assessment."

Unintended damage: "If the tester causes unintended system outage, data loss, or degradation beyond scope, the tester will immediately notify [Client Contact Name] and provide technical details to support remediation."

Out-of-scope discovery: "If the tester discovers critical vulnerability in an excluded system (e.g., production database), the tester will document the finding and notify the client but will not attempt exploitation."

Child exploitation material or illegal content: "If the tester discovers evidence of child exploitation or other illegal content, the tester will immediately contact law enforcement and the client's legal counsel as required by law."

Analyst Perspective

Escalation procedures are most important when something goes wrong. A client who has thought through escalation ahead of time is a client who will not panic or blame you when you call to say "we found active malware." A client without escalation procedures will be unprepared, reactive, and potentially litigious. Escalation planning is a sign of a well-run organization.

Testing Windows and Maintenance Windows

"Testing will occur Monday–Friday, 9 AM–5 PM EST, November 13–24, 2026, with a planned 2-hour break each day for client maintenance and testing suspension during all scheduled system maintenance windows."

This allows the client to brief their team, monitor for test traffic, and halt testing if an unplanned outage occurs.

Risk Tolerance

Some clients are risk-averse and prefer minimal disruption. Others want thorough testing even if it means some temporary impact.

  • Conservative: "Scanning only; no exploitation. Avoid any activity that could disrupt service."
  • Moderate: "Exploitation permitted for identified vulnerabilities; avoid sustained load testing."
  • Aggressive: "Full exploitation including post-exploitation and lateral movement; brief service disruptions acceptable."

This shapes the depth of testing you perform and the timeline you estimate.

Restrictions on Data Handling

"The tester will not copy, download, or retain customer data, personally identifiable information (PII), or trade secrets discovered during testing. Findings will be documented by reference ('SQL injection discovered in /admin/users; able to retrieve row count from users table') without retaining the actual data. Exceptions: Tester may capture screenshots of sensitive data if necessary to document the vulnerability, provided screenshots are securely deleted after report completion."

This protects both parties from data exfiltration liability.

You need documentation. The question is what documentation and in what sequence.

Non-Disclosure Agreement (NDA)

An NDA (also called a Confidentiality Agreement or CDA) binds both parties to keep information confidential. It typically covers:

  • Findings will not be shared with competitors or the media.
  • Vulnerabilities will not be disclosed publicly without client consent.
  • Client's internal business information (user counts, infrastructure details, vendor choices) will not be disclosed.

Who needs it: Both parties. The client wants assurance you will not leak their vulnerabilities. You want assurance the client will not publicly claim you performed testing you did not, or blame you for vulnerabilities you did not cause.

Timing: Usually signed first or simultaneously with other agreements.

Master Service Agreement (MSA)

An MSA is a high-level contract covering general terms: payment terms, liability limits, insurance, IP ownership, dispute resolution. It often covers multiple engagements.

Who needs it: You if you are a consultant or vendor. Larger organizations may require this before engaging any external provider.

Timing: May be negotiated once; referenced in subsequent projects.

Key sections for penetration testing:

  • Liability cap: Except for agreed exceptions such as intentional misconduct, gross negligence, confidentiality violations, or unpaid fees, each party's total financial liability arising from the engagement will not exceed the fees paid for that engagement (limits exposure). For example, if the engagement costs $10,000, a covered claim would generally be limited to $10,000.
  • Errors and omissions (E&O) insurance: The consultant must maintain professional-liability insurance of at least $500,000 per claim and $1,000,000 in aggregate, covering claims arising from negligent acts, errors, or omissions in performing the penetration test. The consultant must provide a certificate of insurance upon request.
  • Limitation of consequential damages: "Neither party is liable for indirect, incidental, or consequential damages" (protects against "you missed a vulnerability, we got hacked, here is our $1M loss" claims).
  • IP ownership: "Client owns findings and reports; consultant retains ownership of tools and methodologies."

Statement of Work (SoW)

A SoW is the project-specific contract. It covers:

  • Scope: Systems, assessment types, exclusions (as defined in section 2.1).
  • Timeline: Engagement dates, testing windows, report delivery date.
  • Deliverables: What you will deliver (report format, executive summary, detailed findings, etc.).
  • Cost: Total fee, payment schedule, any additional costs for scope changes.
  • Assumptions and constraints: What you assume to be true (systems are available, credentials work, etc.).

This is the critical document for a single engagement.

Sample SoW structure:

PROJECT: Q4 2026 Penetration Test - Company XYZ

SCOPE:
- Target systems: 192.168.1.0/24, app.company.com
- Assessment types: Network scanning, web app testing, API testing
- Exclusions: Production database (excluded), physical access (excluded)
- Test window: November 2026, Monday–Friday 9 AM–5 PM EST
- Method: Gray box (staging credentials provided)

DELIVERABLES:
- Executive summary (2–3 pages, non-technical)
- Detailed technical report with findings, impact, remediation
- Presentation to IT team (1 hour)

COST:
- Total: $12,000 USD
- Payment: 50% upon signature, 50% upon report delivery

TIMELINE:
- Engagement: November 13–24, 2026
- Report delivery: November 29, 2026
- Presentation: December 6, 2026

ASSUMPTIONS:
- Client will provide staging credentials by November 10
- Testing will not be interrupted except for documented emergency maintenance
- Client will not patch systems during engagement (to allow tester to test current state)

Rules of Engagement (ROE)

The Rules of Engagement (ROE) is a distinct operational and authorization document. It explains how the penetration test will be conducted within the project described by the SoW. The ROE should document:

  • Scope and boundaries: In-scope targets, exclusions, permitted techniques, test windows, and limits on exploitation or data access.
  • Legal authorization: The organization authorizes the named testers to perform the specified activities against the identified systems during the stated period. For third-party or cloud-hosted resources, document any required provider approval as well.
  • Communication protocols: Primary and backup contacts, status-update procedures, emergency notification channels, escalation triggers, and who can pause or stop testing.
  • Safety controls: Rate limits, maintenance windows, stop conditions, evidence-handling requirements, and procedures for unintended impact.
  • Authorization letters: A signed authorization letter is sometimes informally called a "Get Out of Jail Free" letter. It gives the tester evidence to show that the client authorized the activity, but it does not authorize testing beyond the documented scope or override applicable law or provider terms.

The ROE is not a replacement for the MSA or SoW. The MSA establishes the parties' general commercial and legal relationship, the SoW defines the project-specific services and deliverables, and the ROE defines the boundaries and procedures for performing the test. Keep all three documents consistent and signed before testing begins.

Terms of Service (ToS)

If you are a vendor using cloud platforms (Amazon, Azure, GCP) or third-party tools, you must comply with their ToS. Some explicitly prohibit or restrict penetration testing.

  • AWS: Allows penetration testing of your own resources; prohibits certain activities (DoS, DDoS); requires authorization for specific tests.
  • Azure: Similar restrictions; requires explicit approval.
  • Many SaaS vendors: Prohibit testing of their infrastructure; you can test your configuration.

Implication: Before signing a SoW that includes cloud testing, verify the cloud provider's ToS and ensure the client understands any restrictions. If restrictions are problematic, budget for vendor authorization in your timeline.

The Sequence

Typical engagement workflow:

  1. Discovery call: Discuss goals, scope, timeline, and budget at a high level.
  2. NDA (if not already in place): Both parties sign the confidentiality agreement.
  3. MSA (if required): The parties agree to general commercial and legal terms, including liability, insurance, and dispute resolution.
  4. SoW development and signature: Define and approve the project-specific scope, timeline, deliverables, and cost. Usually takes 1–2 weeks of back-and-forth.
  5. ROE and authorization letter: Prepare and sign the Rules of Engagement and any "Get Out of Jail Free" authorization letter. Confirm targets, boundaries, permitted methods, testing windows, communication protocols, escalation contacts, and stop conditions.
  6. Pre-engagement coordination: Client provides credentials, confirms access, schedules the testing window, and briefs relevant monitoring and incident-response teams.
  7. Testing: Execute the test only within the signed SoW and ROE.
  8. Reporting: Deliver findings, conduct the presentation, and answer questions.
  9. Remediation support (optional): Follow up to verify fixes and re-test if requested.

This sequence is iterative and can be compressed (some firms sign an MSA that covers NDAs and general terms, then issue a much simpler SoW and ROE for each project). The key is that all parties have signed documentation, including the ROE and authorization, before testing starts.

Legal Reality

Do not start testing without a signed SoW, ROE, and authorization. If the client says "we trust you, let's begin and formalize later," decline. Unsigned work creates liability for you and ambiguity for the client. A signed SoW and ROE take time to negotiate. Testing takes two weeks. A delay to establish the legal and operational foundation is professional and standard.

2.5 Target Selection and Pre-Engagement Intelligence

Before the formal engagement begins, you have already gathered information through your scoping discussions. Use this opportunity to build a preliminary understanding of the target.

Questions to Ask the Client

During pre-engagement, ask:

  1. Business context: What does the organization do? Who are the customers? What is the approximate company size?
  2. Current security posture: Do they have a security team? Have they had pen tests before? What was the result?
  3. Known issues: Are there any systems they suspect are vulnerable? Any legacy systems that are hard to patch? Any recent breaches they are recovering from?
  4. Critical systems: What would be considered a catastrophic impact if compromised? (Helps you prioritize post-exploitation testing.)
  5. Compliance requirements: PCI, HIPAA, SOC 2, ISO 27001, GDPR? How do these shape scope?
  6. Technology stack: What applications, databases, frameworks, cloud providers? (Helps you plan reconnaissance and tool selection.)
  7. Previous assessments: Do they have results from past vulnerability scans, pen tests, or security audits? Can they share findings (even high-level) to avoid re-testing known issues?

Preliminary OSINT

Before the engagement formally starts, you can perform public OSINT:

  • Google dorking to find exposed information (see Chapter 4).
  • Checking Shodan or Censys for publicly visible systems.
  • Reviewing DNS records (whois, nslookup).
  • Checking certificate transparency logs.

This is passive reconnaissance: collecting information that already exists in public sources without directly probing, exploiting, or changing the target. For example, reviewing a certificate-transparency record or an existing Shodan result may reveal a hostname or exposed service, but it does not test whether that service is vulnerable. It is therefore preliminary intelligence gathering rather than penetration testing. Chapter 3 covers OSINT and reconnaissance techniques in greater detail.

2.6 Collaboration and Communication Strategy

A penetration test is a collaboration, not a one-way transaction. Clear communication prevents misunderstandings and keeps the engagement on track.

Establishing a Communication Protocol

Define upfront:

  • Primary contact: A single person on the client side who has authority to answer questions and make decisions. This prevents you from receiving conflicting direction from multiple stakeholders.
  • Communication method: Email for formal documentation; Slack, phone, or in-person for quick questions. Define response time expectations ("I will respond to emails within 4 business hours").
  • Reporting line: If you discover something critical, who do you call immediately? (Usually escalation to security leadership, not the original point of contact.)
  • Status updates: Do you provide daily status, weekly updates, or only communicate when findings are ready? Clarify frequency.

Stakeholder Alignment

Different stakeholders have different concerns:

  • IT/System owners: "Will this test disrupt our systems? How do we prepare?"
  • Information Security: "What methodology will you use? How do we validate your findings?"
  • Compliance: "Does this test satisfy our regulatory requirements? How do we document it?"
  • Executive leadership: "What is the impact? Where should we invest in remediation?"

Your job during pre-engagement is to understand each stakeholder's concerns and ensure the test addresses them. This might mean scheduling a kickoff meeting with all parties to align expectations.

Documentation Trail

Document all decisions, scope changes, and clarifications in writing. An email summarizing the conversation is sufficient:

"Thank you for the call today. To confirm: we will test the web application and internal network (192.168.1.0/24), but production database servers are excluded. Testing will occur November 13–24, 9 AM–5 PM EST, Monday–Friday. If this is correct, please confirm by COB Wednesday. If not, let me know the corrections."

This creates a paper trail and prevents the "but I thought we agreed..." moment three weeks into the engagement.

Managing Scope Creep

During the engagement, clients often ask "can you also test this?" or "while you are in there, can you check on that?" Every request is an opportunity for scope creep.

Response: "That is a good point. Let me document it and send you a scope change request with the timeline and cost impact. Once you approve, we will add it to the engagement."

This respects the original contract, protects your timeline and budget, and gives the client a chance to decide whether the additional testing is worth the cost.

Risk Articulation

When you find vulnerabilities, communicate them clearly to different audiences:

For the IT team: Technical detail, what you tested, what you found, how to reproduce it, how to fix it.

For the security team: Impact and context, what an attacker could do, whether you were able to exploit it, whether there are compensating controls.

For executive leadership: Business impact, customer data exposure, regulatory violation risk, operational disruption, revenue impact, reputation risk.

You use the same technical finding but frame it differently for each audience. A SQL injection vulnerability becomes "potential customer data exposure" for the executive summary.

2.7 Authorization Letters and Documentation

The centerpiece of a legal engagement is explicit written authorization. This section covers how to obtain and document it.

What an Authorization Letter Contains

An authorization letter (sometimes called a testing authorization, rules of engagement letter, or scope letter) states that:

  1. The organization authorizes penetration testing.
  2. The specified systems are in scope.
  3. The specified test methods are permitted.
  4. The named individual or company is authorized to perform testing.
  5. The testing window is defined.
  6. The signatory has authority to grant this permission.

Sample language:

AUTHORIZATION FOR PENETRATION TESTING

This letter authorizes [Penetration Testing Company Name] and its authorized
representatives to conduct penetration testing on the systems and networks
listed below during the specified period.

AUTHORIZED TESTER(S): [Name], [Company], [contact information]

TESTING SCOPE:
- Target: Company XYZ internal network (192.168.1.0/24) and web application (app.company.com)
- Assessment type: Network penetration test and web application test
- Testing method: Gray box (staging credentials provided)
- Excluded systems: Production database servers, payment processing infrastructure
- Testing period: November 13–24, 2026, Monday–Friday 9 AM–5 PM EST

PERMITTED ACTIVITIES:
- Network scanning with tools such as Nmap, Nessus
- Web application testing including SQL injection, XSS, authentication testing
- Exploitation of identified vulnerabilities
- Lateral movement and privilege escalation testing
- Documentation and reporting of findings

PROHIBITED ACTIVITIES:
- Denial-of-service attacks
- Data exfiltration beyond what is necessary to document findings
- Physical access to facilities
- Testing of excluded systems
- Testing outside the specified time window

The undersigned acknowledges that this authorization is granted at the organization's request
and in the interest of improving security posture. The undersigned confirms that this
authorization extends only to the specified systems and is limited to the testing window.

AUTHORIZED BY:

Name: ___________________________
Title: ____________________________
Company: _________________________
Date: ____________________________
Signature: ________________________

Signature Authority

The person signing must have clear authority to grant this permission. A helpful IT manager is not enough. You need someone from leadership, Chief Information Security Officer, Chief Information Officer, or owner. If you are unsure, ask "Who in your organization has authority to approve security testing?"

Documentation You Should Maintain

After the engagement:

  • Signed SoW and authorization letters. Secure, encrypted storage.
  • Email confirmations of scope changes. If scope was modified, maintain the email trail.
  • Test notes and logs. Document what you tested, when, and what you found (used to generate the report and defend findings if challenged).
  • Client sign-off on findings. If the client confirms that a finding you reported is a known issue or accepted risk, document that.

This documentation is your legal protection if someone later claims "you tested systems you should not have" or "you caused damage."

Incident Handling and Mandatory Reporting

In the course of testing, you may discover something that requires legal reporting:

  • Active malware infection: Report to law enforcement (FBI, local authorities) and the client's legal counsel.
  • Child exploitation material: Report to the National Center for Missing & Exploited Children (NCMEC) and law enforcement.
  • Imminent threat to public safety: Report to law enforcement.

Your SoW should anticipate this:

"If the tester discovers evidence of ongoing criminal activity or imminent threat to public safety, the tester will immediately notify law enforcement and the client's legal counsel. Testing will suspend pending investigation."

Most incidents do not reach this level, but knowing how to handle them shows professionalism and legal awareness.

Putting It Together: The Pre-Engagement Conversation

You receive an inquiry from a mid-sized financial services firm: "We want a penetration test. Can you start next week?"

Your response to their inquiry:

"Thank you for reaching out. I would like to understand your needs better before we discuss timeline. Let me ask a few questions:

  1. Scope: What systems would you like tested? (networks, web applications, cloud infrastructure, mobile apps?)
  2. Constraints: Are there systems that are off-limits? Any regulatory requirements (PCI, SOX, GLBA) that affect what we can test?
  3. Timeline: You mentioned next week. That is aggressive for scoping. Typically, we spend 1–2 weeks defining scope and securing authorization, then 2–4 weeks on testing, then 1–2 weeks on reporting. Do you have flexibility on timeline?
  4. Budget: What is your budget range? This helps me scope realistically.
  5. Current state: Have you had pen tests before? Any known issues we should focus on?

Once I understand these, I can send you a proposal with scope, timeline, and cost. We would then work toward a signed statement of work before testing begins."

This response shows professionalism, gathers critical information, and sets expectations about timeline and process.

Two weeks later, after email exchanges and a kickoff call, you have:

  • A signed NDA and MSA (if you are a vendor; sometimes clients have their own standard forms).
  • A signed SoW specifying scope, timeline, deliverables, and cost.
  • An authorization letter signed by the Chief Information Officer.
  • Contact information for the primary point of contact and escalation procedures.
  • Staging credentials for gray box testing.
  • A scheduled testing window: Monday–Friday, 9 AM–5 PM, for four weeks.

Now you are ready to begin reconnaissance. But you did not rush into it. You built a foundation that protects everyone involved.

Chapter Summary

  • Scope is defined using CIDR notation, FQDNs, URLs, and explicit inclusions/exclusions. Clear scope prevents testing systems you should not test.
  • Compliance frameworks (PCI, HIPAA, FERPA, GDPR) constrain scope and testing methods. Understand regulatory context before scoping.
  • Shared responsibility model applies to cloud environments. You can test customer configurations but not provider infrastructure.
  • Rules of engagement define testing methods, escalation procedures, testing windows, and risk tolerance.
  • Legal agreements include NDAs (confidentiality), MSAs (general vendor terms), SoWs (project-specific), and ToS compliance.
  • Authorization must be written, specific, and signed by someone with authority. Verbal approval is not sufficient.
  • Communication is bidirectional. Establish a primary contact, define status update frequency, and document scope changes in writing.
  • Risk articulation requires translating technical findings into business impact for different audiences.
  • Documentation (signed agreements, scope change emails, test notes) is your legal protection.