Mental Model
"The difference between a penetration tester and a criminal is a signed contract." — Industry Axiom
Professional security assessment begins not with technical tools but with precise agreements. The engagement charter transforms potentially illegal activity into authorized security work. Every boundary you define protects both your client and yourself while ensuring your findings will be actionable and defensible.
Learning Outcomes
By the end of this week, you will be able to:
- LO1: Analyze client requirements to define appropriate assessment scope and boundaries
- LO2: Identify legal and ethical considerations that constrain security testing activities
- LO3: Draft professional engagement documentation that protects all parties
- LO4: Establish communication protocols and escalation procedures for security engagements
- LO5: Evaluate organizational context to tailor assessment approach appropriately
📚 Building on Prior Knowledge
Your capstone integrates technical and governance skills from prior courses:
- CSY203 (Web Security): Methodology and testing patterns for application findings.
- CSY204 (SOC/IR): Incident response perspective for containment and reporting.
- CSY301 (Threat Intelligence): Actor context and threat-driven prioritization.
- CSY302 (Cloud Security): Cloud posture and misconfiguration review.
- CSY303 (GRC): Risk framing, compliance mapping, and executive reporting.
- CSY104 Week 11 (CVSS): Severity scoring for findings and remediation plans.
Introduction: Your First Client Engagement
Welcome to your capstone engagement. You've been hired by SecureFirst Consulting, a boutique security firm, and assigned your first major client: NovaTech Solutions. Before you touch a single tool or run your first scan, you must establish the professional framework that makes everything else possible.
This week mirrors what every security consultant does at engagement kickoff: understanding the client, defining boundaries, and documenting agreements. Skip this phase, and you risk legal exposure, scope creep, unusable findings, or damaged client relationships. Get it right, and you set the foundation for a successful assessment.
The Scenario
You received this email from your manager at SecureFirst Consulting:
Good news — we've been selected for the NovaTech security assessment. They're a growing SaaS company preparing for SOC 2 Type II and need a comprehensive review before their audit window opens.
I'm assigning you as lead consultant. Your first task is to work with their CISO, Marcus Webb, to scope the engagement and draft our charter. The kickoff call is scheduled for next week.
I've attached the client brief from our sales team. Review it thoroughly before the call. Remember: good scoping prevents 90% of engagement problems.
Let me know if you have questions.
— Sarah
1. Understanding Your Client: The NovaTech Brief
Effective scoping requires deep understanding of the client's business context. Security doesn't exist in a vacuum—it serves business objectives. Before defining technical scope, you must understand what NovaTech does, why they need this assessment, and what constraints shape their environment.
NovaTech Solutions — Client Brief
Company Overview
NovaTech Solutions provides enterprise workflow automation through their flagship product, WorkflowPro. Founded in 2018, they've grown from a startup to approximately 500 employees across three locations: headquarters in Austin, TX; engineering office in Portland, OR; and sales office in New York, NY.
Following a $45M Series C funding round, NovaTech is pursuing enterprise customers who require SOC 2 Type II attestation. Their board has mandated an independent security assessment before the SOC 2 audit window begins in Q3.
Organizational Structure
┌─────────────────────────────────────────────────────────────┐
│ CEO: David Park │
├──────────────┬──────────────┬──────────────┬───────────────┤
│ CTO │ CFO │ COO │ CISO │
│ Elena Torres │ James Wright │ Maria Santos │ Marcus Webb │
├──────────────┼──────────────┼──────────────┼───────────────┤
│ Engineering │ Finance │ Operations │ Security │
│ (~120 staff) │ (~25 staff) │ (~200 staff) │ (~8 staff) │
├──────────────┴──────────────┴──────────────┴───────────────┤
│ Other: Sales (~80), Marketing (~40), HR/Admin (~27) │
└─────────────────────────────────────────────────────────────┘
Key Stakeholder: Marcus Webb (CISO) is your primary point of contact. He reports directly to the CEO and has authority to approve assessment scope. Elena Torres (CTO) owns engineering systems and must approve any testing that could impact production.
Technical Environment Summary
Cloud Infrastructure (Primary):
- AWS (us-east-1, us-west-2) — Production and DR environments
- ~150 EC2 instances, RDS PostgreSQL, S3, Lambda functions
- EKS clusters for containerized microservices
- CloudFront CDN for static assets
On-Premises (Legacy):
- Austin HQ datacenter — file servers, Active Directory, legacy ERP
- ~40 physical/virtual servers running Windows Server and RHEL
- VPN connectivity between offices and cloud
SaaS Applications:
- Google Workspace (email, collaboration)
- Salesforce (CRM)
- Workday (HR/payroll)
- GitHub Enterprise (source code)
- Jira/Confluence (project management)
- Slack (internal communication)
WorkflowPro Platform:
- Multi-tenant SaaS application
- React frontend, Node.js/Python backend
- REST and GraphQL APIs
- ~2,500 enterprise customers
- Processes approximately 50M workflow executions/month
Compliance Context
- Current: SOC 2 Type I (obtained 8 months ago)
- Target: SOC 2 Type II (audit window Q3)
- Regulatory: GDPR (EU customers), CCPA (California customers)
- Contractual: Several enterprise prospects require annual penetration testing
Known Concerns (from Sales Discovery)
- Rapid growth has outpaced security team capacity
- Legacy on-prem systems not fully integrated with cloud security controls
- Recent employee turnover in IT operations
- No formal vulnerability management program currently
- Limited security logging and monitoring capabilities
Engagement Drivers
- Board mandate following Series C investment
- Enterprise sales pipeline blocked by security requirements
- Desire to identify and remediate issues before SOC 2 Type II audit
- CISO seeking independent validation to support budget requests
Think About It
Before reading further, consider: What aspects of this client brief would most influence your scoping decisions? What questions would you want answered before defining assessment boundaries?
2. The Purpose of Engagement Scoping
Engagement scoping isn't administrative overhead—it's risk management for both parties. A well-defined scope accomplishes several critical objectives:
Legal Protection
Security testing involves activities that, without authorization, would violate computer crime laws. The engagement charter provides documented authorization that transforms potentially criminal activity into legitimate professional service.
Expectation Alignment
Clients often have unclear or unrealistic expectations about what security assessment entails. Scoping creates shared understanding of what will (and won't) be tested, what deliverables to expect, and what success looks like.
Resource Planning
Scope determines effort. A web application assessment takes different skills and time than a network penetration test or cloud configuration review. Clear scope enables accurate resourcing and scheduling.
Finding Relevance
Findings must be actionable within the client's context. Understanding their compliance requirements, risk tolerance, and business priorities ensures your report addresses what actually matters to them.
Scope Dimensions
Security assessment scope is multidimensional. You must define boundaries across several axes:
┌─────────────────────────────────────────────────────────────────┐
│ SCOPE DIMENSIONS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ TECHNICAL SCOPE METHODOLOGICAL SCOPE │
│ ───────────────── ──────────────────── │
│ • Which systems? • Black box / Gray box / White box? │
│ • Which networks? • Automated scanning allowed? │
│ • Which applications? • Manual exploitation allowed? │
│ • Which cloud accounts? • Social engineering in scope? │
│ • IP ranges / domains • Physical testing in scope? │
│ │
│ TEMPORAL SCOPE CONSTRAINT SCOPE │
│ ────────────── ──────────────── │
│ • Start and end dates • Testing windows (business hours?) │
│ • Testing windows • Rate limiting requirements │
│ • Milestone deadlines • Systems to avoid │
│ • Report due dates • Actions requiring pre-approval │
│ │
│ AUTHORIZATION SCOPE DELIVERABLE SCOPE │
│ ────────────────── ───────────────── │
│ • Who can authorize? • Report format and depth │
│ • Escalation paths • Executive summary required? │
│ • Emergency contacts • Remediation guidance level │
│ • Notification triggers • Presentation/debrief included? │
│ │
└─────────────────────────────────────────────────────────────────┘
Testing Methodology Spectrum
One critical scoping decision is where on the knowledge spectrum your assessment will operate:
| Approach | Tester Knowledge | Simulates | Advantages | Limitations |
|---|---|---|---|---|
| Black Box | No internal knowledge; external perspective only | External attacker with no insider access | Realistic external threat simulation; tests detection capabilities | Time-consuming; may miss internal vulnerabilities; limited depth |
| Gray Box | Partial knowledge; credentials, architecture docs, some access | Attacker with some insider information or compromised credentials | Balanced depth and realism; efficient use of time; tests privilege escalation | Requires client preparation; may not test initial access vectors |
| White Box | Full knowledge; source code, full documentation, admin access | Insider threat or comprehensive security review | Maximum coverage; identifies architectural issues; efficient | Less realistic attack simulation; requires significant client involvement |
For NovaTech's engagement, consider which approach best serves their objectives. They want to identify issues before SOC 2 audit—does that favor depth (white box) or realism (black box)? Their CISO wants to validate security posture—does that require testing detection capabilities?
3. Legal and Ethical Framework
Security testing operates within a complex legal landscape. Understanding these constraints isn't optional—ignorance doesn't provide legal protection, and violations can result in criminal charges, civil liability, and career-ending consequences.
Relevant Legal Frameworks
Computer Fraud and Abuse Act (CFAA) — United States
The primary U.S. federal law governing unauthorized computer access. Key provisions relevant to security testing:
- Prohibits accessing computers "without authorization" or "exceeding authorized access"
- Covers systems used in interstate commerce (virtually all networked systems)
- Violations can result in felony charges with imprisonment up to 20 years
- Civil liability provisions allow affected parties to sue for damages
Implication: Written authorization must clearly define what access is permitted. Testing beyond defined scope may constitute a CFAA violation even with a signed engagement letter.
State Computer Crime Laws
All 50 U.S. states have computer crime statutes, some stricter than federal law. For NovaTech's engagement spanning Texas, Oregon, and New York, you must consider laws in each jurisdiction where testing occurs.
Data Protection Regulations
Testing may expose you to regulated data:
- GDPR: If you access EU personal data during testing, you become a data processor with compliance obligations
- CCPA: California resident data carries similar handling requirements
- Industry Regulations: If client handles healthcare (HIPAA), payment cards (PCI DSS), or financial data (GLBA), additional constraints apply
Third-Party Considerations
Your client can only authorize testing of systems they own or control:
- Cloud providers: AWS, Azure, GCP have specific penetration testing policies requiring notification or approval
- SaaS vendors: Testing Salesforce or Google Workspace requires vendor authorization, not just client authorization
- Shared infrastructure: Co-located systems or shared hosting may impact other tenants
AWS Penetration Testing Policy
Since NovaTech's primary infrastructure is AWS, understanding AWS's penetration testing policy is essential:
AWS Penetration Testing — Key Points
- Permitted Services: EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, and several others can be tested without prior approval
- Prohibited Activities: DNS zone walking via Route 53, DoS/DDoS attacks, port flooding, protocol flooding, request flooding
- Simulated Events: Must request authorization for simulated events like phishing campaigns that use AWS resources
- Other Services: Testing services not explicitly permitted requires AWS Security approval
Note: AWS policy changes periodically. Always verify current policy at aws.amazon.com/security/penetration-testing before beginning any engagement.
Ethical Obligations
Beyond legal requirements, professional ethics guide security practice:
Do No Harm
Testing should not cause business disruption, data loss, or system damage beyond what's explicitly authorized. If you discover you're causing unintended impact, stop immediately.
Protect Confidentiality
You will access sensitive information during testing. All findings, data accessed, and client information must be protected with appropriate controls and disclosed only to authorized parties.
Report Honestly
Findings must be reported accurately without exaggeration or minimization. Your professional obligation is to truth, even when findings are uncomfortable for the client or reflect well/poorly on specific individuals.
Respect Boundaries
Stay within authorized scope. If you discover interesting vulnerabilities outside scope, document them for discussion but don't exploit them. Scope expansion requires explicit authorization.
4. The Engagement Charter
The engagement charter (sometimes called Statement of Work, Rules of Engagement, or Authorization Letter) is the foundational document that authorizes your work. A comprehensive charter includes:
Essential Charter Components
┌─────────────────────────────────────────────────────────────────┐
│ ENGAGEMENT CHARTER STRUCTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. PARTIES AND AUTHORIZATION │
│ • Client legal entity name │
│ • Consulting firm legal entity name │
│ • Authorizing signatories (with authority to bind) │
│ • Effective dates │
│ │
│ 2. ENGAGEMENT OBJECTIVES │
│ • Business context and drivers │
│ • Assessment goals and success criteria │
│ • Compliance/regulatory context │
│ │
│ 3. SCOPE DEFINITION │
│ • In-scope systems, networks, applications │
│ • Out-of-scope items (explicit exclusions) │
│ • IP ranges, domains, cloud accounts │
│ • Testing methodology (black/gray/white box) │
│ │
│ 4. RULES OF ENGAGEMENT │
│ • Permitted testing activities │
│ • Prohibited testing activities │
│ • Testing windows and timing constraints │
│ • Rate limiting and performance constraints │
│ • Data handling requirements │
│ │
│ 5. COMMUNICATION PROTOCOLS │
│ • Primary and secondary contacts (both sides) │
│ • Status reporting frequency and format │
│ • Critical/emergency finding notification process │
│ • Escalation procedures │
│ │
│ 6. DELIVERABLES │
│ • Report format and content expectations │
│ • Delivery timeline │
│ • Presentation/debrief requirements │
│ • Data retention and destruction │
│ │
│ 7. LEGAL PROVISIONS │
│ • Limitation of liability │
│ • Indemnification │
│ • Confidentiality obligations │
│ • Insurance requirements │
│ │
│ 8. SIGNATURES │
│ • Client authorized signatory │
│ • Consultant authorized signatory │
│ • Date executed │
│ │
└─────────────────────────────────────────────────────────────────┘
Critical Finding Notification
One essential charter element is the critical finding notification process. When you discover a severe vulnerability—active compromise, data exposure, trivially exploitable remote code execution—you can't wait for the final report. The charter should define:
- What constitutes critical: Define severity thresholds that trigger immediate notification (e.g., CVSS 9.0+, active exploitation, data breach evidence)
- Who to notify: Direct contact information for security leadership (not general email aliases)
- How to notify: Secure communication channel (encrypted email, secure portal, phone for urgent matters)
- Response expectations: Acknowledgment timeline, decision authority for emergency actions
- Documentation: How critical findings are logged and tracked separately from routine findings
Sample Scope Statement
For NovaTech's engagement, a scope statement might look like this:
Scope Statement — NovaTech Solutions Security Assessment
IN SCOPE:
- External network penetration testing of NovaTech-owned public IP ranges (provided separately in Appendix A)
- Web application assessment of WorkflowPro production application (app.workflowpro.io)
- API security testing of WorkflowPro REST and GraphQL endpoints
- AWS cloud configuration review (accounts: 123456789012, 234567890123)
- Internal network assessment from provided VPN access point
- Active Directory security review
- Review of security configurations for in-scope SaaS applications (Google Workspace, GitHub Enterprise)
OUT OF SCOPE:
- Third-party SaaS applications (Salesforce, Workday, Slack) — client does not have authorization to test
- Physical security testing
- Social engineering (phishing, phone pretexting)
- Denial of service testing
- Customer-tenant data or customer environments within WorkflowPro
- Production database modification or data exfiltration beyond proof-of-concept
TESTING APPROACH:
Gray box methodology. Consultant will be provided: network diagrams, system inventory, standard user credentials for WorkflowPro, VPN access for internal testing, read-only AWS IAM credentials for configuration review.
TESTING WINDOW:
Active testing permitted Monday-Friday, 6:00 AM - 10:00 PM Central Time. Intensive scanning (vulnerability scanners at full speed) restricted to 10:00 PM - 6:00 AM Central Time to minimize business impact. Weekend testing requires 48-hour advance notice.
5. Stakeholder Communication
Effective security engagements require clear communication protocols established before testing begins. You need to know who to contact, when, and how—before you're in a situation requiring urgent communication.
Communication Matrix
For the NovaTech engagement, establish contacts for different scenarios:
| Scenario | NovaTech Contact | SecureFirst Contact | Method | Timeline |
|---|---|---|---|---|
| Routine status updates | Marcus Webb (CISO) | You (Lead Consultant) | Weekly | |
| Technical questions | James Park (Security Engineer) | You | Slack/Email | As needed |
| Scope clarification needed | Marcus Webb | Sarah Chen (Principal) | Email + call | 24-48 hours |
| Testing causing impact | NOC: +1-555-0199 | You | Phone (immediate) | Immediate |
| Critical vulnerability found | Marcus Webb (cell) | Sarah Chen | Phone + encrypted email | Within 4 hours |
| Evidence of active compromise | Marcus Webb + Elena Torres (CTO) | Sarah Chen | Phone (immediate) | Immediate |
| Testing window exception | Marcus Webb | You | 48 hours advance |
Status Reporting
Regular status reports maintain client confidence and catch scope issues early. A typical weekly status report includes:
- Progress summary: What was tested this week, what's next
- Finding preview: High-level summary of issues identified (detailed findings in final report)
- Blockers: Any access issues, questions, or obstacles
- Schedule status: On track, ahead, or behind; any timeline concerns
- Scope notes: Any scope clarifications needed or boundary questions
Best Practice: No Surprises
The final report should never contain surprises for the client. Critical issues are communicated immediately. Significant findings are previewed in status reports. The final report is a polished compilation of information the client already knows, not a dramatic reveal.
6. Preparing for the Kickoff Call
The kickoff call with Marcus Webb is your opportunity to clarify assumptions, gather additional information, and align expectations. Preparation determines the call's effectiveness.
Pre-Call Preparation Checklist
Key Questions for Kickoff
Your kickoff call should address these areas:
Business Context
- What specific concerns prompted this engagement beyond SOC 2 preparation?
- Are there particular systems or areas leadership is most concerned about?
- What's the timeline pressure? When does the SOC 2 audit window open?
- How will findings be used internally? Budget justification? Board reporting?
Technical Details
- Can you provide current network diagrams and asset inventory?
- What monitoring/detection capabilities should we expect? (Affects testing approach)
- Are there recent changes to infrastructure we should be aware of?
- What's the disaster recovery situation? Can you restore if testing causes issues?
Scope Clarification
- For the WorkflowPro assessment, do you want customer-simulating test accounts or only admin-side testing?
- Regarding cloud review—configuration review only, or active exploitation of misconfigurations?
- Any third-party systems where you DO have penetration testing authorization?
- Any recent incident response or known compromise we should be aware of?
Logistics
- Who will provision access credentials and VPN?
- What's the preferred secure communication channel for sensitive findings?
- Are there change freeze windows or high-traffic periods to avoid?
- Who needs to be notified before testing begins?
Self-Check Questions
Test your understanding of engagement scoping and rules of engagement:
Question 1
NovaTech uses Salesforce as their CRM. During your assessment, you discover a potential vulnerability in how NovaTech has configured Salesforce. What should you do?
Reveal Answer
Document the configuration concern but do NOT attempt to exploit or actively test it. Salesforce is explicitly out of scope because NovaTech doesn't have authorization to permit penetration testing of Salesforce's infrastructure. You can report the configuration observation in your findings with a recommendation that NovaTech review it with Salesforce or conduct a configuration review within Salesforce's permitted guidelines. Testing third-party SaaS platforms without vendor authorization could violate the CFAA and the SaaS provider's terms of service.
Question 2
It's Saturday afternoon and you're doing some passive research on NovaTech. You notice their production website is returning database errors that reveal internal system information. What's your response?
Reveal Answer
This likely constitutes a critical finding requiring immediate notification. Even though it's a weekend and outside normal testing windows, publicly visible database errors represent both a security risk and a compliance concern. Contact Marcus Webb via the emergency contact method (phone) to notify him of the exposure. Document the finding with timestamps and screenshots. Don't attempt to exploit the error for deeper access—report what you observed from the public-facing perspective.
Question 3
During scoping, Marcus asks you to include social engineering testing—sending phishing emails to employees to test their security awareness. Your firm has the capability. Should you agree?
Reveal Answer
You can agree, but several additional requirements must be addressed: (1) HR and legal should be involved in approving social engineering tests due to employee relations implications; (2) The scope of phishing must be carefully defined—which employees, what pretexts are permitted, what happens when someone fails; (3) If using any cloud infrastructure to send phishing emails (like AWS SES), you may need additional authorization from the cloud provider; (4) Data collection and privacy implications must be addressed; (5) Consider whether results will be used punitively against employees (generally not recommended). This should be documented as a separate scope item with its own detailed rules of engagement.
Question 4
The engagement charter specifies testing windows of Monday-Friday, 6 AM - 10 PM. You discover what appears to be an active backdoor late Friday night and want to investigate further. What do you do?
Reveal Answer
Evidence of active compromise triggers immediate notification regardless of testing windows. The testing window restrictions exist to minimize business disruption from your testing activities—they don't apply to incident response. Contact Marcus Webb and Elena Torres immediately using emergency contact procedures. Document everything you've observed without taking additional action that might alert the attacker or destroy evidence. The client's incident response takes priority; your engagement may be paused or modified to support their response.
Question 5
Why is "gray box" testing often preferred for compliance-driven assessments like NovaTech's SOC 2 preparation?
Reveal Answer
Gray box testing balances thoroughness with efficiency. For SOC 2 preparation, the goal is identifying and remediating vulnerabilities before the audit—not testing whether an external attacker could find them. Gray box provides: (1) Deeper coverage because time isn't spent on reconnaissance that the client could simply provide; (2) More relevant findings because you understand the architecture and can identify issues a black box test might miss; (3) Better testing of post-authentication vulnerabilities using provided credentials; (4) Efficient use of limited engagement time. Black box might be appropriate for a red team exercise testing detection capabilities, but for vulnerability identification and compliance preparation, gray box typically delivers more value.
Question 6
What's the risk of having the engagement charter signed only by Marcus Webb (CISO) without involvement from legal or executive leadership?
Reveal Answer
Several risks exist: (1) Authority question—Marcus may not have legal authority to bind the company to all provisions (indemnification, liability limitations); (2) Awareness gap—if an incident occurs during testing, executives unaware of the engagement may react poorly; (3) Legal protection weakness—if the authorization is later disputed, having only one signature from a non-executive weakens your legal protection; (4) Scope disputes—without broader stakeholder awareness, others may challenge the scope after the fact. Best practice is having the CISO sign as technical authority AND a C-level executive or general counsel sign as legal/business authority. At minimum, confirm that Marcus has documented authority to authorize security testing.
Lab: Draft Your Engagement Charter
Objective
Create a professional engagement charter for the NovaTech security assessment that would be ready for review by your principal consultant and, after refinement, presentation to the client.
Deliverable
A complete engagement charter document (2,500-4,000 words) covering all essential sections with NovaTech-specific details.
Time Estimate
3-4 hours
Lab Tasks
Part 1: Document Setup (LO3)
Create a professional document with appropriate formatting. Include:
- Document title and version number
- Prepared by / Prepared for information
- Document classification (e.g., "Confidential")
- Table of contents
Part 2: Parties and Authorization (LO3)
Draft the opening section establishing the parties:
- Full legal entity names for both organizations
- Engagement effective dates (use realistic dates)
- Purpose statement referencing NovaTech's objectives
- Authorization statement with signature blocks
Part 3: Scope Definition (LO1)
Develop comprehensive scope documentation:
- In-scope systems with specific detail (reference the client brief)
- Explicit out-of-scope items with rationale
- Testing methodology selection with justification
- Technical boundaries (IP ranges can be placeholder, e.g., "As documented in Appendix A")
Part 4: Rules of Engagement (LO2)
Define testing constraints and permissions:
- Permitted testing activities (be specific)
- Prohibited activities (reference legal considerations)
- Testing windows with timezone specification
- Data handling requirements
- Actions requiring pre-approval
Part 5: Communication Protocols (LO4)
Establish communication framework:
- Contact matrix with roles and methods
- Status reporting schedule and format
- Critical finding notification process with severity definitions
- Escalation procedures
- Secure communication requirements
Self-Assessment Checklist
Before considering your charter complete, verify:
Completeness
- ☐ All eight major sections are present and substantive
- ☐ NovaTech-specific details are incorporated throughout
- ☐ No placeholders remain except where explicitly appropriate (e.g., IP ranges)
Legal Soundness
- ☐ Authorization language is clear and unambiguous
- ☐ Scope boundaries are explicit (no gray areas)
- ☐ Third-party system limitations are addressed
- ☐ AWS penetration testing policy compliance is referenced
Professional Quality
- ☐ Document is well-organized and easy to navigate
- ☐ Language is professional and precise
- ☐ Formatting is consistent throughout
- ☐ Document could be presented to a client without embarrassment
Practical Utility
- ☐ A consultant could use this to know exactly what they can/can't do
- ☐ Emergency contacts and procedures are immediately findable
- ☐ Scope questions can be resolved by reference to this document
Portfolio Integration
Save your engagement charter as the first artifact in your capstone portfolio.
This document will be referenced throughout the engagement and included in your
final portfolio package. Use filename: 01-engagement-charter-novatech.pdf
🎯 Hands-On Capstone Activities
Apply professional engagement practices with real-world scoping and documentation exercises.
📋 Engagement Scoping Exercise
What you'll do: Review a realistic client brief and create a comprehensive scope document including boundaries, assumptions, and constraints.
Why it matters: Scope defines project success—poor scoping leads to scope creep and legal liability.
Time estimate: 3-4 hours
Deliverable: Complete scope of work document ready for client review
⚖️ Rules of Engagement Document
What you'll do: Draft professional RoE including legal authorization, testing windows, contact procedures, and emergency protocols.
Why it matters: RoE protects both tester and client—it's your legal shield during the engagement.
Time estimate: 2-3 hours
Deliverable: Signed RoE ready for legal review and client signature
🤝 Client Kickoff Meeting Simulation
What you'll do: Prepare and conduct a client kickoff meeting—establish expectations, clarify scope, address concerns.
Why it matters: Effective communication at kickoff prevents misunderstandings throughout the engagement.
Time estimate: 2-3 hours
Deliverable: Meeting agenda, presentation slides, and meeting minutes
💡 Capstone Strategy: Document everything professionally from day one—your capstone deliverables should be portfolio-ready for job interviews.
Resources
PTES: Pre-engagement Interactions
The Penetration Testing Execution Standard's guidance on pre-engagement activities including scoping, authorization, and rules of engagement.
pentest-standard.org/Pre-engagement 45 minutesAWS Penetration Testing Policy
AWS's official policy on permitted penetration testing activities. Essential reading before any AWS-targeted assessment.
aws.amazon.com/security/penetration-testing 20 minutesSANS: Sample Penetration Testing Agreement
Template and guidance for penetration testing agreements from SANS, providing additional structure for your engagement charter.
sans.org/white-papers/33739 30 minutesWeekly Reflection
Prompt
Reflect on the relationship between legal authorization and professional ethics in security testing. Consider: How does the engagement charter serve purposes beyond legal protection? What might happen in scenarios where you have legal authorization but face ethical concerns about a testing activity, or vice versa? How would you handle a situation where the client pressures you to expand scope without updating the formal authorization?
Draw on your understanding of professional responsibility and risk management. Your reflection should demonstrate how scoping decisions connect to broader themes of trust, professionalism, and stakeholder management in security practice.
Target length: 250-350 words