CSY399 Week 01 Capstone

Week Content

Cybersecurity Capstone

Track your progress through this week's content

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:

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:

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:

Third-Party Considerations

Your client can only authorize testing of systems they own or control:

AWS Penetration Testing Policy

Since NovaTech's primary infrastructure is AWS, understanding AWS's penetration testing policy is essential:

AWS Penetration Testing — Key Points

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:

Sample Scope Statement

For NovaTech's engagement, a scope statement might look like this:

Scope Statement — NovaTech Solutions Security Assessment

IN SCOPE:

OUT OF SCOPE:

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) Email 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 Email 48 hours advance

Status Reporting

Regular status reports maintain client confidence and catch scope issues early. A typical weekly status report includes:

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

PTES Scoping Guidelines →

⚖️ 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

SANS RoE Templates →

🤝 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

CISA Engagement Resources →

💡 Capstone Strategy: Document everything professionally from day one—your capstone deliverables should be portfolio-ready for job interviews.

Resources

Required

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 minutes
Required

AWS 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 minutes
Optional

SANS: 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 minutes

Weekly 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

Week 01 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz