---
description: Pre-engagement is the stage of preparation for the actual penetration test.
---

# Pre-Engagement

## Introduction

* During this stage, many questions are asked, and some contractual agreements are made.
* The client informs us about what they want to be tested, and we explain in detail how to make the test as efficient as possible.
* The entire pre-engagement process consists of three essential components:
  1. Scoping questionnaire
  2. Pre-engagement meeting
  3. Kick-off meeting
* It is essential to know who in the company is permitted to contract us for a penetration test.
* This can vary from company to company, with larger organizations not involving the C-level staff directly and the responsibility falling on IT, Audit, or IT Security senior management or the like.
* This stage also requires the preparation of several documents before a penetration test can be conducted that must be signed by our client and us so that the declaration of consent can also be presented in written form if required.
* These documents include, but are not limited to:

<table data-header-hidden><thead><tr><th width="296">Document</th><th>Timing for Creation</th></tr></thead><tbody><tr><td>1. Non-Disclosure Agreement (NDA)</td><td>After Initial Contact</td></tr><tr><td>2. Scoping Questionnaire</td><td>Before the Pre-Engagement Meeting</td></tr><tr><td>3. Scoping Document</td><td>During the Pre-Engagement Meeting</td></tr><tr><td>4. Penetration Testing Proposal (Contract/Scope of Work (SoW))</td><td>During the Pre-engagement Meeting</td></tr><tr><td>5. Rules of Engagement (RoE)</td><td>Before the Kick-Off Meeting</td></tr><tr><td>6. Contractors Agreement (Physical Assessments)</td><td>Before the Kick-Off Meeting</td></tr><tr><td>7. Reports</td><td>During and after the conducted Penetration Test</td></tr></tbody></table>

{% hint style="warning" %}
These documents should be reviewed and adapted by a lawyer after they have been prepared.
{% endhint %}

## Non-Disclosure Agreement (NDA)

* A Non-Disclosure Agreement (NDA) must be signed by all parties.
* There are several types of NDAs:

<table data-header-hidden><thead><tr><th width="172">Type</th><th>Descritpion</th></tr></thead><tbody><tr><td>Unilateral NDA</td><td>This type of NDA obligates only one party to maintain confidentiality and allows the other party to share the information received with third parties.</td></tr><tr><td>Bilateral NDA</td><td>In this type, both parties are obligated to keep the resulting and acquired information confidential. This is the most common type of NDA that protects the work of penetration testers.</td></tr><tr><td>Multilateral NDA</td><td>Multilateral NDA is a commitment to confidentiality by more than two parties. If we conduct a penetration test for a cooperative network, all parties responsible and involved must sign this document.</td></tr></tbody></table>

## Scoping Questionnaire

* After initial contact is made with the client, we typically send them a Scoping Questionnaire to better understand the services they are seeking.
* This scoping questionnaire should clearly explain our services and may ask them which service they are interested in (i.e. Internal Penetration Testing, Internal Vulnerability Assessment, Social Engineering Assessment, etc..)
* Under each of these, the questionnaire should allow the client to be more specific about the required assessment.
* Things like the type of assessment, scope, and client info, should be explained in detail to be able to assign the right resources and deliver the engagement based on the client's expectations.
* This information is also necessary for providing an accurate proposal with regard to the project timeline and cost.
* Some examples of the questions that might be asked in this questionnaire:
  * How many expected live hosts?&#x20;
  * How many IPs/CIDR ranges in scope?&#x20;
  * How many Domains/Subdomains are in scope?&#x20;
  * How many wireless SSIDs in scope?&#x20;
  * How many web/mobile applications?&#x20;
  * If testing is authenticated, how many roles (standard user, admin, etc.)?&#x20;
  * For a phishing assessment, how many users will be targeted?&#x20;
  * Will the client provide a list, or we will be required to gather this list via OSINT?&#x20;
  * If the client is requesting a Physical Assessment, how many locations?&#x20;
  * If multiple sites are in-scope, are they geographically dispersed?&#x20;
  * What is the objective of the Red Team Assessment?&#x20;
  * Are any activities (such as phishing or physical security attacks) out of scope?&#x20;
  * Is a separate Active Directory Security Assessment desired?&#x20;
  * Will network testing be conducted from an anonymous user on the network or a standard domain user?&#x20;
  * Do we need to bypass Network Access Control (NAC)?
  * Is the Penetration Test black box, grey box, or white box?
  * Would they like us to test from a non-evasive, hybrid-evasive (start quiet and gradually become "louder" to assess at what level the client's security personnel detect our activities), or fully evasive?
* Based on the information we received from the scoping questionnaire, we create an overview and summarize all information in the Scoping Document.
* Once we have an initial idea of the client's project requirements, we can move on to the pre-engagement meeting.

## Pre-Engagement Meeting

* This meeting discusses all relevant and essential components with the customer before the penetration test, explaining them to our customer.
* The information we gather during this phase, along with the data collected from the scoping questionnaire, will serve as inputs to the Penetration Testing Proposal, also known as the Contract or Scope of Work (SoW).
* We may encounter clients during our career that are undergoing their first ever penetration test, or the direct client PoC is not familar with the process. It is not uncommon to use part of the pre-engagement meeting to review the scoping questionnaire either in part or step-by-step.
* The most crucial element of this meeting is the detailed presentation of the penetration test to our client and its focus.
* Based on the Contract Checklist and the input information shared in scoping, the Penetration Testing Proposal (Contract) and the associated Rules of Engagement (RoE) are created.

## Kick-Off Meeting

* The kick-off meeting usually occurs at a scheduled time and in-person after signing all contractual documents.
* This meeting usually includes client POC(s), client technical support staff (developers, sysadmins, network engineers, etc.), and the penetration testing team (someone in a management role, the actual penetration tester(s), and sometimes a Project Manager or even the Sales Account Executive or similar).
* We will go over the nature of the penetration test and how it will take place.
* We also explain that if a critical vulnerability is identified, penetration testing activities will be paused, a vulnerability notification report will be generated, and the emergency contacts will be contacted (Typically these are only generated during External Penetration Tests for critical flaws such as unauthenticated remote code execution (RCE), SQL injection, or another flaw that leads to sensitive data disclosure.)
* The purpose of this notification is to allow the client to assess the risk internally and determine if the issue warrants an emergency fix.
* We would typically only stop an Internal Penetration Test and alert the client if a system becomes unresponsive, we find evidence of illegal activity (such as illegal content on a file share) or the presence of an external threat actor in the network or a prior breach.
* We must also inform our customers about potential risks during a penetration test. For example, we should mention that a penetration test can leave many log entries and alarms in their security applications. In addition, if brute forcing or any similar attack is used, it is also worth mentioning that we may accidentally lock some users found during the penetration test. We also must inform our customers that they must contact us immediately if the penetration test performed negatively impacts their network.
* Explaining the penetration testing process gives everyone involved a clear idea of our entire process. This demonstrates our professional approach and convinces our questioners that we know what we are doing.
* All points related to testing need to be discussed and clarified. It is crucial to respond precisely to the wishes and expectations of the customer/client.
* Every company structure and network is different and requires an adapted approach. Each client has different goals, and we should adjust our testing to their wishes.
* We can typically see how experienced our clients are in undergoing penetration tests early in the call, so we may have to shift our focus to explain things in more detail and be prepared to field more questions, or the kickoff call may be very quick and straightforward.

## Checklists

### Contract - Checklist

<table data-header-hidden><thead><tr><th width="186">Checkpoint</th><th>Description</th></tr></thead><tbody><tr><td>NDA</td><td><p>Non-Disclosure Agreement (NDA) refers to a secrecy contract between the client and the contractor regarding all written or verbal information concerning an order/project. </p><p></p><p>The contractor agrees to treat all confidential information brought to its attention as strictly confidential, even after the order/project is completed. </p><p></p><p>Furthermore, any exceptions to confidentiality, the transferability of rights and obligations, and contractual penalties shall be stipulated in the agreement. </p><p></p><p>The NDA should be signed before the kick-off meeting or at the latest during the meeting before any information is discussed in detail.</p></td></tr><tr><td>Goals</td><td>Goals are milestones that must be achieved during the order/project. In this process, goal setting is started with the significant goals and continued with fine-grained and small ones.</td></tr><tr><td>Scope</td><td>The individual components to be tested are discussed and defined. These may include domains, IP ranges, individual hosts, specific accounts, security systems, etc. Our customers may expect us to find out one or the other point by ourselves. However, the legal basis for testing the individual components has the highest priority here.</td></tr><tr><td>Penetration Testing Type</td><td>When choosing the type of penetration test, we present the individual options and explain the advantages and disadvantages. Since we already know the goals and scope of our customers, we can and should also make a recommendation on what we advise and justify our recommendation accordingly. Which type is used in the end is the client's decision.</td></tr><tr><td>Methodologies</td><td>Examples: OSSTMM, OWASP, automated and manual unauthenticated analysis of the internal and external network components, vulnerability assessments of network components and web applications, vulnerability threat vectorization, verification and exploitation, and exploit development to facilitate evasion techniques.</td></tr><tr><td>Penetration Testing Locations</td><td>External: Remote (via secure VPN) and/or Internal: Internal or Remote (via secure VPN)</td></tr><tr><td>Time Estimation</td><td>For the time estimation, we need the start and the end date for the penetration test. This gives us a precise time window to perform the test and helps us plan our procedure. It is also vital to explicitly ask how time windows the individual attacks (Exploitation / Post-Exploitation / Lateral Movement) are to be carried out. These can be carried out during or outside regular working hours. When testing outside regular working hours, the focus is more on the security solutions and systems that should withstand our attacks.</td></tr><tr><td>Third Parties</td><td>For the third parties, it must be determined via which third-party providers our customer obtains services. These can be cloud providers, ISPs, and other hosting providers. Our client must obtain written consent from these providers describing that they agree and are aware that certain parts of their service will be subject to a simulated hacking attack. It is also highly advisable to require the contractor to forward the third-party permission sent to us so that we have actual confirmation that this permission has indeed been obtained.</td></tr><tr><td>Evasive Testing</td><td>Evasive testing is the test of evading and passing security traffic and security systems in the customer's infrastructure. We look for techniques that allow us to find out information about the internal components and attack them. It depends on whether our contractor wants us to use such techniques or not.</td></tr><tr><td>Risks</td><td>We must also inform our client about the risks involved in the tests and the possible consequences. Based on the risks and their potential severity, we can then set the limitations together and take certain precautions.</td></tr><tr><td>Scope Limitations &#x26; Restrictions</td><td>It is also essential to determine which servers, workstations, or other network components are essential for the client's proper functioning and its customers. We will have to avoid these and must not influence them any further, as this could lead to critical technical errors that could also affect our client's customers in production.</td></tr><tr><td>Information Handling</td><td>HIPAA, PCI, HITRUST, FISMA/NIST, etc.</td></tr><tr><td>Contact Information</td><td>For the contact information, we need to create a list of each person's name, title, job title, e-mail address, phone number, office phone number, and an escalation priority order.</td></tr><tr><td>Lines of Communication</td><td>It should also be documented which communication channels are used to exchange information between the customer and us. This may involve e-mail correspondence, telephone calls, or personal meetings.</td></tr><tr><td>Reporting</td><td>Apart from the report's structure, any customer-specific requirements the report should contain are also discussed. In addition, we clarify how the reporting is to take place and whether a presentation of the results is desired.</td></tr><tr><td>Payment Terms</td><td>Finally, prices and the terms of payment are explained.</td></tr></tbody></table>

### Rules of Engagement - Checklist&#x20;

<table data-header-hidden><thead><tr><th width="227">Checkpoint</th><th>Contents</th></tr></thead><tbody><tr><td>Introduction</td><td>Description of this document.</td></tr><tr><td>Contractor</td><td>Company name, contractor full name, job title.</td></tr><tr><td>Penetration Testers</td><td>Company name, pentesters full name.</td></tr><tr><td>Contact Information</td><td>Mailing addresses, e-mail addresses, and phone numbers of all client parties and penetration testers.</td></tr><tr><td>Purpose</td><td>Description of the purpose for the conducted penetration test.</td></tr><tr><td>Goals</td><td>Description of the goals that should be achieved with the penetration test.</td></tr><tr><td>Scope</td><td>All IPs, domain names, URLs, or CIDR ranges.</td></tr><tr><td>Lines of Communication</td><td>Online conferences or phone calls or face-to-face meetings, or via e-mail.</td></tr><tr><td>Time Estimation</td><td>Start and end dates.</td></tr><tr><td>Time of the Day to Test</td><td>Times of the day to test.</td></tr><tr><td>Penetration Testing Type</td><td>External/Internal Penetration Test/Vulnerability Assessments/Social Engineering.</td></tr><tr><td>Penetration Testing Locations</td><td>Description of how the connection to the client network is established.</td></tr><tr><td>Methodologies</td><td>OSSTMM, PTES, OWASP, and others.</td></tr><tr><td>Objectives / Flags</td><td>Users, specific files, specific information, and others.</td></tr><tr><td>Evidence Handling</td><td>Encryption, secure protocols</td></tr><tr><td>System Backups</td><td>Configuration files, databases, and others.</td></tr><tr><td>Information Handling</td><td>Strong data encryption</td></tr><tr><td>Incident Handling and Reporting</td><td>Cases for contact, pentest interruptions, type of reports</td></tr><tr><td>Status Meetings</td><td>Frequency of meetings, dates, times, included parties</td></tr><tr><td>Reporting</td><td>Type, target readers, focus</td></tr><tr><td>Retesting</td><td>Start and end dates</td></tr><tr><td>Disclaimers and Limitation of Liability</td><td>System damage, data loss</td></tr><tr><td>Permission to Test</td><td>Signed contract, contractors agreement</td></tr></tbody></table>

### Contractors Agreement - Checklist for Physical Assessments

* Introduction
* Contractor&#x20;
* Purpose
* Goal
* Penetration Testers
* Contact Information
* Physical Addresses&#x20;
* Building Name
* Floors
* Physical Room Identifications
* Physical Components&#x20;
* Timeline
* Notarization
* Permission to Test
