A school district's rules of engagement forbid intentional denial-of-service during the assessment. A tester finds a path that would likely crash a critical student portal. What is the correct action?
Select an answer to reveal the explanation.
Short Explanation
If the RoE says no DoS, that is a hard stop — not a hint. You can still warn about the risk with evidence that stays inside the lines. Crashing a student portal for a cooler screenshot is how engagements go sideways.
Full Explanation
If school-district RoE forbids intentional denial-of-service and a tester finds a likely crash path against a critical student portal, the correct action is to honor that boundary: stop short of the availability-breaking proof, document the suspected risk with evidence that stays within allowed techniques, and notify the designated contact per the engagement agreement. Maximizing severity by crashing the portal violates written RoE and can harm students and staff who depend on the service. Industry checklists do not override a signed municipal agreement. Verbal overrides from an intern on the help desk lack authority and create unsafe informal expansion of scope. Exam caveat: 'likely crash' hypotheses should be framed as residual risk when exploitation is barred, not silently omitted from the district report. Operational check: capture request/response evidence up to the safe point, mark the finding as suspected DoS risk under RoE constraint, page the district security contact immediately if critical, and record that intentional crash testing was not performed. In municipal operations, record the decision and residual risk in the engagement notes so future civic responders understand which control or boundary was honored and which failure modes the rejected approaches would create for public services. Re-check the same control at the next maintenance window or retest cycle.