2. Problem Discovery, Stakeholders and Engagement Scoping

Introduction and Context

Cybersecurity projects rarely fail because an organisation cannot purchase a security tool. They fail more often because the problem was misunderstood, the wrong people were consulted, the engagement boundaries were unclear, or success was defined in vague terms. A technically sophisticated assessment can therefore produce limited value if it examines the wrong systems, overlooks business priorities, or recommends controls that the organisation cannot implement.

Problem discovery and engagement scoping provide the foundation for applied cybersecurity practice. They convert an initial concern—such as a suspected vulnerability, compliance finding, ransomware exposure, or cloud migration risk—into a clearly defined professional engagement. This requires more than collecting requirements. It involves understanding the organisational context, identifying stakeholders and their interests, distinguishing symptoms from root causes, negotiating scope, documenting assumptions and constraints, and establishing rules under which security work may safely proceed.

The output is normally a project charter, statement of work, engagement letter, or equivalent document. That document creates a shared understanding between the cybersecurity practitioner and the sponsoring organisation. It does not eliminate uncertainty, but it makes uncertainty visible and manageable.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish a cybersecurity symptom, event, risk, problem, and underlying cause.

2. Identify, classify, and analyse stakeholders in a security engagement.

3. Define an engagement’s scope, assumptions, constraints, exclusions, and dependencies.

4. Formulate measurable deliverables and success criteria.

5. Develop appropriate rules of engagement for testing, assessment, or advisory work.

6. Construct a viable cybersecurity project charter.

7. Recognise ethical, legal, governance, and operational risks in engagement planning.

8. Apply structured discovery methods to a realistic organisational scenario.

From Concern to Defensible Problem Definition

A problem statement is not simply a description of a technology. “The organisation needs a vulnerability scan” describes a proposed activity, not the problem requiring attention. A defensible problem definition explains the undesirable condition, the assets or processes affected, the consequences of leaving it unresolved, and the evidence currently available.

Several related concepts must be separated. An event is an observable occurrence, such as repeated failed logins. An incident is an event that has, or may have, adverse effects on confidentiality, integrity, or availability. A vulnerability is a weakness that may be exploited. A threat is a circumstance or actor capable of exploiting a vulnerability. Risk combines the possibility of an adverse event with its potential consequences. A problem is the organisational condition requiring investigation or improvement. A root cause is the deeper condition producing or sustaining the problem.

For example, an organisation may report that its security team receives too many alerts. The alert volume is a symptom. Investigation may reveal duplicated detection rules, poorly tuned thresholds, incomplete asset ownership, and a lack of triage procedures. Buying another monitoring platform would not necessarily address those causes.

A useful problem statement generally answers five questions:

• What condition is unsatisfactory?
• Which assets, services, users, or obligations are affected?
• What evidence supports the concern?
• What consequences may arise if it remains unresolved?
• What decision or change should the engagement enable?

The statement should be specific without prematurely prescribing a solution. A suitable formulation might be: “The organisation cannot reliably determine whether privileged access to its cloud production environment is appropriately authorised and reviewed, creating uncertainty regarding account misuse and audit compliance.” This wording leaves room to investigate identity governance, logging, review processes, and technical configuration.

Discovery as an Investigative Process

Discovery is an iterative process rather than a single meeting. Initial information is usually incomplete, biased toward the sponsor’s perspective, and expressed in organisational language rather than security terminology. The practitioner should therefore test claims, compare perspectives, and seek evidence.

Common discovery activities include sponsor interviews, workshops, document review, architecture walkthroughs, process observation, asset and data-flow analysis, control mapping, and sampling of relevant records. Useful documents may include policies, network diagrams, system inventories, previous audit reports, incident records, risk registers, contracts, regulatory obligations, and business continuity plans.

Interviews should explore both facts and perceptions. Questions such as “Who owns this system?”, “What would happen if it were unavailable for two days?”, “How is access approved and removed?”, and “Which previous recommendations remain unresolved?” often reveal more than a request for a list of controls. Contradictions are valuable evidence. If an asset inventory says a system is retired while operations staff still depend on it, the discrepancy itself becomes part of the discovery outcome.

A disciplined practitioner distinguishes verified facts, stakeholder assertions, working hypotheses, and unresolved questions. This distinction prevents assumptions from being presented as evidence.

Stakeholder Analysis in Cybersecurity Engagements

A stakeholder is an individual, group, or institution that can affect the engagement, is affected by it, or has a legitimate interest in its outcomes. Stakeholders extend beyond the information security department. They may include executive sponsors, system owners, business process owners, infrastructure and application teams, legal and privacy officers, internal audit, procurement, human resources, customers, suppliers, regulators, and affected employees.

Stakeholder analysis is important because cybersecurity decisions distribute benefits, costs, risks, and responsibilities unevenly. A security control may improve protection while increasing operational effort. A penetration test may be valuable to the security team but disruptive to a service owner. A privacy office may object to the unnecessary collection of personal data during testing. Effective engagement planning makes these interests explicit.

Identifying and Classifying Stakeholders

A stakeholder register can record each stakeholder’s role, authority, interests, expected contribution, concerns, preferred communication method, and level of engagement. Stakeholders may be classified according to several dimensions:

• Power or authority: ability to approve, fund, stop, or redirect the work.
• Interest: degree to which the stakeholder is affected or concerned.
• Influence: ability to shape decisions or implementation, even without formal authority.
• Impact: extent to which the engagement changes the stakeholder’s work or risk exposure.
• Expertise: knowledge required to interpret evidence or validate recommendations.

A power–interest matrix is a practical starting point. High-power, high-interest stakeholders require close management. High-power, low-interest stakeholders should receive concise assurance and decision-focused updates. Low-power, high-interest stakeholders may provide essential operational knowledge and should not be ignored. Low-power, low-interest groups generally require proportionate monitoring.

The matrix is not a substitute for judgement. A service desk manager may have little formal authority but possess critical knowledge about recurring access failures. Similarly, a supplier may not approve the engagement but may control an interface necessary for testing. Stakeholder analysis should therefore consider informal influence and dependencies.

Responsibilities and Decision Rights

Engagements become confused when consultation is mistaken for approval. A responsibility assignment matrix, such as RACI, can clarify whether a party is responsible for performing work, accountable for the outcome, consulted before decisions, or informed afterward. For example, a security assessor may be responsible for testing, the system owner accountable for authorising access, legal counsel consulted on contractual restrictions, and the executive sponsor informed of material findings.

Accountability should remain with the organisation that owns the risk. A consultant can identify a vulnerability and recommend treatment, but should not silently accept the risk on behalf of management. This distinction is central to professional integrity.

Establishing Engagement Scope

Scope defines what the engagement will and will not address. It should be specific enough to guide action and flexible enough to accommodate controlled change. Scope commonly covers organisational units, locations, systems, applications, networks, cloud services, data types, processes, time periods, threat scenarios, control domains, and methods of work.

A strong scope statement includes:

1. In-scope assets and processes: systems, applications, identities, locations, services, and business activities examined.

2. Out-of-scope items: assets or activities deliberately excluded and the reason for exclusion.

3. Assessment boundaries: depth of review, testing intensity, environments, accounts, and data permitted.

4. Interfaces and dependencies: third parties, shared services, inherited controls, and connected systems.

5. Time boundary: the period of evidence reviewed and the engagement schedule.

6. Change procedure: how additions, exclusions, or material changes will be approved.

Scope can be expressed through an asset list, network ranges, cloud subscriptions, application identifiers, business process maps, data classifications, or control objectives. Vague phrases such as “the corporate network” are inadequate because they do not identify whether remote offices, production environments, wireless networks, subsidiaries, or third-party connections are included.

Assumptions, Constraints, and Dependencies

An assumption is treated as true for planning purposes but has not been fully verified. Examples include an assumption that a system owner will provide read-only access or that a supplier will be available for an interview. Assumptions should have owners and validation dates.

A constraint limits the engagement. Common constraints include a fixed budget, limited access to production systems, restricted testing windows, data residency requirements, staff availability, confidentiality obligations, or a prohibition on destructive testing. Constraints do not necessarily invalidate an engagement, but they affect the confidence and completeness of its conclusions.

A dependency is an external condition required for progress, such as a current asset inventory, firewall approval, a cloud administrator, or a third-party contract. Dependencies should be monitored because delays often arise outside the immediate project team.

Deliverables and Success Criteria

Deliverables are tangible outputs; success criteria describe how the outputs or outcomes will be judged. A deliverable might be a validated asset inventory, risk-ranked findings register, control-gap analysis, executive briefing, remediation roadmap, or retest report. A success criterion might require that all critical in-scope assets are accounted for, that findings are supported by reproducible evidence, or that owners and due dates are assigned to agreed remediation actions.

Good success criteria are specific, observable, and proportionate. “Improve security” is not measurable. “Provide management with a prioritised list of externally exposed authentication weaknesses, each mapped to an owner, business impact, evidence, and recommended treatment” is more defensible. Where numerical targets are used, their limitations should be recognised. A reduction in vulnerabilities does not necessarily mean a reduction in material business risk if critical assets remain unprotected.

Rules of Engagement

Rules of engagement govern how cybersecurity work will be conducted. They are especially important for penetration tests, vulnerability assessments, incident-response support, social-engineering exercises, and activities involving personal or production data.

A rules-of-engagement document normally specifies:

• authorised testers and points of contact;
• written authorisation and ownership of the tested assets;
• dates, time windows, and permitted source addresses;
• techniques allowed, restricted, or prohibited;
• systems and data that must not be accessed;
• treatment of credentials, personal data, and evidence;
• rate limits and safeguards against service disruption;
• emergency stop authority and escalation contacts;
• incident handling if testing triggers an alert or causes harm;
• evidence storage, transmission, retention, and destruction;
• reporting channels and communication expectations.

Authorisation must be sufficiently precise. Permission to test an organisation’s web application does not automatically authorise testing a cloud provider, a payment processor, a managed service, or a connected customer portal. Third-party approval may be required. Similarly, a vulnerability scan may be authorised while exploitation, password spraying, denial-of-service activity, or data extraction is prohibited.

The principle of least privilege applies to engagement access. Test accounts should be limited, monitored, time-bound, and removed when no longer required. Sensitive findings should be transmitted through approved channels and shared only with people who need them.

The Project Charter as a Governance Instrument

A project charter turns discovery into an agreed operating model. It should normally contain the engagement purpose, problem statement, objectives, scope, exclusions, stakeholders, governance structure, assumptions, constraints, dependencies, methods, deliverables, milestones, resources, risks, success criteria, reporting arrangements, and rules of engagement.

A useful charter is neither a lengthy technical report nor a formality signed without review. It provides a baseline for managing changes and disagreements. If a sponsor later requests testing of an excluded system, the team can assess the request against the charter rather than relying on informal messages. If evidence is unavailable, the charter makes it possible to explain how that limitation affects confidence.

Charters should be reviewed at suitable decision points. A discovery review confirms the problem and stakeholders. A scope approval authorises the boundaries and methods. A mid-engagement review addresses material changes. A closure review confirms deliverables, residual risks, evidence handling, and ownership of next steps.

Applied Scenario: Northbridge Health Services

The following is an illustrative case developed for educational purposes.

Background

Northbridge Health Services operates clinics, diagnostic laboratories, and a patient portal. Its executive committee commissions a cybersecurity engagement after an external auditor reports weaknesses in privileged access management. The initial request is: “Perform a penetration test of the patient portal and assess privileged accounts.”

Situation and Problem Discovery

During the first sponsor meeting, the security manager focuses on the audit finding, while the portal product owner is concerned about service availability. The privacy officer explains that test data may contain sensitive health information. The infrastructure team reports that several administrative accounts are shared with an outsourced laboratory provider. The audit report, however, covers only a sample of systems and does not establish whether the shared accounts remain active.

The practitioner reframes the problem as uncertainty about whether privileged access to patient-facing and laboratory-supporting systems is authorised, individually attributable, periodically reviewed, and promptly removed when no longer needed. The portal penetration test remains relevant, but it is only one source of evidence.

Stakeholder and Scope Analysis

The chief information officer is the executive sponsor and approves resources. The security manager coordinates the engagement. The portal product owner is accountable for service availability. The laboratory technology manager owns the outsourced interface. Privacy and legal officers advise on patient data and contractual permissions. The external laboratory provider must authorise testing of its managed components.

In scope are the patient portal authentication functions, administrative roles, identity-provider configurations supporting the portal, privileged access to two laboratory-support systems, and access-review procedures for the previous twelve months. The clinical record system is excluded because it is undergoing a separate safety assessment. Denial-of-service testing, social engineering, and exploitation of laboratory-provider infrastructure are excluded unless separately authorised.

Approach

The team first reviews architecture diagrams, access lists, contracts, audit evidence, and termination records. It conducts interviews with system owners and samples privileged accounts. A controlled assessment of the portal examines authentication and authorisation without extracting patient records. Test accounts are uniquely identified and monitored. The laboratory provider supplies written permission for the agreed interface tests.

The rules of engagement establish a testing window outside peak clinic hours, a stop contact available at all times, rate limits, prohibited data access, and immediate reporting of any suspected patient-data exposure. Findings are ranked according to business impact and exploitability, not merely technical severity.

Outcome

The assessment finds that the portal’s administrator roles are individually attributable, but two dormant contractor accounts remain enabled in a laboratory-support environment. Quarterly access reviews were documented, yet review evidence did not demonstrate that account owners had examined actual privileges. The most important recommendation is therefore not simply to patch software. It is to implement an integrated joiner–mover–leaver process, strengthen ownership of outsourced identities, and require evidence-based privilege review.

The final charter and report distinguish confirmed findings from limitations. Because the clinical record system and provider infrastructure were excluded, the report does not claim organisation-wide assurance. Management accepts the remediation plan, assigns owners, and schedules a retest after implementation.

Learning Points

The case demonstrates that an initial technical request may conceal a broader governance problem. It also shows why stakeholder authority, third-party permission, privacy safeguards, scope exclusions, and evidence limitations must be addressed before testing begins. A narrow penetration test could have missed the dormant laboratory accounts and created a misleading impression of assurance.

Challenges, Risks, and Common Mistakes

One common mistake is scope driven by available tools rather than organisational risk. A scanner may identify technically interesting issues while ignoring unsupported business processes or high-impact access pathways. Another mistake is accepting the sponsor’s first description without interviewing affected operators and owners.

Scope creep is a further risk. Informal requests can expand the engagement without additional time, authority, or resources. Scope should be changed through a documented process that considers impact on schedule, risk, permissions, and deliverables.

Overly broad scope creates superficial analysis, while excessively narrow scope creates false assurance. The appropriate balance depends on the decision the engagement must support. A further danger is confusing absence of evidence with evidence of absence. If logs were unavailable, the correct conclusion is that the control could not be verified—not that no unauthorised activity occurred.

Other frequent failures include unclear acceptance criteria, failure to identify third-party ownership, untested assumptions, excessive collection of personal data, weak evidence protection, and reports written for executives without operationally actionable recommendations.

Ethical, Legal, and Governance Considerations

Cybersecurity practitioners operate with privileged access and knowledge. They must respect authorisation boundaries, confidentiality, privacy, proportionality, and professional competence. Testing beyond permission may constitute unauthorised access even when the intention is defensive. The least intrusive method capable of answering the question should be preferred.

Engagements involving personal data require purpose limitation, data minimisation, access control, retention limits, and secure disposal. Legal and privacy specialists should be consulted where jurisdiction, cross-border processing, employee monitoring, regulated data, or contractual restrictions are relevant.

Governance also requires transparent treatment of residual risk. Management may decide not to remediate a finding, but that decision should be informed, documented, time-bound where appropriate, and assigned to an accountable risk owner. A practitioner should not dilute a material finding to avoid discomfort or allow commercial interests to compromise professional judgement.

Technology and Emerging Practice

Digital tools can improve discovery and scoping. Configuration-management databases, cloud asset inventories, identity analytics, attack-surface monitoring, data-flow mapping, and security information and event management platforms help establish evidence. Automated discovery is valuable, but it should be validated because inventories may contain stale records, duplicate assets, or incomplete ownership information.

Artificial intelligence can assist with interview transcription, document classification, control mapping, and identification of inconsistencies across inventories and policies. It should not replace human judgement about authorisation, business impact, legal restrictions, or risk acceptance. Sensitive engagement material should not be uploaded to an external AI service without approved safeguards. Generated summaries must be checked against source evidence, particularly where findings could affect individuals or regulatory reporting.

Current practice increasingly treats identity, cloud services, software supply chains, application programming interfaces, and managed service providers as interconnected scope elements. Consequently, scoping must follow trust relationships and data flows rather than organisational boundaries alone. Continuous assessment also challenges the traditional assumption that a charter remains unchanged until a final report; material changes in assets, threats, or suppliers may require controlled re-scoping.

Best Practices for a Viable Engagement

A sound engagement follows several practical disciplines:

• begin with the decision the organisation needs to make;
• define the problem before selecting the technical method;
• involve asset owners, operators, legal or privacy advisers, and affected business units;
• record facts, assumptions, uncertainties, and evidence separately;
• identify both in-scope and explicitly excluded assets;
• obtain written authorisation and third-party permissions;
• make deliverables and success criteria observable;
• use proportionate testing and protect sensitive evidence;
• establish escalation and stop procedures before technical work begins;
• review scope when material assumptions change; and
• assign every accepted action to an accountable owner.

These practices improve not only the quality of technical findings but also the likelihood that findings will be understood, accepted, and implemented.

Chapter Summary

Problem discovery converts a broad concern into a defensible cybersecurity problem statement grounded in evidence and organisational consequences. Stakeholder analysis identifies authority, interests, expertise, dependencies, and accountability across technical and business communities. Engagement scoping establishes assets, processes, methods, exclusions, assumptions, constraints, and dependencies. Deliverables and success criteria make results assessable, while rules of engagement protect systems, data, people, and the legal position of all parties.

The project charter integrates these elements into a governance baseline. It supports decision-making, controls scope change, clarifies responsibilities, and records limitations. Effective practitioners avoid tool-led investigations, unsupported assumptions, unauthorised testing, and false claims of assurance. They combine technical understanding with communication, ethics, risk judgement, and organisational awareness.

Key Terms

Problem statement: A concise description of an undesirable condition, its effects, evidence, and decision context.

Symptom: An observable indication of a deeper problem or cause.

Root cause: An underlying condition that produces or sustains a problem.

Stakeholder: A person, group, or institution that affects or is affected by an engagement.

Stakeholder register: A record of stakeholder roles, interests, authority, concerns, and communication needs.

Power–interest matrix: A model for prioritising stakeholder engagement according to authority and concern.

RACI: A responsibility model identifying who is Responsible, Accountable, Consulted, and Informed.

Scope: The agreed boundaries of activities, assets, processes, methods, and time.

Scope exclusion: An explicitly omitted asset, process, or activity.

Assumption: An unverified condition treated as true for planning.

Constraint: A factor that limits available methods, resources, access, or timing.

Dependency: An external condition required for engagement progress.

Deliverable: A tangible output produced by the engagement.

Success criterion: An observable condition used to judge whether objectives were met.

Rules of engagement: Authorised procedures, limits, safeguards, and escalation arrangements for security work.

Project charter: An approved document defining an engagement’s purpose, governance, scope, resources, and controls.

Residual risk: Risk remaining after controls or treatments are applied.

False assurance: An unjustified belief that security is adequate because evidence or scope was incomplete.

Scope creep: Uncontrolled expansion of engagement activities or boundaries.

Risk owner: The person or authority accountable for accepting or treating a risk.

Review Questions

Short Answer Questions

1. How does a cybersecurity problem differ from a proposed technical solution?

2. What is the purpose of a stakeholder register?

3. Distinguish an assumption from a constraint and a dependency.

4. Why should scope exclusions be documented explicitly?

5. What information should rules of engagement contain?

Long Answer Questions

1. Explain how a practitioner can move from an initial cybersecurity concern to an evidence-based problem statement.

2. Discuss the role of power, interest, influence, and expertise in stakeholder analysis.

3. Explain how a project charter supports governance and scope control throughout an engagement.

4. Analyse the relationship between deliverables, success criteria, evidence limitations, and management decisions.

5. Discuss the ethical and legal considerations involved in testing systems connected to third-party services.

Analytical / Application Questions

1. An organisation asks for a vulnerability scan after a ransomware incident but cannot identify all internet-facing assets. Design a discovery and scoping approach, including stakeholders, evidence, assumptions, and initial exclusions.

2. A penetration test is authorised for a web application hosted by a cloud provider, but the contract does not address security testing. Explain the risks and propose the approvals and rules required before testing.

3. An assessment finds no evidence of unauthorised access because relevant logs were unavailable. How should this limitation be expressed in the report, and what follow-up actions should be included?

22. Multiple Choice Questions with Answers

Question 1

Which statement best represents a defensible cybersecurity problem statement?

A. The organisation should buy a new security information and event management platform.

B. The organisation cannot reliably verify whether privileged cloud access is authorised and reviewed.

C. The security team needs more training on incident response tools.

D. The network requires a complete penetration test immediately.

Correct Answer: B. The organisation cannot reliably verify whether privileged cloud access is authorised and reviewed.

Question 2

A service desk manager has little formal authority but detailed knowledge of recurring access failures. How should the manager be treated in stakeholder analysis?

A. Ignored because the manager lacks approval authority.

B. Classified as irrelevant to technical scope.

C. Recognised as a potentially influential operational stakeholder.

D. Made accountable for accepting organisational risk.

Correct Answer: C. Recognised as a potentially influential operational stakeholder.

Question 3

Which item is an engagement constraint?

A. The cloud administrator must provide temporary read-only access.

B. The assessment cannot test production systems during business hours.

C. The system owner will approve the final report.

D. The organisation has an external identity provider.

Correct Answer: B. The assessment cannot test production systems during business hours.

Question 4

What is the primary purpose of documenting scope exclusions?

A. To demonstrate that no further security work is ever needed.

B. To prevent stakeholders from knowing the engagement limitations.

C. To clarify what is not assessed and reduce false assurance.

D. To replace the need for written authorisation.

Correct Answer: C. To clarify what is not assessed and reduce false assurance.

Question 5

Which activity is most appropriate before testing a third-party managed system?

A. Assume that the organisation’s approval covers the supplier.

B. Obtain appropriate written permission and define the testing boundary.

C. Test the system secretly to avoid supplier delays.

D. Extract data first and request approval afterward.

Correct Answer: B. Obtain appropriate written permission and define the testing boundary.

Question 6

Which statement correctly distinguishes a deliverable from a success criterion?

A. A deliverable is an output; a success criterion explains how achievement is judged.

B. A deliverable is a risk; a success criterion is a stakeholder.

C. A deliverable is always technical; a success criterion is always financial.

D. A deliverable is an assumption; a success criterion is a constraint.

Correct Answer: A. A deliverable is an output; a success criterion explains how achievement is judged.

Question 7

During an assessment, logs are unavailable for the period under review. What is the most accurate conclusion?

A. No unauthorised activity occurred.

B. The system is fully compliant because no evidence was found.

C. The relevant control or activity could not be verified.

D. The missing logs should be recreated from assumptions.

Correct Answer: C. The relevant control or activity could not be verified.

Question 8

Which RACI role is accountable for accepting a business risk?

A. The person who performs the technical test.

B. The person or authority that owns the risk and decision.

C. Any employee consulted during discovery.

D. The external tool provider.

Correct Answer: B. The person or authority that owns the risk and decision.

Question 9

Why should security testing include an emergency stop procedure?

A. To allow testers to avoid documenting failures.

B. To ensure testing can be halted if material harm or disruption occurs.

C. To permit testing outside the authorised scope.

D. To eliminate the need for monitoring.

Correct Answer: B. To ensure testing can be halted if material harm or disruption occurs.

Question 10

A sponsor requests testing of an asset excluded from the approved charter. What is the best response?

A. Begin testing immediately because the sponsor requested it informally.

B. Refuse all future changes to protect the original schedule.

C. Use a documented change process to assess authority, impact, and revised scope.

D. Remove the asset from the final report without explanation.

Correct Answer: C. Use a documented change process to assess authority, impact, and revised scope.