How to Prepare a System for a Security Review

A security review is a structured examination of a system's defences, carried out at a specific point in time by someone outside the day-to-day development or operations team. For most UK businesses that commission or build web applications, portals and internal tools, the review arrives as a external requirement rather than a voluntary exercise. A prospective enterprise customer may insist on one before signing a contract. A regulator or industry body may mandate it. An insurer may request it before offering cyber cover. In some cases, the business itself initiates a review after a change in architecture, a migration, or simply because the last one is now several years old.

Decision summary: Provide an accurate architecture, asset and access inventory so reviewers can test the real system and track remediation.

It helps to distinguish a security review from ongoing security practices. Monitoring, patching, access control and logging are continuous activities. A review, by contrast, is a bounded engagement with a defined scope, a set of credentials, a timeframe and a report at the end. Understanding that distinction shapes how you prepare: you are not being asked to prove that the system is perfectly secure at all times, but that it can withstand focused scrutiny under controlled conditions.

Reviews take several forms. A penetration test targets specific endpoints and attempts to exploit weaknesses. An architecture review examines design decisions, data flows and integration points without necessarily running attacks. A compliance assessment checks whether the system meets a particular standard or set of controls. A customer-driven security questionnaire asks for documented evidence of policies, procedures and technical measures. Each type demands slightly different preparation, and the first practical step is to confirm exactly which kind of review you are facing and what its scope covers.

A proportionate security baseline

For “How to Prepare a System for a Security Review”, security controls should be selected from a documented risk assessment and tested in the complete service. No single product, certificate or test removes the need for secure design, access control, monitoring, patching, incident response and recoverable backups.

Establish the scope and rules of engagement

Before any reviewer receives access, agree in writing what is in scope and what is not. For a web application, this typically means listing the URLs or subdomains included, the user roles that may be tested, the integrations that fall within the boundary and any endpoints explicitly excluded. If the system connects to a third-party service via an API, clarify whether that API is in scope or whether the review stops at your system's boundary. Without this agreement, you risk receiving findings about components you do not control or, conversely, gaps where everyone assumed someone else was checking.

Agree on rules of engagement: whether the test can be run during business hours, whether the reviewer should avoid certain actions that might trigger rate limits or lock accounts, and how the reviewer will handle any sensitive data they encounter during testing. These details belong in a brief document signed before work begins.

Gather and organise documentation

Reviewers work faster and produce more useful findings when they can read before they probe. Prepare an architecture overview that shows the major components: the application itself, the database layer, file storage, caching, message queues and any external integrations. Document the data flows: what personal or sensitive data enters the system, where it is stored, how it moves between components and where it leaves the system. Include a list of user roles and a summary of what each role can access and do.

If you have existing documentation on how authentication works, how sessions are managed, how backups are stored and how logging is configured, gather it into one location. You do not need to produce polished marketing material; rough internal diagrams and notes are often more useful because they reflect how the system actually runs rather than how it was once designed.

Provision access to the right environment

Decide early whether the review will run against a staging environment or production. Staging is usually preferable because it avoids any risk of disrupting live users or generating misleading alerts. However, staging must genuinely mirror production in terms of configuration, code version and data structure. A staging environment that is several releases behind or uses different security headers will produce findings that do not apply to the live system, wasting everyone's time.

If production access is unavoidable, agree on constraints: read-only actions where possible, avoidance of bulk data extraction, and clear communication windows so your operations team can distinguish test activity from genuine incidents. Provide the reviewer with test accounts that cover each relevant role, and ensure those accounts have the exact permissions a real user in that role would have. Over-privileged test accounts mask real access-control problems.

Assign a single point of contact

The reviewer will have questions during the engagement. Designate one person within your business to receive and coordinate those questions, even if the answers come from different team members. This prevents contradictory information reaching the reviewer and gives you a clear record of what was discussed. The point of contact should also be responsible for receiving the findings, distributing them internally and tracking the response.

Mistakes that undermine the review

One of the most common errors is treating the review as a pass-or-fail exam and attempting to make the system look better than it is. Disabling features that you know are weak, tightening permissions just for the test period, or deploying last-minute patches without testing them can introduce new problems and makes the results unreliable. The purpose of the review is to find out where the real risks lie so you can address them. Hiding issues defeats that purpose and can create liability if a problem later surfaces that the review should have caught.

Another frequent mistake is failing to plan for what happens after the report arrives. A security review that produces a list of findings but no process for prioritising, assigning and tracking remediation is only half complete. Before the review begins, agree internally how findings will be triaged, who will own each category of remediation work and what the timeline for re-testing will be.

Limitations to communicate clearly

A security review is a snapshot. It assesses the system as it exists during the engagement window. A change deployed the following week can introduce a new vulnerability that the review would not have detected. Make sure stakeholders understand this limitation so they do not treat the report as a permanent guarantee.

Scope boundaries also create limitations. If the review excludes a particular integration because it is owned by a third party, the report will not cover risks arising from that integration. If the review covers only the web application and not the underlying infrastructure, server-level misconfigurations may remain unexamined. These boundaries are normal and necessary, but they should be documented and acknowledged by the business, not buried in an appendix.

Pre-review checks to run yourself

Before inviting an external reviewer, run a set of basic checks to avoid paying for findings you could have identified in an afternoon. Verify that all user accounts with elevated privileges are still needed and belong to people who are still employed or engaged. Confirm that software dependencies are up to date, or at least that any known unpatched vulnerabilities are documented and accepted as risks. Check that logging is active for authentication events, permission changes and data exports, and that those logs are actually being retained for the period you believe they are. Test that backups exist, are recent and can be restored to a separate environment without errors.

Review the access controls on your file storage, database and any admin interfaces that are exposed beyond your internal network. Ensure that default credentials have been changed on every component, including services that are not directly user-facing. These are not substitutes for a professional review, but resolving them beforehand allows the reviewer to focus on deeper, less obvious issues.

Questions to put to the reviewer before engagement

• What methodology will you follow, and can you share a sample report structure so we understand the level of detail?
• Will findings include a severity rating, and how is that rating determined?
• Do you provide re-testing of remediated findings, and is that included in the initial fee?
• How will you handle any personal data you encounter during testing, and can you confirm this in writing?
• What information do you need from us before day one, and what is the deadline for providing it?

Asking these questions before the engagement starts clarifies expectations on both sides and reduces the chance of disputes over scope, deliverables or handling of sensitive information. Security and privacy arrangements in particular should be confirmed with current specialist advice, as requirements change and the specifics of your system may create obligations that a general engagement letter does not cover.

Security evidence to require

• Define the protected asset, likely abuse case and evidence that the control still works in production.
• Define the assets, threats, trust boundaries and business impact before selecting controls.
• Give named owners responsibility for patching, access reviews, logging, incident response and recovery testing.
• Prefer phishing-resistant authentication where practical and document recovery paths with the same care as login.

Primary guidance checked for this edition

Sources for “How to Prepare a System for a Security Review” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• NCSC: Identity and access management
• NCSC: Vulnerability management
• NCSC: Planning cyber-incident response