The Scope Creep Engagement
A client engages you to assess the security of a new customer portal before launch in six weeks. During kickoff, the client's CTO asks you to also review the mobile app, the internal HR system, and a legacy database because "you're already in." None of these were in the signed statement of work. The mobile app is built by a third party that has not granted access. The HR system contains employee health data. The launch date is fixed by a marketing campaign. The client's procurement team has not approved additional budget, and your engagement letter caps fees at the original amount. The CTO says the extra work is "just a quick look" and implies future work depends on flexibility.
1. How do you respond to the CTO's request?
Read the worked answer
I separate the relationship from the scope. I thank the CTO and say yes to a conversation about the additional systems, but I do not perform out-of-scope testing under the existing letter. The reasons are concrete: the mobile app's third party has not authorised testing, so testing it could breach the third party's terms and expose the client; the HR system holds special-category data, which changes the legal basis and the handling requirements; and the fee cap means out-of-scope work is unfunded and uninsured. I propose a short scoping session to define the additional systems, then a change order with revised scope, fees, and timeline. The implication about future work is noted but does not change the professional obligation to stay within an authorised, funded scope.
2. The launch date is fixed. How do you prioritise within the original scope?
Read the worked answer
I prioritise by consequence and exposure. The portal is internet-facing and is the launch artefact, so authentication, session management, access control, input handling, and any payment or personal-data flows come first. I use a risk-based test plan that concentrates effort on the highest-likelihood, highest-impact paths rather than uniform coverage. I agree the priority order with the client in writing so that if time runs short, the deferred areas are a documented decision, not an omission. I also flag that a fixed launch date does not reduce the risk of launching with unresolved high findings; the client may choose to launch with accepted risk, but that choice should be explicit and recorded.
3. What do you do about the third-party mobile app and the HR data if the client later approves them?
Read the worked answer
If approved, I require written authorisation from the third party before any testing of the app, and I confirm the rules of engagement cover the app's backend and any shared APIs. For the HR system, I confirm the legal basis for processing special-category data, restrict access to named testers, define data handling and destruction, and ensure the client's privacy office is aware. I issue a revised statement of work and engagement letter covering scope, fees, authorisation, and data handling before work starts. The principle is that approval of budget is necessary but not sufficient; authorisation and data-handling terms must also be in place.