Business security / Decision guide

Before you buy a security review, ask these questions.

By Velocor Security ·

You don't need to become a security specialist to make a better security decision. You need to know what your business depends on, what the review covers, and what you will be able to do with the result.

1. What would interrupt our business?

List the systems that support sales, service delivery, payments, and customer communication. Ask the owner of each system what happens if it becomes unavailable or is accessed by the wrong person.

Ask for: An agreed list of critical systems, their owners, and the business processes they support—not an invented estimate of money you will lose.

2. Do we know what we have online?

Your website may connect to hosting, cloud storage, staff accounts, suppliers, and older systems that have not been reviewed recently. Your attack surface is the set of places through which someone could try to reach your systems or information.

Ask for: The assets included in the review, how ownership is confirmed, and what remains outside the scope.

3. Who can access the important things?

Include staff, contractors, and suppliers when you review who can manage your website, business email, cloud services, and customer information. Check who approves access and who removes it when a role changes.

Ask for: A review of agreed roles and access controls—not a request to email passwords. Approve and securely manage any access required for testing.

4. Are we buying a scan, a test, or an investigation?

A scan helps identify known weaknesses. A hands-on test examines how agreed weaknesses or workflows could be exploited. An investigation examines available evidence of something that may already have happened.

Ask for: Objectives, permitted techniques, exclusions, and the evidence you will receive.

5. Will the findings help us make a decision?

A list of severity labels is not an action plan. A useful finding connects evidence to a possible business consequence, explains uncertainty, and recommends a next step.

Ask for: A sample report showing what was observed, what could be affected, what is not yet known, and who should act.

6. Who fixes the issues, and who checks the fixes?

Testing, implementation, and re-testing may be different pieces of work. Your developer, cloud provider, or internal team may need to make changes.

Ask for: Named owners, implementation boundaries, and the scope and price of fix verification.

7. Who do we call if something happens?

Keep contact details for the people responsible for your website, email, cloud accounts, and business-critical systems. Confirm how to reach them if your usual communication channel is unavailable.

Ask for: Actual coverage hours, response arrangements, and escalation contacts. A contact form is not an incident-response contract.

8. What will this review not tell us?

An assessment is limited by its scope, access, timing, and available evidence. A clean result is not a guarantee against a future breach. An exposed system does not automatically mean data was stolen.

Ask for: An explicit limitations section and a way to revisit findings when your systems or business change.

Take these five items into the first conversation

  1. Your important business systems and their owners.
  2. The concern or business change that prompted the review.
  3. Any relevant deadline, such as a launch or customer assurance request.
  4. Who can approve scope and access.
  5. The decision you want the review to help you make.

Don't include passwords, customer data, or confidential incident evidence in an initial public enquiry. Agree a secure way to share sensitive information.

Explore the next step

Tell us what you need to protect. We will discuss an appropriate scope and proposal before testing begins.

Discuss my business risks