PT0-002 Engagement Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Securely delete all test data after the engagement is complete

  Why this is correct

  Securely deleting all test data post-engagement is correct because penetration testing engagements typically operate under a data-handling agreement that mandates the tester to either return or destroy all client data upon conclusion. Secure deletion goes beyond normal file removal—it requires cryptographic erase, overwriting with validated patterns (e.g., NIST SP 800-88 Purge), or physical destruction to ensure data is irrecoverable. This mitigates the risk of inadvertent disclosure, maintains client confidentiality, and aligns with the principle of data minimization.

• ✓

  Return any client data to the client before destruction

  Why this is correct

  Returning any client data to the client before destruction is correct because the client retains ownership and intellectual property rights over data obtained during the test, including credentials, vulnerabilities, and network diagrams. The engagement contract usually specifies that upon completion, the tester must hand over all deliverables and any raw data collected, after which the tester may destroy their residual copies. This ensures the client has full visibility into what was collected and allows them to fulfill their own governance and compliance obligations.

• ✗

  Keep all test data indefinitely for future reference

  Why it's wrong here

  Keeping all test data indefinitely for future reference is incorrect because it violates data minimization and retention policies that are standard in penetration testing agreements and regulatory frameworks like GDPR, HIPAA, or PCI-DSS, which mandate limited retention periods. Long-term storage increases the risk of a breach exposing sensitive client information, and it blurs the scope of the engagement—data that was once authorized for testing may later be used outside the agreed terms, creating legal and ethical liability.

• ✗

  Store test data in an unencrypted archive on the tester's laptop

  Why it's wrong here

  Storing test data in an unencrypted archive on the tester's laptop is incorrect because it exposes the data at rest to compromise if the device is lost, stolen, or accessed by an unauthorized party. Industry best practice and many compliance standards require encryption of sensitive data at rest (e.g., FIPS 140-2 validated full-disk encryption or file-level AES-256) to protect it even if physical security fails. An unencrypted archive is a direct violation of the confidentiality obligations that are core to a penetration tester's professional responsibility.

• ✗

  Share test data with other clients for benchmarking

  Why it's wrong here

  Sharing test data with other clients for benchmarking is incorrect because it breaches the confidentiality clause of the original engagement's NDA and the mutually agreed scope, which typically restricts the use of data solely for the client's benefit. It can expose the client's internal architecture, vulnerabilities, and security deficiencies to third parties—possibly competitors—which could be exploited or used to the client's detriment. Professional standards (e.g., PTES, ethical guidelines) require obtaining explicit written consent from the client before any data or findings are shared outside the engagement.

Go deeper

Related to this question