Notes · 1 of 8
Your vendor goes down on the day. Who do you call?
Half of what protects an office that doesn't run its own systems is a name and a number written down before you need it.
Last month we told a client to make one demand of a vendor before a deadline: put in writing what happens to our service if your system goes down, and who we call.
That paragraph did more than anything else in the report.
No vulnerability identifier. No version number. No severity score. A phone call and a contract clause.
I've been thinking about it since, because of what it says about who security reporting is written for.
Who the report is for
Almost every security report I've read is written for the person who patches. That isn't a criticism — it's the natural shape of the job. Findings come out of scanners, scanners find software, software gets patched. The report lists what to patch, in the order the scanner thinks is worst.
But that report goes to two readers, and only one of them can patch anything.
The other reader is the person who answers for the organization. The head of a system with forty campuses. The Secretary of State whose counties each run their own election vendor. That person doesn't run the systems. They can't patch. When the report reaches them, it's a list of things they can't do.
So they route it to IT and go back to their day. And the things only they could have done don't get done.
What only the executive can do
Here's what I've noticed, writing for that second reader. Roughly half of what actually reduces risk for an organization that doesn't operate its own systems isn't technical at all. It's one of four things.
Ask. A question with a date in it. "What of yours expires or changes between now and November?" No tool required. The answer is the finding.
Require. In writing, in the contract. An outage plan. A log-retention period with a number of days in it. A remediation deadline. No security tool suggests these, because scanners don't read contracts.
Confirm. Evidence, not status. "We're working on it" and "it's done" are different findings. Ask for the date it was fixed, and check.
Decide. Which forty findings of twelve hundred actually change the week. Whether to take a system offline or leave it up. Whether it matters that most of your counties use the same vendor for the same thing — and what happens to all of them on the same afternoon.
None of those require touching a keyboard. All of them require the authority to demand an answer, the contract to put it in, and the calendar to hold it against — which is exactly what the executive has and the security team doesn't.
If you want the short version to send to a colleague:
Ask (with a date) · Require (in the contract) · Confirm (with evidence) · Decide (what changes this week)
The paragraph again
If the vendor answers the outage question in a day, you have a plan and a phone number before you need one. If they take three weeks, you've learned something too. Either way, it's the difference between an incident and a story.
That's what security looks like from the chair of the person who answers. Not a patch. A paragraph, a phone call, and a date.
If you oversee units or vendors you don't operate, reply with what you're accountable for — a county, a campus, a system — and I'll tell you which of the four I'd start with. Message me instead if you'd rather not say it in public.
Next · 2 of 8 · A risk accepted without your signature