A security review can clarify controls, access and responsibilities. A penetration test investigates agreed technical targets through authorised testing. The right starting point depends on the question you need answered.

In this guide

Ask what assurance you actually need

Make a review specific enough to act on

When targeted testing may be appropriate

Keep everyday controls in view

Prepare a clear initial brief

Ask what assurance you actually need

If you do not know which accounts, websites and systems the business depends on, start by establishing that picture. A review can examine agreed settings, access, backups and working practices, then identify what needs attention.

A penetration test is a distinct technical engagement with specified targets and methods. It can investigate whether weaknesses can be exploited within the agreed scope. It does not replace routine maintenance or prove that every system is secure.

The NCSC’s penetration-testing guidance explains the importance of commissioning and scoping tests and the limits of what a test can establish.

Make a review specific enough to act on

Agree which systems and controls are included. A business might start with its website, business email, administrator accounts and recovery arrangements. Record what is excluded, what evidence is available and which provider owns each responsibility.

Ask the findings to explain the business consequence, supporting evidence and recommended next step. Separate confirmed issues from assumptions and areas that could not be assessed. A long list of technical terms is not a prioritised plan.

Implementation is another decision. Agree which changes will be made, how they will be verified and who will maintain them after the review.

When targeted testing may be appropriate

You may need to investigate a defined application, verify remediation or obtain evidence against an agreed assurance requirement. Explain that requirement before buying a test: different engagements answer different questions.

Confirm ownership and written authorisation, target systems, permitted techniques, timing, contacts and reporting. Include relevant third-party permissions. The proposal should explain limitations and how findings or unexpected issues will be handled.

Ask who will perform the work and what relevant experience they have. Plan how findings will be prioritised and retested; receiving a report is not the same as resolving the issues.

Keep everyday controls in view

A test is a snapshot of agreed work, while access, software and business processes keep changing. Routine controls still need owners and evidence that they work.

As a baseline, NIST’s small-business guidance recommends MFA, software updates, protected and tested backups, and staff awareness. Those practices support ongoing risk management rather than a one-off certificate of safety.

For your own business, record who reviews accounts, applies updates, checks backups and handles an urgent concern. Review those responsibilities when staff or providers change.

Prepare a clear initial brief

Describe the systems involved, the business concern and the decision the work needs to support. Mention relevant deadlines, existing providers and any assurance requirement. Do not send passwords, customer records or sensitive incident evidence in an initial contact form.

If you suspect an active incident, treat that as a separate response discussion. A scheduled review or website enquiry does not establish emergency availability or an agreed incident-response service.

Before work begins, agree scope, access, fees, deliverables and next steps. No review or penetration test can guarantee that an incident will never happen.

Make the next step practical

Bring your own situation, constraints and questions. We can help define a focused starting point.