Every time a public agency accepts a cybersecurity risk, it makes that decision for people who weren't in the room.
On the other side of the screen, a parent is uploading school records. A business owner is checking a permit application. Neither can negotiate the agency's security practices or take the same paperwork to a different municipality. They provide what's required and trust that someone has thought carefully about what happens next.
For those of us who build, fund, or run these services, that someone is us.
Of course, the decisions rarely arrive on such human terms. They arrive as a maintenance request, a budget line, or an exception needed to get a project over the finish line. Sometimes accepting risks is reasonable. The difficulty is keeping sight of who else has to live with that choice.
Where the work goes when systems fail
Nearly 4,000 hours of assistance, in less than a week.
That's what Port of Seattle staff and volunteers had provided to customers by September 1 following the August 2024 ransomware attack. According to the Port's official incident updates, the attack disrupted baggage services, check-in kiosks, ticketing, and passenger displays.
Travel remained safe, but keeping the airport functioning required extraordinary human effort.
Behind that number is a second workload: all the effort needed to keep a service moving when its usual systems are unavailable. Travelers still needed directions. Bags still needed to reach aircraft. Recovery depended on that effort, too.
In a security budget discussion, follow that workload to the people who would inherit it. The employees answering extra calls would have other work waiting. Account for what they would have to put aside, and how long the agency could sustain that arrangement.
We can usually see the price of a software upgrade in a proposal. The time a resident spends chasing an answer, or a clerk spends reconstructing a submission, rarely arrives with a price tag.
But someone is paying for it.
When a vulnerability becomes an emergency
The October 2026 PHP2Shell vulnerabilities illustrate how quickly a technical issue can become an operational problem.
Researchers disclosed two critical vulnerabilities in PHP, the software underlying millions of websites and applications. Rated 9.2 out of 10 in severity, the flaws could allow attackers to execute malicious code on vulnerable servers without logging in. Exploitation attempts were detected before public disclosure, prompting urgent security updates.
For a public agency, responding means identifying vulnerable applications, coordinating with hosting providers, installing patches, and testing that everything still works. If a system cannot be patched immediately, temporarily taking it offline may be necessary. Every step consumes time and resources. And none of it was in the original project plan.
PHP2Shell reminds us that cybersecurity isn't something we can always address during the next scheduled maintenance window.
Sometimes the vulnerability arrives on Tuesday, and the response needs to happen on Wednesday. Organizations need to know what technology they're running, who's responsible for maintaining it, and how quickly they can act.
When "temporary" becomes permanent
Suppose a supplier needs elevated access to connect a new application. Launch is close, the team is stretched, and the access is supposed to end when the integration is finished. Then the schedule slips. Everyone agrees to leave it in place a little longer.
Six months later, the project is closed and the permissions are still there.
Somewhere in that handoff, a decision stopped being temporary without anyone quite deciding to make it permanent. The original approval may have been sensible. Leaving it open indefinitely is a different decision, with different consequences.
Before renewing an exception like that, ask for the consequence in language a program owner can use. Which records could the supplier change? Which service could be interrupted? “Elevated access” describes a permission; those answers describe what is at stake.
Then give the exception an owner, a defined scope, and an end date. Where the system supports it, configure the access to expire automatically and require a deliberate renewal. Busy people should have a system that helps them finish what they agreed to do.
NIST's Cybersecurity Framework 2.0 places responsibilities, oversight, and dependencies within its Govern function. Reviewing open exceptions gives leaders a chance to establish whether the original need still exists and fund a safer way to meet it.
Recovery is complete when people can get back to work
After an outage, seeing the application come back online is a relief. For the people depending on it, the next question is practical: can they pick up where they left off?
At Tactile, we help people find travel information on Philadelphia International Airport’s public website and move applications through Philadelphia Water Department’s stormwater plan review system. In the Water Department workflow, architectural drawings and inspection photos support the review process. Getting the work done depends on those pieces fitting together.
Consider a hypothetical permitting service recovering from an outage. The technical team brings the database back online and confirms that the application runs. Then a reviewer opens a submission and discovers that the supporting drawing is missing. Meanwhile, an applicant who uploaded documents during the interruption has no way to tell whether they arrived.
From either side of that exchange, there’s still work to recover.
Restoring infrastructure and data is technical recovery. Operational recovery follows through until people can use that information reliably and continue their work. In the gap between them, staff may be reconstructing submissions, answering calls, and asking applicants to repeat steps they thought were finished.
Bring those staff into the recovery exercise. Have a reviewer follow a submission through the restored service, open its attachments, and complete the next step. Check what arrived during the interruption. Include the applicant’s view, too: can they see that their documents were received and understand what happens next?
Better to discover a missing drawing together during an exercise than while someone is waiting on the phone. Before declaring the service recovered, let the people who use it show that they can move forward.
Three questions worth asking
At your next planning discussion, bring the conversation back to the people depending on the service. Whether you oversee operations, manage a budget, or lead a technical team, these three questions can help make the decisions clearer:
- Who carries the cost? Identify the people, information, and services affected. Include the staff who would absorb extra work, the people left waiting, and what an interruption could cost them in time, money, or trust.
- Who owns the decision? Every significant exception to normal security rules needs an accountable owner, clear limits, and a date for reconsideration. Someone should be able to explain why it remains necessary and what would allow it to end.
- What proves we can recover? Ask for evidence that staff can complete real tasks using the correct information and give reliable answers to people waiting on the service. A successful backup is a starting point; the recovery exercise should show what people can actually do with it.
- Choose one open exception or recovery plan this week and walk through those questions with its owner. If the answers are vague, you’ve found a useful place to start.
With those answers in hand, spending decisions become more concrete. You can weigh the cost of preparation against the disruption people would have to manage, and decide what deserves attention first. There’s more room for that judgment before an outage, when the phones are quiet and the team has time to plan.
Back at the screen, that parent has finished uploading the documents. The business owner has an application number and something else to get on with. Neither will know about the vulnerability your team patched or the recovery gap caught during an exercise.
For them, success means closing the browser and getting on with their day.
Our work should make that ordinary moment dependable.
Sources
· Port of Seattle — Official Cyberattack Archive
· Port of Seattle — Employees Pitched In During the SEA Cyberattack