Nobody gets into security because they love patching. The work that keeps you safe is dull, repetitive, and easy to put off. Which is exactly why most companies put it off, and exactly why they get hurt.
I ran technology and security for a national retailer for two decades, and now I ghostwrite books for security leaders. The most important lesson I can pass on is unglamorous: the boring work is the job. The companies that skip it get hurt by attacks that were entirely preventable, and it’s inexcusable, because the fix was sitting on somebody’s to-do list the whole time.
Why does patching matter so much?
Patching matters. Unpatched systems are how a lot of attacks succeed, because the hole was known, the fix existed, and nobody applied it. The attacker didn’t need to discover anything. They just walked through a door the vendor had already told you to lock. A huge share of real breaches trace back to a patch that was available for months and never installed.
So you patch. But patching is annoying, because patches force reboots, and the reboot never comes at a good time. The way Microsoft works, it’ll reboot your machine right in the middle of whatever you’re doing. It doesn’t care that you have work open or that it’s the middle of your busiest day.
What I always did was turn off auto-patching.
Then patch manually, on a schedule, after I had a chance to test the patch in a staging environment first. Auto-patching sounds responsible, but it hands control of your timing and your stability to a vendor who doesn’t know your environment. Manual patching on a tested schedule keeps you both current and in control.
Never patch blind. Test it in staging first. I learned that when a patch blue-screened every machine we had and we spent days rolling it back.Share on X
That staging step isn’t optional, and I learned why the hard way. Back in the Windows NT days, we pushed a patch that caused blue screens on every system. Every one. The machines wouldn’t boot. We had to roll all of it back and clean up the mess across the entire environment, by hand, while the business waited. It was days of work to undo something we’d applied in an afternoon. After that, we didn’t patch anything until we’d proven it safe on a test box first.
The lesson cost us dearly and I never forgot it. A patch is a change. Every change can break something. So you test it where breaking is cheap, before you apply it where breaking is expensive.
Auto-patching sounds responsible, but it hands control of your timing and your stability to a vendor who doesn’t know your environment.
I still run my own computer that way. I’ve set Windows Update on my machine to install once a quarter. Every time it ran on its own schedule, it brought new problems, new features I didn’t want, and new instability. One update changed all my files to read only. I had to hunt through settings to find what it had switched and switch it back.
Now I update when I’m ready to deal with it.
My system’s stable, and I’ve got plenty of other security in place, so a quarter between updates doesn’t worry me.
How does access review limit insider damage?
The other boring habit is reviewing who can reach what, and pulling access the moment it’s no longer needed. When someone changes roles, their old access should go away that day, not six months later when somebody finally notices.
Someone joins, gets access to do their job. They move to a new team, get new access, but nobody removes the old. They take on a project, get more access, project ends, access stays.
Year after year, person after person, the company accumulates a sprawl of permissions that nobody is tracking, where half the people can reach things they have no reason to touch. Each one is a key that an attacker, or a disgruntled employee, can use.
This is the control that limits insider damage, and it’s the one that most directly addresses the threat I describe in what actually gets attacked first, where the insider turns out to be the most common and most missed vector. It’s also the control that rots unnoticed, because nobody owns it and nothing breaks visibly when you skip it. The patching failure announces itself. The access-review failure stays invisible, right up until someone leaves angry and discovers their login still works.
Regularly reviewing access and ripping out what’s no longer needed is tedious and thankless, and it’s one of the highest-value things you can do. A manager who approves new access in a day and takes six months to remove the old is leaving keys lying around for whoever wants them, and I’d hold that manager to account the same way I would for a server room door propped open.
My take
Do the dull work, because it’s the work that saves you. Patch on a test box before production, since every patch is a change and changes break things. Review access and pull what nobody needs anymore. Test your backups before the night you need them. The one time everything went wrong for us, backups pulled us through, barely, and barely is too close. Nobody sells a dashboard for any of this. Do it anyway.
Why are backups the most important boring work?
Then there are backups, the most boring thing in all of technology, and the thing that once saved my entire operation. Let me tell you how, because it’s the best argument for boring work I have.
Back in the earlier days we backed up in layers, because one backup isn’t really a backup. Every night we copied our whole system, all our files, to a duplicate set of disks. That was the first layer, fast to make and fast to restore from. From there, we copied it over the network, over T3 lines, to a remote site, so that even if our building burned down we could recover somewhere else entirely.
And on top of all that, we ran a tape backup every night, magnetic tape, the final fallback you could put on a shelf and carry out the door.
Three layers. Disk, remote, tape. Local for speed, remote for disaster, tape for last resort. You’d think that was bulletproof. That’s the point of layering. The odds of all of them failing at once are vanishingly small. Then we had the worst night of my career, and learned that vanishingly small isn’t the same as zero.
A power outage spiked a surge into the system and physically destroyed hardware. Our main disks failed. The disk-to-disk backup failed in the same event, because it was on the same power.
And the T3 lines to the remote site had already been down for several days before the outage, so there was no remote copy waiting either. A triple failure, all at once, the thing layering is supposed to make impossible, and it happened anyway.
We had three layers of backup. A power surge took out all three the same night. The one thing that saved us was a brilliant DBA and a week-old tape.Share on X
So we went to the tapes. Our last line of defense, the one that survives when everything electronic dies. The tapes were physically snapped. Broken. The one backup that was supposed to be unkillable had failed in the most basic physical way. We had to go back about a week to find tape we could read.
What saved us was a person. My Oracle DBA, Elvis Niba, was among the best database people I’ve ever worked with. He was originally from Cameroon, and his mother named him after Elvis Presley.
When everything else failed, Elvis walked the data, rolling it forward from partial backups and transaction logs, reconstructing what had happened in the days the readable backup didn’t cover. He rebuilt the database almost from nothing, piecing it together from fragments that a lesser engineer would have called unrecoverable.
We recovered virtually all of it. By rights we should have lost a week of business. Because of him, we lost almost nothing.
I tell that story whenever someone tells me backups are boring.
They are. They’re also the difference between a bad week and a dead company. And notice the lesson hiding inside it: even three layers of backup can fail, so the final safeguard isn’t a system at all, it’s a person who deeply understands the data and can rebuild it when every automated safety net tears. That’s why ransomware, which I describe in what gets attacked first, is a backup problem.
The defense against your files being encrypted is a clean copy you can restore, the same boring discipline that saved us that night.
What does the boring security routine look like?
The routine is patching on a schedule after testing, pulling access the day a role changes, and backing up in layers while testing that the backups restore, because a backup you’ve never tested is just a hope with a label on it. None of it is exciting and none of it shows up in a vendor demo, yet it’s the work that keeps a company alive. I have no sympathy for leaders who starve it to fund something shinier.
The companies that get this right are the ones where the boring work is simply how the team works, not a project, not a heroic push before an audit, just the daily grind that someone owns and does. The audit, when it comes, is easy, because everything is already the way it should be. I get into that distinction in what eight PCI audits taught me about real security versus checkbox security.
AI hasn’t changed any of this. It’s made it urgent. Ross Haleliuk, who writes the Venture in Security newsletter, quoted a friend who said that twenty years ago we had two problems, patches and passwords, and today we still have the same two problems. What AI changes is the speed. An attacker with AI tools can find the unpatched server you were going to get to someday, and find it this week.
For years, plenty of companies bet that nobody skilled enough would bother with them. That bet is gone. Every attacker now works with the tools that used to belong to the best ones.
So do the boring list, and do it on time.
When I work with a security leader on a book, this is often the most valuable material, because it’s the part they lived and no framework teaches. The war story about the night everything failed is worth more to a reader than any list of best practices. I get impatient with security books that skip those stories, because the judgment underneath them is the one thing a reader can’t pick up from a vendor white paper.
Frequently Asked Questions
Don’t let systems auto-patch, because patches force reboots whenever the vendor decides and a bad patch can take down everything. Test each patch in a staging environment first, then apply it manually on a schedule once it’s proven safe.
Because they’re the only reliable recovery when everything else fails, from ransomware to hardware death. Back up in layers, local disk, a remote site, and a separate medium, and test that the backups restore. I once had all three layers fail in one night from a power surge, and only a brilliant DBA rebuilding from partial data saved us.
It’s the practice of regularly checking who can reach what, and removing access the moment it’s no longer needed. Access quietly accumulates as people change roles and old permissions are never revoked, leaving keys everywhere. When someone changes roles or leaves, their old access should be pulled that day. It’s the quiet control that limits insider damage.
Because attacks succeed through the gaps the boring work would have closed. The unpatched server, the login that was never revoked, the backup nobody tested. None of it is exciting, none of it shows up in a demo, and all of it keeps a company alive. The companies that do it well treat it as daily operation.
Always. A backup you’ve never restored from is just a hope with a label on it. Tapes snap, copies corrupt, and restores fail in ways you only discover when you try. Test that your backups restore cleanly, regularly, so the day you need them isn’t the day you find out they were broken.
Yes. I ghostwrite books for CISOs, security founders, and technical executives who want their real experience on the page. The war stories and hard-won judgment, not just the best-practice lists, make a security book worth reading. You can see how I work on the cybersecurity ghostwriting page.
Backups decide whether a bad day becomes a disaster. Family Cybersecurity opens with a friend who lost thirty years of photos to ransomware, and the book shows how to keep that from happening in your house.
