You don't need to understand firewalls to know whether your company is handling security well, any more than you need to be an accountant to review the books. What you need is a set of questions, a feel for what good answers sound like, and the discipline to ask for evidence instead of reassurance. This guide gives you all three.

It's written for owners, CEOs and board members of small and mid-sized organizations who rely on an IT manager, an MSP or a security provider — and want to review the work without pretending to be technicians.

Start with the business, not the technology

Every useful security review starts with two plain-English questions: what do we most need to protect, and what would hurt us most? Customer data, the ability to take payment, the production line, your reputation with regulators — the answers are business answers, and you already know them.

Write them down before anyone opens a dashboard. Everything else in the review is just checking whether the security program actually covers those things. When the conversation drifts into acronyms, pull it back: "Which of our crown jewels does that protect?"

The ten questions to ask

Ask these of whoever runs your IT or security, internal or outsourced. None of them require technical knowledge to ask — or to judge the answer.

  1. What are the five things we can't afford to lose, leak or have shut down?
  2. If we were breached right now, how would we find out — and how quickly?
  3. Who owns security day to day? I want a name, not a department.
  4. When did we last restore from backup to prove it works, and how long did it take?
  5. Is multi-factor authentication enforced on email, banking and every admin account?
  6. When a critical vulnerability is announced, how fast do we fix it?
  7. Which vendors can reach our data or systems, and when did we last check them?
  8. What incidents or near-misses did we have this year, and what changed because of them?
  9. What would our cyber insurance require us to prove if we claimed tomorrow?
  10. What's the one security thing that keeps you up at night?

That last question is the most important on the list. The answer tells you what your team already knows but hasn't been resourced to fix.

What good answers sound like

You can judge an answer without knowing the technology. Good answers share four traits:

  • Specifics over adjectives. "Critical patches are applied within 14 days; last quarter we averaged 9" beats "we take patching seriously."
  • Names and dates. "Maria owns it; we tested the restore on August 12" beats "the team handles that."
  • Tested, not assumed. "We ran the incident plan in a tabletop in March and here's what broke" beats "we have a plan."
  • Honest gaps. "Here's what we're not doing yet and why" is the sound of a program you can trust. A program with no admitted gaps is a program with no admitted visibility.

If the answers only make sense to a technician, ask for the one-page version. Translating technical status into business language is their job, not yours.

Red flags worth digging into

Any of these deserves a follow-up:

  • Nobody's name comes up. Security owned by "the team" or "the vendor" is owned by no one.
  • Answers are products, not outcomes. "We bought a leading EDR" doesn't say who watches it or what happened because of it.
  • Backups exist but have never been restored. Untested backups are a hope, not a control.
  • The same finding appears in consecutive reviews. Once is a gap; twice is a decision someone made without telling you.
  • The compliance certificate is the whole answer. Passing an audit isn't the same as being secure — we covered why in Compliance Isn't Security.
  • The provider's reports are never questioned. If your MSP or MSSP's monthly report gets a nod and nothing else, you're paying for a subscription, not a service.

Evidence you can ask for

Reassurance is free; evidence takes work. Ask to see a few of these — you can judge them at a glance:

  • The asset inventory: one list of what's owned and who owns each item
  • MFA coverage: percentage of accounts enforced, not "rolled out"
  • Patching or vulnerability metrics: average days to fix criticals, oldest open critical
  • The record of the last backup restore test, with dates
  • The incident log for the year, including near-misses
  • Training and phishing-simulation completion numbers
  • The vendor list with each vendor's last review date
  • Minutes from the last security review — if there are none, this year's job is to start

Missing evidence is an answer too. It usually means the activity isn't happening.

What to do with the answers

End the review the same way every time, with three lists:

  • Keep funding: what's working and should continue untouched
  • Fix: specific gaps, each with a named owner and a date — quick wins inside 90 days
  • Get help: gaps your team has admitted it can't close alone

That third list is where outside help earns its keep. An independent risk assessment calibrates whether your internal answers match reality, and a virtual CISO can run this whole review with you and own the follow-through. Both exist because the pattern in this article is common: the business wants oversight, and the technical team wants air cover to ask for resources.

Related reading: The Annual Cybersecurity Review: What to Actually Look At and MSP vs. In-House IT: Should You Outsource or Hire Your Own Staff?

Frequently asked questions

Do I need to understand the technology to review security?

No. You're reviewing management, not configuring firewalls. If answers only make sense to a technician, that's a communication problem on their side, not a knowledge problem on yours.

How often should a non-technical leader review security?

One deep review a year plus a short quarterly check-in on the same few numbers: patching speed, backup tests, incidents, training completion. Consistency matters more than depth at the quarterly cadence.

Should we bring in an outside reviewer?

Periodically, yes. People reviewing their own work grade gently. An independent assessment every year or two, even a short one, calibrates what your internal answers really mean.

Key takeaways

  • You review the management of security, not the technology — that requires questions, not certifications.
  • Anchor everything to what the business can't afford to lose.
  • Good answers have specifics, names, dates and admitted gaps; adjectives and products are not answers.
  • Ask for evidence you can judge at a glance: inventories, restore tests, incident logs, review minutes.
  • End with three lists: keep funding, fix with owners and dates, and get outside help.