During a penetration testing engagement, you may encounter unexpected situations, such as discovering a pre-existing breach or navigating strict data privacy laws. This guide explains how to establish clear incident response procedures with your client and protect both your team and their infrastructure before the test begins.
Pre-Engagement Preparation
Due to the sensitive nature of penetration testing, you must ensure all legal and procedural bases are covered before any active testing begins. Discuss these elements with your client to establish clear roles and responsibilities.
- 1
Establish legal authorization
Ensure that the contract or Statement of Work (SOW) signed by both parties explicitly states that all actions taken on the target systems are authorized and performed on behalf of the client.
- 2
Review acceptable use policies
Obtain a copy of the security policies governing the client's systems (often referred to as "Acceptable Use" policies). Verify how these policies handle personal employee data, equipment use, and data ownership.
- 3
Confirm data regulations
Identify the specific laws and regulations that govern the data managed by the client. This will dictate how you interact with databases and file systems during the engagement.
- 4
Secure your testing equipment
Implement Full Drive Encryption (FDE) on all testing systems and removable media that will receive, process, or store any client data.
Handling a Prior Compromise
It is entirely possible to breach a system only to discover that a malicious actor is already there. You must establish a procedure with the client before the engagement on how to handle this scenario.
flowchart TD
A[Discover Evidence of Prior Compromise] --> B[Pause Relevant Testing]
B --> C[Save and Hash Team Activity Logs]
C --> D[Provide Hashed Logs to Client]
D --> E["Client Initiates Internal Incident Response (IR)"]If you find evidence of a prior compromise:
Document your tracks: Save all logs detailing your penetration testing team's actions and timestamps.
Ensure integrity: Hash these logs to prove they haven't been tampered with.
Hand over to the client: Provide the hashed logs to the client so their internal defensive team can separate your authorized testing activity from the malicious actor's activity.
The penetration testing team's role is to provide evidence of the compromise and step back. The client is responsible for determining how best to respond to and handle the actual incident response.
Data Handling and Privacy Rules
When accessing sensitive systems, you must ensure that your data collection methods do not violate applicable laws or client trust.
| Activity | Rule / Best Practice |
|---|---|
| Data Exfiltration | Do not download or store sensitive client data on your own systems. Instead, capture "proof of access" (e.g., file permissions, record counts, or directory listings). |
| Password Cracking | Never use third-party services for password cracking or share any data with third parties without the client's explicit prior written consent. |
| Audio/Video Capture | Check local and national wiretap laws before capturing audio or video during post-exploitation, as this may be considered a severe legal violation. |
What does 'Proof of Access' look like?
Instead of downloading a database containing sensitive customer PII (Personally Identifiable Information), you can run a query to return the total row count, or take a screenshot of the database schema and table names. This proves you had access without exposing the actual sensitive data.
Log Management
During post-exploitation or clean-up phases, you might interact with system logs. It is critical to handle these carefully to avoid disrupting the client's internal security monitoring.
Do not clear logs
No logs should ever be removed, cleared, or modified unless you are specifically authorized to do so by the client in the engagement contract.
If the client does authorize you to clear or modify logs to test their defensive team's response, you must back up the logs prior to making any changes.