01Agree the boundary of the review
Identify the systems, accounts, devices and business processes in scope. Confirm who owns them and can authorise the work, including any external services. Define what testing is permitted, when it can occur and how a potentially disruptive issue will be escalated.
A review of configuration and business controls is not automatically a penetration test. The depth of testing, method, exclusions and required practitioner expertise should be explicit in the proposal. Do not assume an engagement covers every system or provides a certification.
02Gather evidence proportionate to the risk
Useful starting material includes the system inventory, access arrangements, update process, backup coverage and incident contacts. Evidence should be collected through approved access routes and handled according to its sensitivity. Do not send credentials or confidential system exports through the public enquiry form.
Questions should follow the business’s important work. For example, identify what happens if email access is lost or a shared device is unavailable, and which dependencies are needed to recover. Technical settings and operational ownership need to be considered together.
03Turn findings into priorities
A finding should state what was observed, which systems are affected, why it matters and what a suitable next step could be. Separate confirmed observations from untested assumptions. Priorities should reflect the potential business impact and the evidence available rather than a long undifferentiated list.
Agree who owns each corrective action and how completion will be verified. A report alone does not implement the control or establish that residual risk is acceptable to the business.
