Most small business owners have the same relationship with their IT provider: things work, occasionally something breaks and gets fixed, an invoice arrives monthly, and security is assumed to be handled somewhere in there. It usually is, at least partly. But "assumed" is doing a lot of work in that sentence, and the gap between what an owner thinks is covered and what's actually covered is where most unpleasant surprises live.
The awkwardness is that the conversation feels hard to start. Nobody wants to sound like they're auditing a supplier they like, and most owners worry they'll get an answer they don't have the vocabulary to evaluate. So the conversation doesn't happen, and both sides carry on assuming.
Before the list, something worth saying plainly: these questions are not a test, and a provider who answers them well is showing you real value for what you pay. Good providers genuinely want clients who ask — informed clients approve sensible work, escalate faster, and are far easier to protect. In our experience the honest answer to most of these is not "we neglected that." It's "nobody ever asked, and it wasn't in scope." Which is exactly the thing worth finding out.
Take these twelve in one meeting, or a few at a time. You don't need to understand the technical detail of any answer. You're listening for three things: whether the answer is specific, whether someone is clearly responsible, and whether it has ever actually been tested.
Knowing what you have
1
What of ours is reachable from the internet right now?
Almost every attack in this series began with something exposed to the internet — a server, a remote access service, a management interface, a device nobody remembered. You cannot protect what nobody has listed. This question establishes whether an inventory exists at all.
Reassuring"Here's the list — these services, these addresses. We review it quarterly and we'd notice something new appearing."
Worth following up"Not much, really." Vagueness here usually means no inventory exists — ask for one in writing.
2
How do we decide what to patch first?
Nobody can patch everything, and severity ratings alone are a poor guide — a great deal of effort gets spent on flaws nobody will ever exploit. The strongest answer prioritises what is confirmed to be under active attack on systems you actually expose.
Reassuring"We prioritise anything confirmed to be actively exploited on internet-facing systems, then work down by risk."
Worth following up"Everything gets patched on the monthly cycle." Fine for routine flaws; too slow for the ones being exploited today.
3
Which of our network devices are still supported by the manufacturer?
Routers, firewalls and similar equipment keep working long after they stop receiving security updates, so nothing prompts a replacement. Unsupported edge equipment carries permanently open, publicly documented weaknesses — and it sits directly on the internet.
Reassuring"All current. This one reaches end of support next year and we've budgeted its replacement."
Worth following up"It's all working fine." Working and supported are different things. Ask for the dates.
Controlling who gets in
4
Which accounts don't have multi-factor authentication — and what kind do we use?
Coverage gaps matter more than the average. One unprotected administrator account undoes a great deal of good work. The second half of the question matters too: codes and push approvals can be relayed by an attacker in real time, while methods bound to a physical device cannot.
Reassuring"Everyone, including service accounts. Admins and finance are on phishing-resistant methods, and we're extending that."
Worth following up"Everyone's covered" without detail. Ask specifically about administrator and shared accounts.
5
If an account is compromised, how do we end the attacker's access — not just change the password?
This is the question most likely to surface something genuinely useful. A successful login issues a token that keeps the session alive, and in many default configurations that token can outlive a password reset. Ending the sessions is a separate action.
Reassuring"Reset the password and revoke active sessions and refresh tokens. It's a documented step and we've done it."
Worth following up"We'd reset the password and force a re-login." Ask directly whether sessions and tokens are revoked too.
6
Would we be alerted if someone created a mailbox rule that deletes or forwards messages?
Intruders hide the alarm — routing security notifications away so the real owner never sees them — and they set up quiet forwarding. Rule creation is one of the most reliable early signals available, and it's a step attackers can't skip.
Reassuring"Yes, alerts on rule creation and on external forwarding, and here's who reviews them."
Worth following up"We could look if you suspected something." Detection after suspicion is not detection. Ask what it takes to enable alerting.
7
What third-party apps and integrations currently have access to our systems?
Every "connect this app" approval grants standing access that persists until revoked — including for tools you trialled once and abandoned. Forgotten integrations are pure risk with no remaining benefit, and they're a well-documented path from one compromised supplier into many customers.
Reassuring"Here's the current list. We review it quarterly and revoke anything unused. Only admins can approve new ones."
Worth following up"Just the ones we set up." Ask for the full list — it's usually longer than anyone expects.
8
What happens to access when someone leaves — including contractors and abandoned tools?
Most businesses have a process for departing employees. Far fewer have one for an ended contract, a completed project, or a service they stopped using. A credential created for a temporary purpose and never revoked is one of the most consistently exploited weaknesses there is.
Reassuring"Documented checklist covering staff, contractors and integrations, triggered when you tell us. We also sweep for dormant accounts."
Worth following up"We disable the account when you let us know." Ask what happens to contractor access and unused services.
Surviving the bad day
9
When did we last actually restore from a backup — and how long did it take?
Note the wording. Not "do we have backups" — everyone says yes. A backup that has never been restored is an assumption, not a safeguard, and the moment you discover otherwise is the worst possible moment. The time it took is the number that tells you how long your business would be down.
Reassuring"We tested a full restore in [month]. It took roughly [x] hours. Backups are isolated so they can't be encrypted alongside live systems."
Worth following up"Backups run nightly and we monitor for failures." That's backup, not recovery. Ask for a test restore this quarter.
10
Is there a written plan for a serious incident, and who decides what?
In the first hours of an incident, the expensive mistakes are decision mistakes — who isolates what, who talks to customers, who calls the insurer, who has authority to take systems offline. A plan converts panic into sequence, and businesses with one recover measurably faster and cheaper.
Reassuring"Yes — here's the document. Named roles, notification steps, and we walk through it annually."
Worth following up"You'd call us and we'd handle it." Reasonable instinct, but ask for it in writing with named decisions.
11
If something serious happens at 2am on a Sunday, who do I call and how fast do you respond?
Attacks are deliberately timed for when nobody is watching — weekends, holidays, overnight. The response time in your agreement is the one that applies, not the one you're imagining. This is a contract question as much as a technical one, and worth confirming before you need it.
Reassuring"This number, monitored out of hours. Our committed response for a security incident is [x], and here's the escalation path."
Worth following up"Email support and we'll pick it up." Fine for a printer. Ask what specifically changes for a security incident.
12
What is not covered by our agreement that you'd recommend we add?
The most valuable question on the list, and the one almost nobody asks. Providers deliver the scope they were engaged for. Most of them can see gaps they've never been asked to fill — and inviting that conversation usually surfaces a short, cheap, high-value list.
Reassuring"Three things we'd suggest, in priority order, with rough costs — and one you can do yourselves for free."
Worth following up"You're all covered." Nobody is fully covered. A provider who can't name a gap may not be looking for them.
How to read the answers
You don't need to evaluate the technical content. Across all twelve, three signals tell you nearly everything.
Specific beats general. "Here's the list, we review it quarterly" is a different quality of answer from "that's all handled." Specificity means someone has actually looked.
Tested beats configured. The gap between "we have backups" and "we restored one in March and it took four hours" is the entire difference between an assumption and a safeguard. The same applies to incident plans and session revocation.
Named beats implied. "Who reviews those alerts?" and "who decides to take systems offline?" should have names attached. Controls without an owner tend to quietly stop working.
If several answers come back vague, the most likely explanation is not negligence — it's scope. Providers are engaged to do particular things at a particular price, and security monitoring frequently wasn't in the original conversation because nobody raised it. That's a fixable commercial discussion, and it's a far better one to have on an ordinary Tuesday than in the middle of an incident.
One practical suggestion: send the questions in advance rather than asking cold. You'll get considered answers instead of off-the-cuff ones, your provider gets to prepare properly, and the meeting becomes a working session rather than a quiz. Ask for the answers in writing — not for accountability, but because in twelve months you'll want to know what changed, and because if you ever make an insurance claim, documented security practices are exactly what gets asked for.
The one you should ask yourself
There's a thirteenth question, and it isn't for your provider. How would we know if any of this stopped being true?
Controls drift. A device gets added and never inventoried. Someone turns off an alert during a noisy week and forgets. A tool gets connected for a project. None of it is anyone's fault, and none of it announces itself. The answers you get today describe a moment, and moments pass.
That's the gap the Veriti Spottr CyberScore is built to close. It gives you an independent, continuously updated view of what's exposed and how your security posture is actually tracking — mapped to a recognised framework, in language you can take straight into your next provider conversation. Not to check up on anyone, but because a shared, objective picture makes that conversation dramatically more productive for both sides. And when your insurer asks you to evidence your posture, you'll have something better than a recollection.
The short version
Twelve questions, one meeting, no technical knowledge required. Listen for specific over general, tested over configured, named over implied. Send them ahead, ask for written answers, and treat the whole thing as a working conversation rather than an inspection.
A good provider will welcome it — informed clients are easier to protect and cheaper to serve. And if the answers reveal gaps, that's the point. Every one of them is far less expensive to close this week than to discover during the incident that finds them for you.
Comments
Post a Comment