Essay
The risks nobody decided to accept
On security, service continuity and the decisions leaders need to own.
The difficult part of reducing technology exposure isn't always identifying it. It's getting a decision about what happens next.
In September 2026, ABC News reported Australian Signals Directorate Director-General Abigail Bradshaw urging entities to prioritise security over availability. Her practical advice was to reduce attack surfaces by isolating systems that do not need internet connectivity.
That advice is sound. But organisations rarely start from a clean slate. Technology introduced under one set of circumstances may still be operating years later, after its owners, dependencies and the risks around it have changed.
The question is whether anyone has revisited the decisions that continue to shape that exposure - and who has the authority to change them.
When the original justification expires
Consider legacy infrastructure that continues to support an important service. Replacing it would require investment; isolating it may affect how the service operates. The technical team can understand its limitations and keep it running without necessarily having the authority to decide its future.
In technology delivery, I've learned that understanding a problem and establishing who can make a decision about it are different tasks. Ownership may be clear for day-to-day operations yet unclear when a change involves funding, risk acceptance or service disruption.
Continuing to operate the infrastructure might be the right choice. But that choice needs an owner who can explain why it still makes sense.
Availability is an obligation, not an automatic justification
For services people rely on, taking something offline carries consequences of its own. Service availability matters, sometimes most when people are facing difficult circumstances.
But keeping a service available is not the same as keeping every component publicly accessible. Restricting administrative access or isolating unnecessary internet-facing infrastructure can protect continuity rather than compromise it.
At other times, the trade-off is real. A security improvement might disrupt an essential function, or a safer replacement may be beyond the organisation's current resources. Those constraints deserve serious consideration. They do not remove the need for a conscious decision.
Accepted risk or inherited exposure?
Risk acceptance can be legitimate. Organisations cannot remediate everything immediately, and sometimes the alternatives carry greater operational consequences.
But acceptance should describe an informed, authorised decision - not become an administrative destination for unresolved work. It should also identify what would cause that decision to be reconsidered: a new threat, a change in service criticality or a viable remediation option. A review date alone is not enough.
When remediation is repeatedly deferred, the organisation is choosing to tolerate that exposure for longer, whether or not it records the choice. Leadership needs to recognise and own the consequences.
Make the decision possible
Shared responsibility is necessary here, but it must not become diluted accountability.
Technology teams need to explain what is exposed, which dependencies matter and what could realistically change. Cyber security leaders need to assess the risk, challenge assumptions and identify proportionate controls. Service owners need to explain the consequences for the people and operations that depend on the system.
When a material trade-off requires funding, changes to service expectations or acceptance beyond delegated authority, executive leadership has to own that choice.
Not every exposed service needs an executive meeting. Decisions should be made as close to the work as the authority and consequences allow. But escalating a material risk without clear options is unlikely to produce a useful decision, just as presenting credible options without securing ownership is unlikely to produce action.
This is where technology leadership earns its place: connecting technical evidence to operational consequences, making alternatives understandable and getting the decision into the hands of someone who can act.
Sometimes the answer will still be to defer remediation. If so, what is being protected by that choice? Who has accepted the additional exposure? What would trigger a different decision, and is the organisation willing to provide the resources when that point arrives?
Those questions are more useful than treating the risk register as evidence that the underlying condition is governed.
Would we choose it again?
An organisation doesn't need to reconsider every technical decision constantly. It does need to recognise when the reasons for accepting material exposure have changed.
If the same exposure were presented for approval today, would the organisation accept it? Who could answer - and act on that answer?
Risk appetite is not only what an organisation says it is prepared to accept. It is whether the exposure it continues to carry still reflects decisions it would willingly make again.