Clear and secure communication is the backbone of a successful penetration test or security engagement. By establishing reliable communication protocols early, you ensure that stakeholders stay informed, sensitive data remains protected, and emergencies are handled swiftly without causing unnecessary panic.
Securing Your Communications
Due to the sensitive nature of security testing, encryption is not optional. Before testing begins, you must establish and verify secure communication channels with your client.
Discuss which types of information can be put in writing and which should only be communicated verbally, as some organizations have strict policies regarding written security vulnerabilities.
Common secure communication methods include:
PGP/GPG: Use this for email communication and encrypting the final report. (Note: Email subject lines are always sent in plaintext, so keep them generic).
Secure Mailboxes: Utilize a secure, dedicated mailbox hosted on the customer’s internal network.
Encrypted Archives: When delivering reports or evidence, store the files in an AES-encrypted archive (ensure your utility supports AES encryption using CBC mode).
Direct Communication: Telephone or face-to-face meetings for highly sensitive discussions.
Never mishandle evidence. Always sanitize your test machines between engagements, never hand out USB drives with test reports at conferences, and never reuse a report from another customer as a template. Leaving references to another organization in your document is highly unprofessional and a major security risk.
Creating the Emergency Contact List
Emergencies happen. Whether a system becomes unstable or a critical vulnerability is discovered that requires immediate remediation, you need a predefined list of contacts.
Create an emergency contact list, share it with all involved parties, and ensure it includes the following representatives:
| Role | Recommended Quantity | Description |
|---|---|---|
| Test Team | All testers + 1 Manager | The individuals actively performing the assessment and their direct supervisor. |
| Target Organization | 2 Technical Contacts | IT or security staff at the target organization who can respond to system issues. |
| Customer | 2 Technical + 1 Management | The client's technical liaisons and a business/management contact for escalation. |
For every person on the emergency contact list, gather the following details:
Full name and title.
Operational responsibility and authorization level.
Two forms of 24/7 immediate contact (e.g., cell phone, home phone).
One form of secure bulk data transfer (e.g., SFTP, encrypted email).
A 24/7 staffed help desk or operations center can replace an individual emergency contact, provided they have the authority to escalate issues appropriately.
Regular Status Meetings
Throughout the testing process, it is critical to keep the customer informed of your overall progress. An ignored customer is a former customer.
Schedule daily status meetings. Keep them as brief as possible by focusing strictly on the "Three Ps":
If you must postpone a status report, agree on a new schedule with the client. Never skip a status report altogether.
Incident Reporting Process
Part of a penetration test is evaluating an organization's incident response capabilities. However, you must carefully balance realistic testing with avoiding false alarms.
Ensure that a designated point of contact at the target organization is aware of the testing schedule. This prevents the internal incident response team from waking up upper management in the middle of the night because they believe a genuine cyberattack is underway.
flowchart TD
A["Tester Identifies Issue"] --> B{"Is it a critical incident?"}
B -- "No" --> C["Log for Daily Status Meeting"]
B -- "Yes" --> D["Check Emergency Contact List"]
D --> E["Call 24/7 Technical Contact"]
E --> F["Send Technical Details via PGP/SFTP"]
F --> G["Client Incident Response Team Takes Action"]What is an incident? The National Institute of Standards and Technology (NIST) defines an incident as "a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices." This also includes unauthorized physical access.
Communicating with Third Parties
Modern infrastructure rarely lives entirely on-premises. If your engagement includes testing services hosted by a third party, the client's permission is not enough. You must obtain explicit permission from the third-party providers.
Cloud Service Providers
Cloud environments host data from multiple organizations on shared physical mediums. You must alert the cloud provider, acknowledge their specific testing procedures (which may require request forms or scheduling), and establish a direct security contact with them in case your testing impacts other tenants.
Internet Service Providers (ISPs)
Verify the ISP's terms of service. ISPs often have automated systems that shun or block malicious traffic. While the customer may accept this risk, you must communicate it clearly before starting.
Managed Security Service Providers (MSSPs)
If the MSSP owns the devices or services being tested, they generally need to be notified. Exception: If the explicit goal of the engagement is to test the MSSP's response time and detection capabilities, they should remain unaware (provided the client has authorized this blind test).
Web Hosting Providers
Clearly communicate the scope and timing of the test to the hosting provider. Ensure both the client and the host understand that the test focuses solely on web vulnerabilities, not the underlying shared infrastructure.
Verify Local Laws
Always verify the physical country where the servers are housed. Laws vary wildly by region (e.g., capturing VoIP traffic may be considered illegal wiretapping in certain jurisdictions). It is your responsibility to understand and abide by local laws before transmitting data or launching tests.