Security · Topic 04 of 23 · Part I — Foundations

Engagement lifecycle: scoping, boundaries, and readiness

Most professional disputes trace back to something skipped in this lifecycle — a scoping ambiguity, an untested credential, a missing third-party consent.

Syllabus: § ICT Security Fundamentals (1.1–1.3) → Engagement lifecycle, scope, and pre-engagement readiness

Topic 04 · Scope & readiness

Senior testers spend more time here than anywhere else

By the end of this topic you can:

Walk an engagement from first client contact to first testing activity, naming artefacts at each step
Define "scope" and list the elements that must be unambiguously documented
Classify a test along the BSI axes (information basis, aggressivity, scope, approach, technique, starting point)
Identify scope ambiguities and ask the right clarifying questions
Distinguish in-scope, out-of-scope, and off-limits assets, and resist scope creep
Run a pre-engagement readiness check and refuse to start when blockers remain

The lifecycle at a glance

1Discovery. Learn the client's business, infrastructure, regulatory landscape, and threat perception before any commercial conversation.

2Scoping. Written negotiation of what is tested, how, when, and under what constraints. Produces the Scope document.

3Contracting. SoW, NDA, and Rules of Engagement. The legal foundation.

4Readiness. Verify every practical, legal, technical, and logistical piece is actually in place.

5Execution. Testing.

6Reporting & closeout. Findings delivered; retest; credentials revoked; data destroyed.

This topic covers phases 1, 2, and 4 in depth. Topics 05–06 deepen phase 3. Parts III–IV cover phases 5–6.

The tester as scoping professional

Scoping is a professional negotiation, not a technical exercise. Technical skill is necessary but not sufficient.

Organizational discipline. Track what was agreed, what is open, what was said vs. what is written.
Goal-oriented facilitation. Scope discussions drift; the tester must steer them toward closure.
Judgment under ambiguity. Document exclusions as client request, not low risk, so they are auditable.

Analytical care. "Test production" + "zero downtime tolerance" is a conflict to resolve in scoping, not mid-engagement.
Independence. Disagree when the scope will not answer the stated risk question.
Objectivity. Recognize conflicts of interest, organizational blindness, and political constraints.

Junior testers want to show technical skill; senior testers know the cost of rushing this phase.

Why scope must come first

Scope shapes legal exposure, resource allocation, and client expectations. Most disputes trace to one of four failures:

Failure 1 Tester and client disagree about what was in scope. ("I thought you were testing the database too.")

Failure 2 Tester probes something out of scope. ("That subdomain was shared with another tenant.")

Failure 3 Scope expands without documentation. ("You said on the call we could also look at the partner portal.")

Failure 4 A third-party system is in scope but its operator never consented.

Testing something not in scope — especially third-party systems — is unauthorized access, even if the finding is real.

Discovery: understanding the client first

Competent pre-scoping reconnaissance is not chargeable testing time — it is an investment toward a meaningful scope.

What to learn

Business and data. Critical processes; what data is most damaging if exposed.
Infrastructure. Owned, cloud, on-premises, hybrid, third-party dependencies (CDN, MSP, SaaS, payment processor).
Regulatory landscape. GDPR, FADP, PCI-DSS, HIPAA, FINMA 2023/1, NIS2, DORA — which apply and which drive the engagement.
Threat perception. What incident triggered this engagement? External, insider, supply-chain, or compliance-driven?
Risk appetite. Tolerance for active exploitation, blackout periods, blast radius.

Key questions

What would a 2-hour outage of System X cost?
Which third parties are critical to operations?
Who signs the scope; who owns remediation?
Real production data or sanitized copies?
Calendar window, blackouts, peak business periods?

What a complete scope document contains

In-scope assets — hostnames, IP ranges, URLs, app identifiers, network segments. Explicit and exhaustive.
Out-of-scope assets — often as important as the in-scope list.
Authorized test types — passive, active scanning, exploitation, DoS, social engineering, physical. Default: not authorized unless listed.
Information basis — black / grey / white box.
Aggressivity — low (read-only) → high (exploitation) → calculated (specific exploits listed).
Time window — calendar duration, permitted hours, blackout dates.

Data handling rules.
Incident-handling protocol — who is called, in what order, if the tester crashes a system or finds an active intrusion.
Communication channels — standup cadence, primary technical contact, management contact.
Reporting format and audience.
Deliverables and dates.
Third-party consents — cloud providers, MSPs, SaaS dependencies, shared infrastructure. (See Topic 06.)

Information basis and BSI classification axes

Black / grey / white box

Black box Minimum information an external attacker would have. Maximally realistic, maximally inefficient.
Grey box In-scope list, a low-privileged account, high-level architecture. Most commercial pentests are grey box.
White box Source code, diagrams, credentials, design docs. Maximally efficient at finding deep flaws; less representative of an outsider's view.

The client must choose deliberately — the same budget yields very different results.

BSI classification axes

1. Information basis	Black / grey / white
2. Aggressivity	Passive → calculated → aggressive
3. Scope	Limited / full perimeter
4. Approach	Overt / covert
5. Technique	Network / physical / social / other
6. Starting point	External / internal

Forcing a point on each axis is the most efficient way to surface disagreement before it causes a dispute.

Production vs. staging and real data handling

Production vs. staging

Production — same versions, same configuration drift, same data as real attackers see. Errors affect real customers.
Staging — safer, but typically diverges: different configs, missing data, different access controls. Findings may not reflect production.

Most engagements compromise: reconnaissance against production; exploitation against staging where one exists. The scope must say which is which.

Real data handling (must be written)

Can the tester access real production data at all?
If real data is encountered during exploitation: access, log, screenshot, store, quote in report, encrypt, securely delete?
What data is strictly off-limits? PCI cardholder data, PHI, passwords and API keys, PII.
GDPR/FADP: lawful basis, audit trail of tester access, retention obligations.

Best practice Minimize real-data exposure. Request anonymization or masking. When unavoidable: explicit written permission, isolated test machines, secure deletion plan.

System freeze, blast radius, and scheduling

System freeze

Active changes during the engagement make findings ambiguous and exploits invalid.
Scope must define: frozen perimeter, what counts as frozen, how mid-test patches are handled.
1–2 week freeze for exploitation phases is reasonable.

Blast radius

Monitoring noise — IDS/SIEM alerts. Will the SOC detect or be notified?
Performance — aggressive scanning is a customer-impact event on loaded systems.
Crashes — define who is called and where liability sits.
Cascading effects — if pivot from System A enables System B, stop or follow?

Scheduling

Concrete calendar: start/end dates, testing hours, timezone.
Blackouts: vacations, maintenance, business peaks, regulatory deadlines.
Write the window precisely: "April 15 – May 30, Mon–Fri 09–17 CET".
Verify feasibility before the engagement starts — not after.

Off-limits, scope creep, and discovery vs. exploitation

Out-of-scope vs. off-limits Out of scope: the tester does not test it.
Off-limits: the tester actively avoids it — even if discovered as an attack path.
Typical off-limits entries: safety-critical systems, fragile systems, third-party shared-tenant infrastructure, backup systems.

Scope creep The gradual expansion of "I'll just check this too." Defensive practices: all changes in writing; maintain a running list of "would test if authorized"; default answer to "can you just check…" is not yet — until written.

Discovery vs. exploitation

A client may authorize finding vulnerabilities but not triggering them.
The tester must not cross the line — including automated tools that may exploit by default.

Severity thresholds

Some engagements scope only findings above a stated severity. Report silence on lower-severity items is then by design, not oversight.

Contracting: SoW, NDA, and RoE

Three documents that sometimes overlap but serve distinct purposes. Both SoW and RoE are needed; conflating them is a frequent source of disputes.

SoW — Statement of Work The commercial and legal contract. Defines deliverables, payment, timelines. Lives in the legal archive. Negotiated with procurement or legal.

NDA — Non-Disclosure Agreement Confidentiality terms; often mutual. Protects client data and tester methodology. Sometimes incorporated into the SoW.

RoE — Rules of Engagement The operational document the tester refers to daily: in-scope and off-limits lists, allowed techniques, escalation contacts, communication channels, incident-handling protocol. Derived from the SoW and scope.

Pre-engagement readiness

Skipping readiness is the most common reason a well-scoped engagement stumbles in week one.

Blockers — do not start without these

Scope and RoE signed by both sides.
Third-party consents obtained in writing and verified.
Test accounts created, delivered, and tested by the tester — login and permissions confirmed.
VPN / firewall rules set up and tested by the tester — actual connection confirmed.
Incident-response protocol agreed in writing.

Contacts and communication

Primary technical contact: name, phone, email, availability hours.
Escalation contact: decision-maker when primary is unavailable.
Emergency / out-of-hours: confirmed mobile or on-call rota.
Issue-escalation channel with expected response time.
Q&A / scope-clarification must be in writing — not verbal.

Pre-flight Run the checklist the day before testing starts. Credentials expire overnight; VPNs get reconfigured; contacts go on unscheduled leave.

Check — scope clarification

Scenario

A client says "Test our web application." Write five clarifying questions you would ask before proceeding.

Reveal answer

Which application — URL, environment (production or staging)? What role and credentials does the tester receive? Which APIs are in scope? Active exploitation or discovery-only? Cloud or SaaS dependencies — in or out of scope? Time window and blackout dates? Report audience and format? Who approves third-party testing if cloud-hosted?

What you take home

The engagement lifecycle runs from discovery through closeout — skipping any phase creates traceable liability.
Scoping is a professional negotiation; ambiguity in the scope document becomes a dispute in execution.
A complete scope document names in-scope assets, authorized test types, data handling rules, incident protocol, and third-party consents.
Black / grey / white box and the six BSI axes give a precise shared vocabulary for the scoping conversation.
Out of scope means do not test it; off-limits means actively avoid it — even as an attack path.
Scope creep is resisted with one rule: all changes in writing before proceeding.
Pre-engagement readiness has hard blockers — unsigned scope, no working credentials, missing third-party consent — and testing does not start until they are cleared.

Next: Topic 05 — Legal implications. The legal framework that makes a signed scope the difference between authorized testing and unauthorized access.

END · TOPIC 04

Scope first. Then everything else.

Before next session: draft the five clarifying questions you would ask for a real client request you have encountered or imagined.