Clinical engineering asks you to renew a blanket exception for 60 unpatchable devices. What do you sign, refuse or change?

## Recognise what is actually being asked A blanket exception is not a security control that has aged; it is an absence of information given a rule number. Sixty devices under one permission means nobody can state what the permission allows in aggregate, which means nobody can say what an intruder landing on the weakest of them receives. The renewal request is therefore an opportunity, and possibly the only leverage you get this year, because renewal is the moment somebody has to sign something. ## What you cannot do You cannot refuse the devices. They are clinical equipment under contracts and, in many cases, regulatory certification; the person on the other side of the table is responsible for keeping them working and outranks the network team in this argument. You also cannot narrow the rules unilaterally at the next maintenance window. Breaking a clinical flow to make a security point ends the relationship that every subsequent improvement depends on, and it turns the next request into an instruction from above your head. ## What to change - **Enumeration.** One record per device: what it is, where it lives, what it may originate and to what, why. Sixty records is tedious and it is the deliverable, because it converts an unknown into a list somebody can argue about. - **Expiry.** Tie each record to something that already recurs - the service contract date, the annual safety inspection - so renewal happens inside a process that exists rather than one you must invent. - **A named owner.** A department is not an owner. A person who can be asked in twelve months why the exception still exists is an owner. - **Evidence.** Bring the flow data. Permits that have carried no traffic in a year, devices that were decommissioned two years ago and still hold rules, and a widest-member rule that turns out to allow far more than anyone believed are the three findings that make the conversation land. They also let you shrink the request without anyone losing an argument. - **Accepted risk, in writing.** Whatever remains is a risk the organisation is running knowingly. Write down what an intruder inherits from it in one paragraph of plain language, and have it accepted by someone with the authority to accept it. Your name is not the right name on that line, and the point is not to shed blame - it is that a risk with a signature gets reviewed and a risk without one does not. ## The counter-argument you will hear, and the answer *Any restriction risks patient safety.* The honest response is that an outage caused by a rule is a risk with a known shape and a rollback, while an intruder inside the clinical segment is a risk with no shape at all - and that both are patient-safety risks. The way to be believed is to have never caused the first one carelessly: change during agreed windows, test the flow with the department present, keep a documented back-out, and be the team that has never surprised them. Credibility here is earned operationally, not rhetorically. ## Move the fix upstream Everything above manages a situation you inherited. The durable change is in procurement. Devices bought next year can carry contract terms: a patch cadence with a defined window, support access that terminates on a broker you control, a documented list of the flows the device requires, and a stated end-of-support date so the exception has a horizon. This is slow, it belongs to a purchasing cycle rather than a project, and it is the difference between a network team that manages exceptions forever and one whose exception list stops growing. Getting one clause into one standard purchase template is a bigger win than any rule you will write this quarter. ## Where a principal earns the seat The technical content of this problem is modest. The judgment is in accepting that you own a control you cannot make good, choosing which battles buy the most reduction for the least relationship cost, being able to say plainly what the organisation is running, and making sure the decision is made by someone empowered to make it rather than defaulted into by a rule nobody dared touch. If the answer is that the exception is renewed largely as it stands, that can be the right outcome - provided it is now enumerated, expiring, owned and signed, which is four improvements over what you were handed.