Start with the service, not a scanner
Before a digital service launches, the team needs a shared picture of what it does and what failure would mean. List the people who use it, the information it holds, and the actions that could cause harm. A public information page and a payment service face different risks. The review should reflect that difference.
Draw a simple map of the browser, application, database, external services, and administrative tools. Mark where information crosses a boundary and where one system trusts another. This map makes it easier to identify assumptions that otherwise remain hidden in individual developers’ heads.
Check access at the point of action
Authentication establishes who someone is; authorisation determines what they may do. Test both. A user should not be able to read another account’s records simply by changing an identifier. Administrative actions should require deliberate, restricted access, and departed staff should lose access promptly.
Review account recovery, session expiry, and service accounts as well as normal sign-in. A strong login screen does little if a forgotten integration retains broad permissions or a recovery process exposes an account.
Follow sensitive information
Trace information from collection through logs, exports, backups, and deletion. Collect only what the service needs. Check whether error messages or diagnostic logs expose secrets or personal records. Keep credentials out of source code and separate development settings from production.
Dependencies deserve the same attention. Record which external services receive data, what permissions they need, and how the application behaves when they are unavailable. An inventory is useful only if someone owns keeping it current.
Make recovery part of the launch decision
A backup is not evidence of recoverability until restoration has been tested. Agree who responds to an incident, how the team will disable a compromised integration, and which communications channel remains available if the main service fails.
End the review with a short decision record: findings, severity, evidence, owner, and due date. Resolve launch-blocking issues and explicitly record residual risks. Security review should produce decisions the team can act on, rather than an unprioritised list that nobody owns.