Ten Questions to Ask Your IT Provider This Week
You do not need to understand SAML, FortiCloud single sign-on, CVE numbering, or Known Exploited Vulnerability obligations to hold your IT provider to account. That is their job. Your job is to ask grown-up questions and expect plain-English answers.
After the Fortinet edge-device authentication bypass over the past winter, where a trusted firewall could be walked straight past and, in some cases, even fully patched devices were compromised, a lot of business owners wanted to ask their provider whether they were affected. Most did not know how to phrase it. So here is the phrasing. Ten questions, in order, with the wording you can copy straight into an email.
A note before the list. If your provider cannot answer one of these, that does not mean sack them on the spot. Good providers exist, and they track advisories, patch edge devices, check logs, and document the outcome. They will not be upset by these questions. They will use them as customer education. The ones who are upset may want to ask why the shoe fitted so quickly. The point of asking is to find out which kind you have.
The Ten Questions
1. Can you give me a list of our edge devices and their firmware versions?
This is the foundation. Edge devices are the things facing the internet: firewalls, VPN appliances, remote-access gateways. If your provider cannot produce this list quickly, they cannot map any future advisory to your actual estate, which means every alert becomes a scavenger hunt.
2. Were any of our devices affected by recent KEV-listed vulnerabilities?
KEV stands for Known Exploited Vulnerabilities, a catalogue maintained by the US cyber security agency. A listing means the flaw is being actively used by attackers right now. You are asking whether any of your kit was on that list and what happened next.
3. Is any management access exposed to the internet, and if so, why?
The administrative interface of a firewall or remote-access device should almost never be reachable from the open internet. If it is, there should be a specific, controlled, logged reason. “It was easier to set up that way” is not a reason. This single question closes one of the most common doors attackers use. We covered the wider version of this in why RDP belongs behind a VPN.
4. Who owns cyber risk inside our business?
This one is not technical at all, and that is the point. Name the person responsible for cyber risk decisions. Not the person who fixes printers. The person who decides what risk is acceptable. If the answer is “the MSP handles it,” that is the start of a follow-up question, not a complete answer.
5. When did we last test a restore from backup?
Not “do we have backups.” Not “does the backup job report success.” When did someone last restore an actual file, open it, and confirm it worked? A backup you have never restored is a hope, not a control. And ask the follow-up: can a single compromised admin account delete those backups? If yes, your recovery plan has a trapdoor.
6. Have you reviewed our administrative accounts recently?
After any edge-device incident, the classic attacker move is to create a new admin account or change an existing one. Ask when admin accounts were last reviewed, whether any unrecognised accounts exist, and whether old shared admin logins have been removed.
7. Do logs exist for the systems we would rely on during an incident?
This is the question that catches people out. If an incident happened, would there be a record of what occurred? Discovering during a breach that the relevant logs were never collected is the worst possible moment to find out. An answer of “we do not keep those logs” is not a technical detail. It is a business risk disclosure.
8. Do we have a simple incident contact list?
Not a hundred-page plan. A single page: who to call, in what order, when something goes wrong. Who can take systems offline. Who can approve emergency action. Who talks to the insurer. Who talks to customers. During a real incident, delay is not admin. Delay is damage.
9. What exactly are you responsible for, and what remains ours?
Scope is everything. If something is not in your provider’s scope, it may not be monitored, patched, backed up, or supported, and you may not know that until it fails. Get it in writing: what they handle, where it is documented, what evidence proves it, and what is explicitly outside scope. Attackers are famously uninterested in your contract boundaries.
10. What happens at 9pm on a Friday when the managed thing starts screaming?
The real test of “fully managed” is not the quiet Tuesday. It is the out-of-hours emergency. Ask what the response process is, who picks up, how fast they act, and what evidence you get afterward. If the honest answer is “we would pick it up Monday,” you have learned something important about what “managed” means in your contract.
How to Use the Answers
You are listening for two things: specifics and ownership. A good answer contains versions, dates, actions, and a named person. A weak answer contains “we are aware,” “we believe,” “it should be fine,” and “the dashboard is green.”
“We are aware” is what people say when they want credit for receiving an email. A real answer sounds like this: we are assessing affected devices, we have identified these versions, we are applying this mitigation, we will check these indicators, and we will report back by this time. That is communication. Everything else is fog.
How to Turn This Into a Competitive Advantage
Asking these questions changes the relationship in your favour.
Providers perform better when customers ask for evidence. This is not cynicism, it is human nature. A client who asks for proof gets prioritised over one who accepts reassurance. Asking well is a way of buying better service at the same price.
Your answers become a sales asset. Once you can answer these ten questions about your own business, you can answer them for a prospective client too. “Here is how we manage edge security and here is who owns it” wins work that vague reassurance loses.
How to Sell This to Your Board
Three points for the people who control the budget.
This is governance in plain English, not a technical project. The ten questions reduce to six the board can ask directly: what do we have, is it affected, what did we do, what did we check, what risk remains, and who owns it. That chain is a board’s job, and it requires no technical knowledge.
It costs almost nothing to ask, and exposes expensive gaps early. A single email of ten questions can reveal a missing backup test, an exposed management interface, or an undocumented scope gap, all of which are far cheaper to fix before an incident than after.
It converts a vague “our MSP handles cyber” into something defensible. If a regulator, insurer, or customer later asks whether reasonable steps were taken, a documented set of answers to these questions is your evidence.
What This Means for Your Business
-
Send the email this week. Copy the ten questions into a message to your IT provider. Give them a reasonable deadline to respond.
-
Write down the answers. The act of recording them creates the documentation a board, insurer, or auditor will later want.
-
Flag every “we are aware” or “should be fine.” Those are not answers. Ask for the specific version, date, action, or owner instead.
-
Fix the cheap things immediately. Exposed management interfaces, missing multi-factor authentication, and stale admin accounts can usually be closed in hours, not days. If your provider quotes you two days to disable internet-facing firewall management, get a second opinion.
-
Schedule the restore test. Put a date in the diary to actually restore from backup and confirm it works. A control you have never tested is a belief, not a defence.
You are not asking your provider to perform magic. You are asking them to explain the risk they are paid to manage. If that annoys someone, good.
Related Posts: