Cybersecurity Questions to Ask
For owners and managers choosing a security vendor: these are the cybersecurity questions to ask an MSSP (a managed security service provider), an IT provider that sells security, or a consultant before you sign. The 61 questions follow the order of the decision: fit and assessment, monitoring, incidents, the controls they would run, your people and policies, then the contract. Breach notification rules, liability clauses and insurance conditions differ by country and by policy, so take those answers to your own lawyer or broker as well.
The questions
Each question, and why to ask it
Fit
Are you a managed security service provider, an IT provider that also sells security, or a consultancy?
Why ask it
The three are different purchases. An MSSP is paid to watch for attacks and act on them, an IT provider mostly keeps things running and adds security tools, and a consultant advises and leaves. Knowing which one is in the room tells you which of their promises are the main business and which are a side line.
How would you assess where our security stands today, and what does that assessment involve?
Why ask it
You are finding out whether they run a real review or send a questionnaire. A real one has them logging in to your systems, talking to staff and looking at the network; the other kind ticks boxes against a template and returns 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.
What would still be our job, or another supplier's, after we sign with you?
Why ask it
Security services have edges: the provider watches laptops but not the phone system, or flags a problem and expects your IT person to fix it. Have them draw the line on paper so the unowned jobs are visible before something falls through one.
How many of your clients are about our size, and how many work in our industry?
Why ask it
A firm built for enterprises with their own security teams may give a forty-person company its most junior analyst and its least flexible contract. A rough count beats a slide of logos, and the size of the smallest client they serve today tells you where you would sit in the queue.
Which parts of the service are delivered by your own employees, and which are passed to a partner?
Why ask it
Plenty of providers resell another company's monitoring centre under their own name. That can work well, but you should know whose analysts read your alerts, which country they sit in, and whether your contract gives you any standing with that third party.
Which of the security tools we already pay for would you keep, and which would you ask us to replace?
Why ask it
Some providers work with what you have and others only support their own stack. Swapping out working tools adds cost and a risky changeover period, so ask for the reason behind each replacement and whether it is technical or simply what their analysts are trained on.
What happens between signing and the day you are actually watching our systems, and how long does that take?
Why ask it
Onboarding is when agents get installed, log sources connected and normal behaviour learned, and until it finishes you are less protected than the invoice suggests. Ask for a week-by-week plan and for what they need from your staff to keep it on schedule.
Monitoring
Which of our systems would you monitor, and which would you have no view of?
Why ask it
Coverage is rarely complete. Laptops and servers are usually in; cloud email, the accounting system, the firewall and staff phones may not be. A provider who lists the blind spots unprompted is telling you where an intruder could sit unnoticed, which is worth more than a claim of full visibility.
Who reads the monitoring alerts, and what happens to the ones nobody has time for?
Why ask it
Monitoring tools can raise far more alerts than a team has hours to read. 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.
Is your security operations centre staffed through the night by analysts at their desks, or covered by someone on call?
Why ask it
Both arrangements get sold as 24/7. Staffed means someone is looking at a screen at 2am; on call means a pager wakes a person who then has to log in. The follow-up is how many analysts work the night shift and how many clients each one covers.
When an analyst spots something serious overnight, what are they allowed to do without reaching us first?
Why ask it
Some services only notify, which leaves the decision with whoever answers your phone in the dark. Others will isolate a laptop or disable an account on their own authority. Agree the list of pre-approved actions in advance, including the systems they must never switch off without a call.
How long does it take from an alert firing to a person looking at it, and can we see your real figures for last quarter?
Why ask it
A target in a brochure and a measured average are different things. The figures worth seeing are the ones existing clients are sent, slowest cases included. Check too whether the clock starts when the alert fires or only when a ticket is opened.
Which detection tools would you run for us, and whose name would the licences be in?
Why ask it
If the software is licensed in the provider's name, leaving them can mean losing your endpoint protection the same day. Find out whether the tools would be yours, theirs or rented through them, and what a changeover would involve.
Where are our logs stored, how long are they kept, and can we search them ourselves?
Why ask it
Logs are the record of what happened, and an investigation can only reach back as far as they are kept. You need three facts: the number of days, the country the data sits in, and whether you get your own login. Some regulations and insurance policies set a minimum retention period, so check which apply to you.
How will we hear from you about an alert: a phone call, a ticket or a portal entry, and what decides which?
Why ask it
A critical finding emailed to a shared inbox on a Friday night has not really been reported. Get the severity levels, the channel for each, and the names of the people whose mobile numbers they will hold for the top tier.
What does the monthly report contain, and may we see one you sent to another client with the names removed?
Why ask it
A report that counts blocked threats in the millions looks impressive and tells you nothing. The useful kind lists what was investigated, what turned out to be real, what was changed as a result and what they are still waiting on you to fix.
Do your analysts go looking for intruders who have not tripped an alert, or only work the alerts the tools raise?
Why ask it
Threat hunting appears in a lot of sales material. What makes it real is hours: how many a month go on it for a client your size, what the last hunt was looking for, and whether you would hear the result even when nothing was found.
How would you know if your monitoring of us had quietly stopped working?
Why ask it
Agents get uninstalled, a log feed breaks after an update, a new office opens without anyone telling the provider. Silence then looks the same as safety. A source going quiet should raise its own alarm, and they should be able to show you a health check of every connection.
Incidents
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.
If we spot the problem before you do, what number do we call, and how soon does someone who can act ring back?
Why ask it
Not every incident starts with their alert: a member of staff notices a strange login, or a customer queries an invoice you never sent. A general support line that opens a ticket for the next working day is the wrong door. Write down the emergency number and its callback time, then try it once before you need it.
Is hands-on incident response part of the service, or do you hand us to another firm once a breach is confirmed?
Why ask it
Detection and response are often sold separately. If the provider stops at telling you there is a problem, you need a second relationship arranged in advance, because finding and contracting a response firm in the middle of an attack costs days.
If ransomware encrypted everything tonight, what would we lose and how long would we be down?
Why ask it
This turns vague protection talk into two numbers you can plan around: how much recent work disappears, and how many days you cannot trade. Nobody can give them before seeing your systems, so find out what they would need to look at to offer ranges, and by when.
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.
Could someone who got into our network also reach the backups and delete them?
Why ask it
An intruder who plans to extort a business has every reason to wreck the backups before encrypting anything else. Two things settle it: whether any copy is offline or cannot be altered, and whether the backup system uses different logins from the network it protects.
If our data were taken, what could you give us quickly to help work out who has to be told?
Why ask it
Duties to notify customers, a regulator or an insurer depend on your country, your sector and your contracts, and some carry short deadlines. A security provider is not your lawyer, so what you need from them is evidence: which records were touched, and when. Ask your own counsel how the rules work where you operate.
Have you worked alongside a cyber insurer's response team, and will you read our policy before we sign?
Why ask it
Some policies name the firms you may use and require early notice, and conditions differ from one insurer to the next. Hand over the wording so their plan and the insurer's do not pull in opposite directions at the worst moment, and take anything it leaves unclear to your broker.
Is a rehearsal of a breach, with our managers in the room, part of the service or an extra?
Why ask it
A tabletop exercise shows up the gaps no document does: the provider's emergency number is stored only on the server that is down, or the one person who can approve a shutdown is on a flight. Settle how often they would run one and who writes up what it found.
Have you had a client breached while under your care, and what did you do about it?
Why ask it
After enough years and enough clients, an incident on their watch is close to certain. 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.
If your own company were breached, how soon would we hear, and what happens to your access to our systems in the meantime?
Why ask it
A provider's remote tools and stored passwords reach into every client at once, so a break-in on their side is your incident too. The answer worth having is a notice period written into the contract and a way to cut their access from your end without their help.
What do we receive in writing once an incident is closed?
Why ask it
You will need an account of events for your board, your insurer and perhaps a customer. A past example with the details removed shows what you would get: a timeline, the way in, what was touched, and the changes recommended so it does not happen twice.
Controls
How do you find the devices and accounts on our network that nobody told you about?
Why ask it
Nobody can protect a laptop that is missing from the list. The detail to get is how the inventory is built at the start, how often it is refreshed, and what happened the last time a client turned out to have a server no one remembered.
How do you handle access when someone joins, changes role, or is let go the same day?
Why ask it
A leaver whose account still works is a door left open with nobody watching it. 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.
Which of our logins would you put behind multi-factor authentication first, and what would you do about the ones that cannot support it?
Why ask it
Email, remote access and anything with administrator rights usually head the list. The second half of the question matters more: older systems that cannot take a second factor need some other fence around them, and you want to hear what that fence is.
How do you decide when a patch goes out immediately versus waiting for a test window?
Why ask it
Patching at once can break the software a business runs on, and waiting leaves a known hole open. The sign of a method is a stated threshold, a rollback plan and a named person who can authorise an emergency change. Always-immediately and always-wait are both signs that nobody is weighing it.
How often would you scan us for known weaknesses, and who fixes what the scan finds?
Why ask it
A scan produces a list, and lists are easy to ignore. Pin down whether the provider applies the fixes, hands them to your IT person or simply reports them, and how old the oldest unfixed item is allowed to get.
What do you do about the old systems we cannot upgrade or replace yet?
Why ask it
Think of the machine that runs the label printer, or the software its maker no longer updates. Being told to replace it is not a plan. The plan is to wall it off from everything else and watch it more closely in the meantime.
What would you put in place to protect our email, beyond the filter that came with it?
Why ask it
Email defence is layered: sender authentication records, attachment and link handling, rules that catch lookalike addresses, and a fast way for staff to report something odd. An answer that names one product and stops has left most of those layers out.
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. A workable position keeps work apps in a managed, separate part of the phone or limits what a personal laptop can open. The two answers to distrust are a ban everyone quietly ignores and 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 trouble often comes from a setting, not a clever attack: storage left public, permissions widened for a project and never narrowed. Expect a review cadence, a checklist and an example of drift being caught, not a one-time setup nobody has revisited since.
How do you check the suppliers and outside software that connect into our systems?
Why ask it
Your payroll bureau, your website developer and the remote support tool an old contractor left installed all have a way in. Ask whether third-party access is listed, reviewed and switched off when a relationship ends, or whether that sits outside their scope.
Do you run penetration tests yourselves or bring in an outside tester, and what did the last one for a client our size turn up?
Why ask it
Testing defences you built yourself is marking your own homework, so an outside tester now and then is worth raising. Anonymised findings show the kind of problem they can find and whether they retest after fixes. If every finding is a technical exploit and none is a process failure, the testing probably stopped at the perimeter and never touched your people.
People and policy
What training do you run for our staff, and how do you tell whether it changed anything?
Why ask it
A once-a-year video with a quiz at the end rarely changes what people do. 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.
When one of our staff clicks a bad link, what should they do next, and how do you keep them willing to own up?
Why ask it
The minutes after a click matter, and people who expect a telling-off stay quiet. Look for one easy way to report, a quick reply from a human, and a provider who treats the reporter as the person who helped.
Which regulations and standards have you helped clients in our sector meet, and where do you think we fall short?
Why ask it
What applies to you depends on your country, your sector and the contracts you have signed, so treat their list as a starting point and confirm it with a lawyer or your regulator. A provider who knows the sector names specific frameworks and specific gaps. A promise that compliance is handled, with nothing named, means nobody has mapped your business against a requirement.
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.
When a customer or an insurer sends us a security questionnaire, how much of it could you answer and stand behind?
Why ask it
Larger customers and insurers often want written evidence of controls. A provider who runs those controls should be able to supply reports and screenshots for their part, and say plainly which answers only you can give.
How would you work with the IT person or IT company we already have, and who has the last word on a change?
Why ask it
Security wants things locked and IT wants things working, and the two will disagree over a blocked program or a forced restart. Agree who can overrule whom, how changes are requested and how the pair of them talk during an incident, ideally with your IT contact sitting in on this meeting.
Who on our side will you need decisions from, and how much of their time should we set aside?
Why ask it
Outsourcing security does not remove the need for an owner inside the business. Someone has to approve changes, chase staff and take the night call. Ask for an honest estimate in hours per month so the job lands on a named person and not on whoever is nearest.
How often would you sit down with our management, and what would you bring to that meeting?
Why ask it
A quarterly review should cover what changed in your risk, what was fixed, what is overdue and where they would spend next. If the only regular contact is an invoice, small problems pile up unmentioned until one of them is large.
Contract
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. A list of every extra with its rate, plus what a typical year comes to for a client like you, shows the gap now and not in the middle of an emergency.
How is the service priced: per user, per device or by the volume of logs, and what would make the bill rise?
Why ask it
Pricing by log volume can jump when you add a system or switch on more detailed logging, which quietly rewards you for watching less. Have them price your current setup, then the same business with ten more staff and one more office.
Which of the commitments you have described are written into the agreement as measurable targets?
Why ask it
Go through the proposal with a pen and mark every figure: time to respond, time to contain, report dates, restore times. Then find each one in the contract, and ask what remedy applies to a miss, whether a credit, a right to leave or nothing at all.
What independent audit or certification covers your own security, and may we read the report?
Why ask it
They will hold access to everything you run, and their own word for how they guard it is not evidence. An outside audit report says more than a badge on a website. Read which services and locations it covers, because the audited part of a company is sometimes not the part you are buying.
If a breach traces back to something you missed, what does the contract say about your liability?
Why ask it
Many agreements cap what the provider owes at some multiple of the fees, which may be far below your loss. How such clauses work varies by country, so this is one for your lawyer and your insurer to read, but ask the provider to show you the clause and the insurance behind it.
How long is the term, how does it renew, and how could we leave early if the service falls short?
Why ask it
Multi-year terms that renew automatically are common in managed security. Find the notice window and put it in a calendar, and ask whether repeated missed targets give you a way out without paying for the remaining months.
If we leave, what do you hand back: the logs, the documentation, the detection rules, the administrator accounts?
Why ask it
The time to raise this is while they still want your signature. The answer you are after names a format, a timescale and a price for each item, and confirms that their own access to your systems is removed and shown to be removed.
May we speak to a client who has been through a real incident with you?
Why ask it
References picked by a sales team mostly describe quiet months. One conversation with a business that called at the worst moment tells you how fast the provider moved, how clearly they kept people informed and whether the bill afterwards was a surprise.
Could we begin with a limited scope or a short first term before committing to the full contract?
Why ask it
Three months on your most exposed systems lets you judge the alerts, the reports and the people before you are locked in. Some providers decline because their setup costs come early, and how they explain that is informative too.
Running the vendor conversation
Practical guidance for the conversation itself
How to run the meeting
Take the groups in order
Fit and Monitoring belong in a first meeting, because they show whether you are talking to a managed security service provider with analysts on shift or an IT firm with a security add-on. Bring Incidents and Controls to a second session with one of their technical leads present, People and policy once you are down to two candidates, and Contract when the agreement is on the table.
Send every provider on the shortlist the same one-page brief
Headcount, sites, the cloud services you rely on, the tools you already own, and any regulation or insurance condition you know applies. Proposals written against one brief can be compared line by line. Proposals written after separate sales calls cannot, because each provider will have assumed a different scope.
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, and what it would cost. A provider you can leave in a month has to keep earning the renewal; one you cannot leave does not.