1. What type of cyber security work do you actually specialise in?

Be suspicious of anybody who appears to specialise in everything.

Security is too broad for one person to be equally strong at penetration testing, incident response, cloud architecture, compliance, forensics, security operations and board-level risk. If compliance-driven penetration testing specifically is what you need, our roundup of small consulting firms that specialise in compliance and regulation testing narrows the field.

A good consultant should be comfortable explaining where their expertise is strongest and where they would bring in somebody else.

2. Have you done this specific type of work before?

General security experience matters, but relevant experience matters more.

If you need an AWS architecture reviewed, ask about AWS security architecture. If you need ISO 27001, ask about recent ISO 27001 implementations. If you need an application tested, ask about comparable application testing.

You are looking for enough detail to establish that this is familiar territory rather than something they are learning on your engagement.

3. Who will actually do the work?

This is particularly important with larger consultancies.

The person leading the sales meeting may not be the person who appears once the contract is signed.

Ask who will deliver the engagement, their level of experience and who reviews their work.

4. What exactly is in scope?

Many disappointing consulting engagements begin with two parties having different ideas about what was purchased.

Ask for a clear scope covering systems, locations, people, deliverables, assumptions and exclusions.

For technical work, this may include specific networks, applications, cloud accounts or environments. For advisory work, it may define workshops, reviews, documentation and management support.

5. What will I actually receive?

“Cyber security assessment” is not a deliverable.

Will you receive a technical report, executive summary, risk register, architecture, remediation plan, policies, evidence pack, workshop outputs or something else?

Ask to see a sanitised example where appropriate. Good work should still be useful after the consultant has left.

6. How will you prioritise findings?

A list of vulnerabilities is not the same thing as useful risk advice.

A consultant should be able to distinguish between something technically interesting and something that genuinely creates material risk for your organisation.

Ask how findings will be prioritised and how business context changes that prioritisation.

7. How will you work with our existing IT team or provider?

Most SMEs already have somebody operating their technology, whether that is an internal team or managed service provider.

A security consultant should be able to work constructively with them while retaining enough independence to challenge assumptions where necessary.

If the proposed engagement depends on bypassing or antagonising everybody who understands your existing environment, that is rarely a good start.

8. What happens when you find something outside your expertise?

This is one of my favourite questions because the right answer is not “that never happens”.

Good consultants know the boundaries of their expertise.

I would rather work with somebody who says “that requires a specialist” than somebody who improvises confidently in an area they barely understand. AI security is a good example of a specialism worth asking about directly – our piece on what AI security consultants actually offer small businesses explains what to expect from someone who genuinely knows that space.

9. What qualifications or professional credentials are relevant to this engagement?

Qualifications can provide useful evidence, but their relevance depends on the work.

A security management qualification tells you something different from a penetration-testing credential. Cloud certifications may be relevant for architecture work. ISO implementation or audit qualifications may matter for management-system work.

Ask why a particular qualification matters rather than simply counting acronyms.

10. How will we know whether the engagement was successful?

The answer should normally be more meaningful than “we delivered the report”.

Success might mean a defined set of risks understood and treated, vulnerabilities remediated, an architecture approved, certification readiness achieved or an internal team able to operate a process themselves.

Agree that before the work starts.

11. What happens after the engagement?

Ask about remediation questions, retesting, handover and follow-up support.

Some engagements should end cleanly. Others benefit from continued support.

Either is fine, but you should understand the model before you buy it.

12. Are there any commercial conflicts I should understand?

If the consultant recommends a product, managed service or third-party supplier, ask whether they receive commission or have another commercial relationship with that provider.

That does not automatically make the recommendation wrong. You should simply know whether the advice is commercially independent.