Free course · Module 1 · Lesson 4 of 4
Deadlines, and saying no on purpose
What you'll decide
How fast each level of problem gets fixed, what counts as fixed, and how your business says "not yet" to a fix without letting it drift into "never".
You now have an order. Order without deadlines drifts, though. "We'll get to it" turns into six months, and the payroll laptop is still waiting. This lesson puts a clock on each level, and gives you an honest way to handle the problems that can't be fixed in time.
Plain-English terms
Deadline (or SLA). How long you allow from the moment a problem is confirmed and assigned to the moment it's fixed. SLA stands for service level agreement; it's what your IT provider may call it.
Compensating control. A barrier that makes a problem harder to use without fixing it. For example, blocking internet access to a device, or putting it on its own network.
Exception. A written, signed decision to leave a problem unfixed past its deadline, for a stated reason, until a stated date.
The deadlines
These are the same deadlines the VM Program Kit's policy uses. They were written for companies with security teams, and they still work for a 12-person office, because an attacker doesn't give a small business extra time.
- P1Box 1: exploited and reachable from the internet24 hours
- P1Box 2 on a top system72 hours
- P2Rest of Box 2, and Box 3 on a top system30 days
- P3Rest of Box 3, and Box 4 on a top system90 days
- P4Rest of Box 4, or accepted in writing180 days
Bar length on a log scale, so hours and months fit on one line.
The clock starts when someone confirms the problem is real and it's assigned to a person, not when a scanner first spots it. Otherwise every deadline is half gone before anyone looks.
The Kit's model sets levels with a scoring formula instead of this table, so an edge case can land one level apart. For a small business's list, the table gets you to the right order.
When your IT provider can't do 24 hours
If your IT provider comes in once a week, a 24-hour deadline can look impossible. Keep the number anyway. Don't loosen it. Treat the gap as a contract question:
- Does your agreement say how fast they'll respond to an emergency, including evenings and weekends?
- Did you give them permission to make emergency fixes without waiting for you? (That was Part 2 of your file.)
- If not, what would it cost to add?
A Box 1 problem is rare. When one happens, the business needs someone who will act the same day. Better to find out now whether that's true.
What counts as fixed
Any of these closes the problem:
Update it
Install the vendor's fix.
Change the setting
New password, feature switched off, admin access removed.
Take it off the internet
If it's no longer reachable, it no longer passes the gate. Switching off the remote-access feature until a fix arrives counts.
Remove or replace it
An app nobody uses is best closed by deleting it.
A compensating control is different. It doesn't fix anything, it just makes the problem harder to use. It can move something down one level. It can never move something out of Box 1. If it's being exploited and reachable, it gets fixed or taken off the internet.
Saying no on purpose
Sometimes you can't fix something in time. The vendor stopped making updates. The old machine runs the one program you need. The fix breaks something important.
That's normal. What's not fine is letting it sit there with nobody having decided anything. An unfixed problem with no decision behind it is still a risk you're taking. You just didn't choose it.
An exception turns that into a decision. It has five parts:
- What isn't being fixed.
- Why it can't be fixed by the deadline.
- What we're doing instead to make it safer in the meantime.
- Who signed off. For P1 and P2, the owner. For P3 and P4, the person who owns that system is enough.
- When it expires. Pick a real date. When it arrives, the problem is overdue again unless someone renews the exception on purpose.
Take the payroll laptop from Lesson 2, the one that can't be updated anymore. It's Box 2 on a top system, so P1, 72 hours. You can't patch it in 72 hours, because no patch exists. The exception might read: "Payroll laptop can't be updated. Payroll moves to the office manager's PC this week. Until then the old laptop is used only for payroll and nothing else. Signed: owner. Expires: 14 days." That's a decision you can defend to an insurer, a customer, or yourself.
Scenario
The card terminal nobody will update
Your card terminal is six years old. The manufacturer stopped releasing updates last year. Your IT provider reports a flaw in it scored 8.0. It isn't on the KEV list, there are no reports of attacks, and it isn't reachable from the internet. It's on the same network as the office PCs. Card payments are on your top systems list, so this is P3, 90 days, and it can't be patched.
What do you do?
Pick the one you would choose. It opens with the reasoning, then you can compare the rest.
AKeep using it. It works fine.
It probably will keep working fine, which is exactly how an unfixable problem becomes permanent. Nobody decided to accept this risk. It just never came up again. If the flaw ever joins the KEV list, you'll be starting from zero.
BReplace it today, whatever it costs.
It's a P3, not a fire. Emergency spending on a problem nobody is exploiting uses money and attention that Box 1 and Box 2 may need. Replacing it is the right fix. Doing it today at any price isn't.
CWrite an exception, and start the replacement.
What: the old card terminal can't be updated. Why: the manufacturer stopped. Instead: the IT provider moves it to its own network, away from the office PCs, and you call your card processor about a supported replacement. Most processors can supply one, and they have their own rules about unsupported terminals. Signed: the manager who owns card payments, or you. Expires: 60 days, by which time the new one should be in. If the flaw joins the KEV list before then, the exception is off and it's handled as the new facts demand.
DUnplug it until the new one arrives.
Now you can't take cards, which is exactly the harm your top systems list exists to prevent. The fix shouldn't hurt the business more than the risk does. That would be different if this were Box 1.
Keep it alive
Your file isn't finished for good the day you fill it in. Look at it twice a year, the same rhythm as Step 18 of the Security Starter. New people, new apps, and new vendors change the top systems list. Check that no exception has passed its date without anyone renewing it.
Remember
- Every level has a clock, starting when a problem is confirmed and assigned: 24 hours for Box 1, up to 180 days for routine work.
- If your IT provider can't meet 24 hours, that's a contract question, not a reason to loosen the number.
- A problem you can't fix gets a written exception with a reason, a stand-in, a signature and an end date, so it never just sits there unfixed.
Build your file
Parts 4 and 5: Deadlines and exceptions
Part 4. The deadlines are already in your file. Fill in who gets told when a deadline is missed, and who agreed to the deadlines and when. If your IT provider can't meet 24 hours today, write down what you're doing about it.
Part 5. If you already know of something that can't be fixed, like an old machine or an unsupported device, write it in the exceptions table now with all five parts. Delete the grey example row.
Example: "Missed deadlines go to: owner, same day. 24-hour coverage: IT agreement updated to include weekend emergency response, June 1." Exception row: "Card terminal · no updates from maker · own network, replacement ordered · signed: Dana (manager) · expires Aug 15."
Last, fill in Review again on at the top, six months out, and put the same date in your calendar. Part 6, the review log, is where you'll note what changed each time.
That's the file finished. Share it with your IT provider (a view-only link to named people is better than an attachment), so they know the rules they're working to.
Where this goes next
Step 13 of the Security Starter is a one-page "if it goes wrong" plan: who to call, in what order, when something passes your gate. In the VM Program Kit, Part 4 is the policy's severity and SLA table, and Part 5 grows into the Exception Register, which flips an expired exception back into a missed deadline automatically.