This guide is currently under development, and I greatly welcome any suggestions or feedback or at reaper.gitbook@gmail.com

Client Communication

Setting Proper Expectations

Managing Unrealistic Expectations: Many clients expect you to "hack everything" or find specific vulnerabilities. Your job is to educate them about what penetration testing can and cannot accomplish.

What Penetration Testing Is:

  • Point-in-time security assessment

  • Sampling of potential vulnerabilities

  • Validation of security controls

  • Risk identification and prioritization

What Penetration Testing Is Not:

  • Guarantee that no vulnerabilities exist

  • Comprehensive security audit

  • Compliance certification

  • Ongoing security monitoring

Communication Protocols

Regular Check-ins: Establish how often you'll communicate progress

  • Daily updates for critical findings

  • Weekly status reports for longer engagements

  • Immediate notification for emergency situations

Escalation Procedures: Who to contact when things go wrong

  • Technical Contact: IT administrator who can resolve technical issues

  • Business Contact: Decision-maker who can authorize scope changes

  • Emergency Contact: 24/7 contact for critical security findings

  • Legal Contact: Legal counsel for contract or liability issues

Reporting Timeline: When and how you'll deliver results

  • Preliminary Findings: Critical vulnerabilities requiring immediate attention

  • Draft Report: Complete technical findings for review and clarification

  • Final Report: Polished deliverable with executive summary and recommendations

  • Presentation: Executive briefing and technical deep-dive sessions

Managing Scope Changes

Scope Creep: Clients often want to add systems or change requirements mid-engagement

  • All scope changes must be documented in writing

  • Additional work requires contract amendments

  • Timeline and cost impacts must be clearly communicated

Discovery of New Systems: What happens when you find undocumented systems

  • Report discovery immediately to technical contact

  • Request written authorization before testing new systems

  • Document new systems in final report even if not tested

Last updated

Was this helpful?