Cybersecurity Questions to Ask
For business owners and managers choosing an IT provider, a managed security service or a consultant. Twenty questions covering assessment, out-of-hours response, monitoring, backup restores, access control, patching, staff training and what the contract actually includes.
The questions
Open any question for the note
How would you assess where our security stands today, and what does that assessment involve?
Why ask it
The answer tells you whether they run a real review or a questionnaire. Ask whether they log in to your systems, interview staff and look at your network, or simply tick boxes against a template and hand you a report you could have written yourself.
Which threats do you actually see hitting companies our size?
Why ask it
Providers who work with businesses like yours name mundane things: invoice fraud, a reused password, an old account nobody closed. A pitch built around nation-state actors and advanced persistent threats usually means the answer came from a marketing deck, not their own ticket queue.
If we could only fix three things this year, what would you pick?
Why ask it
Forcing a ranking separates advisers from order-takers. Someone who says everything is critical either has not looked at your situation or is selling the full catalogue. Note whether their three are cheap process changes or the products they happen to resell.
Walk me through the first hour after we call you about a suspected breach.
Why ask it
You are listening for named steps and named people: who isolates the machine, who preserves the logs before they roll over, who decides whether to pull the internet connection. Vague reassurance here means the plan will be invented while you are losing data.
Who picks up the phone at 3am on a Sunday, and what response time do you commit to in writing?
Why ask it
Attacks are timed for when nobody is watching. A verbal promise of round-the-clock cover often means one person with their phone on. Ask for the response time in the contract and ask what happens if they miss it, because a target with no consequence is not a target.
Who reads the monitoring alerts, and what happens to the ones nobody has time for?
Why ask it
Most tools generate far more alerts than any team reviews. The honest answer describes tuning, triage rules and a queue with a limit. If they claim every alert is investigated, ask how many they got last month and how many people were on shift.
When did you last restore a client's data from backup, and how long did it take?
Why ask it
Backups that have never been restored are untested assumptions. A specific recent example, with hours attached, is the strongest thing they can offer. Silence, or a description of the backup schedule instead of a restore, tells you nobody has proved it works.
If ransomware encrypted everything tonight, what would we lose and how long would we be down?
Why ask it
This converts vague protection talk into two numbers you can plan around: how much recent work disappears, and how many days you cannot trade. If they cannot give ranges, they do not know your environment well enough to be defending it.
How do you handle access when someone joins, changes role, or is let go the same day?
Why ask it
Leavers with live accounts are one of the most common ways data walks out. Listen for who initiates the request, how fast it happens outside business hours, and whether role changes actually remove old permissions rather than stacking new ones on top.
Who holds admin rights on our systems, including your staff, and how is that logged?
Why ask it
Your provider will hold keys to everything, which makes them a target too. A good answer covers named individual accounts rather than a shared password, approval before privileged use, and a log you are allowed to read without asking permission.
How do you decide when a patch goes out immediately versus waiting for a test window?
Why ask it
This exposes how they handle the real tension between stability and exposure. You want a stated threshold, a rollback plan and a named person who can authorise an emergency change. Blanket answers in either direction mean the decision is being made ad hoc.
What do you put in place for email, given that is where most of this starts?
Why ask it
Email defence is layered: authentication records, attachment and link handling, rules that catch lookalike sender addresses, and a fast way for staff to report something odd. If the answer stops at the spam filter that came with your mail platform, the layers are missing.
What is your position on staff using personal phones and laptops for work?
Why ask it
Personal devices are where policy meets reality, especially in small teams. Look for a workable position, such as containerised work apps or restricted access, rather than a ban that everyone quietly ignores or a shrug that leaves company data on unmanaged phones.
How often does someone actually look at our cloud configuration, and what do they check?
Why ask it
Cloud breaches are usually misconfiguration, not clever attacks: storage left public, permissions widened for a project and never narrowed. You want a review cadence, a checklist and evidence of drift being caught, not a one-time setup they have not revisited since.
What training do you run for our staff, and how do you tell whether it changed anything?
Why ask it
Annual video training with a quiz at the end changes little. Useful answers mention short repeated sessions, simulated phishing with follow-up for the people who click, and a reporting rate that goes up over time. Ask what they measure, not what they deliver.
Which regulations apply to us, and where are we falling short of them today?
Why ask it
A provider who knows your sector can name the specific obligations and the gaps without a research period. Being told compliance is handled, with no named framework and no gap list, means nobody has mapped your operations against any actual requirement.
What did the last penetration test you ran for a client our size turn up?
Why ask it
Anonymised findings show you the kind of problem they are able to find, and whether they retest after fixes. If everything they describe is a technical exploit and nothing is a process failure, their testing probably stops at the perimeter and never touches your people.
Which security policies will you write for us, and which stay our responsibility?
Why ask it
Policy gaps usually sit in the seam between provider and client. Get the split in writing now, including who owns the incident plan, who approves exceptions, and who tells staff when a rule changes. Assumed ownership tends to mean nobody owns it.
Have you had a client breached while under your care, and what did you do about it?
Why ask it
Any experienced provider has been through an incident. A calm account of what happened, what they changed afterwards and what they told the client is a good sign. A flat claim of a perfect record is either inexperience or a story you are not being told.
What is inside the monthly fee, and what will arrive as a separate invoice?
Why ask it
Incident response hours, out-of-hours work, licences and project time are commonly billed on top. Ask for the last twelve months of a comparable client's total cost against their headline fee, so you find the gap now rather than during an emergency.
Running the vendor conversation
Practical guidance for the conversation itself
How to run the meeting
Bring someone non-technical
Have the person who would actually be affected by a week of downtime in the room: the finance lead, the operations manager. They ask the cost and continuity questions a technical buyer skips, and they notice when an answer avoids the question.
Ask for evidence, not intent
Most claims can be evidenced with a date, a number or a document. Change every question that begins with what they would do into a question about what they last did, then ask when and for whom.
Get commitments into the contract
Response times, restore targets, who is on call and what is billed extra all belong in the agreement. Anything said warmly in a meeting but absent from the paperwork should be treated as not promised.
Talk to a reference who left
Current happy clients are chosen for you. Ask for a client who moved on, or find one yourself. Their account of how the relationship ended tells you more about the provider under pressure than any case study.
Reading the answers
Signs they know your environment
- They name systems and business processes you actually use
- They give ranges and numbers rather than adjectives
- They volunteer the limits of what they can protect
- They separate cheap process fixes from things you have to buy
- They describe a specific recent incident and what it taught them
Signs to slow down
- Every recommendation happens to be a product they resell
- The words used are threat, posture and resilience, with no verbs attached
- Response times are enthusiastic in conversation and absent from the contract
- Compliance is described as handled with no framework named
- They cannot say when a restore was last tested
Common mistakes buyers make
Buying tools instead of operations
Detection software with nobody watching it produces logs, not defence. For every tool proposed, ask who looks at its output, how often, and what they do when it fires.
Treating the assessment as the deliverable
A report full of findings is the start of the work. Agree upfront who fixes what, in what order, by when, and how you will verify each item is actually closed.
Skipping the exit question
Ask how you would get your data, documentation and administrative access back if you left. Providers who make leaving painful tend to be relaxed about service quality once the contract is signed.