13. The Server Nobody Owns, but Nobody Can Turn Off

It survived three reorganizations, two acquisitions and the departure of everyone who knew its original purpose. It doesn’t appear in the current inventory, but someone believes it might have something to do with payroll. Its documentation consists of a yellow sticky note reading “DO NOT TOUCH,” which has acquired the authority of a court order. Every proposed retirement ends with a decision to investigate later. Meanwhile, the machine keeps consuming electricity and accumulating risk. The server is practically an employee at this point, except it has successfully avoided every performance review. Assigning an owner and mapping its dependencies would help, but that requires someone to accept responsibility for what the investigation might uncover.

12. “It’s Just a Quick Change Before the Weekend”

Few phrases carry more menace than this one, especially at 4:47 on a Friday afternoon. The adjustment is simple, the requester has done something similar before, and everyone would like it finished before Monday. Testing feels excessive for such a small change. Unfortunately, the production environment has no obligation to respect anyone’s dinner reservations. A configuration edit can touch dependencies that took years to accumulate and minutes to disrupt. Before long, the person who requested the change is texting from a restaurant while the operations team reconstructs what happened. A tested rollback plan deserves at least as much attention as the confidence of whoever says this will only take a minute.

11. The Backup That Has Never Met a Restore Test

The dashboard is green. The job completed. An email confirms success. Everyone sleeps comfortably until someone needs the data back and discovers the recovery process requires credentials, infrastructure or instructions that are unavailable. A backup can exist while the ability to restore business operations remains largely theoretical. CISA recommends regularly testing backups for good reason: the emergency is a terrible time to discover what the recovery plan leaves out. Recovery also has a clock attached. Getting a system back eventually offers limited comfort when the business needed it six hours ago. Ask when the last successful restore happened, what it included and how long it took. Watch how quickly the meeting gets quiet.

CISA backup guidance

10. The Cloud Bill That Feeds After Midnight

Someone spun up a test environment. Someone else needed extra capacity. A development project ended, although its infrastructure apparently didn’t receive the announcement. Now add AI workloads capable of generating more calls, more processing and more charges while everyone admires the productivity gains. Each expense has a plausible explanation; collectively, they produce an invoice that finance treats as evidence of a crime. The FinOps Foundation’s 2026 research identifies AI cost and value management as a major priority. Understanding what useful work costs takes ownership, measurement and the occasional willingness to shut something down. Otherwise, the cloud becomes a very accommodating restaurant where everyone orders and nobody asks for the check.

State of FinOps 2026

9. The Employee Who Brought Their Own AI Department

An employee finds a service that summarizes contracts beautifully. Within an afternoon, it has processed documents that IT would have spent weeks evaluating how to protect. The employee is pleased with the results and genuinely surprised that anyone has concerns. You can understand the appeal, particularly when getting an approved tool requires enough paperwork to qualify as a separate job. But the organization still needs to understand where its information goes, who can access it and what the service does with it. Blanket prohibitions won’t make the demand disappear. Give people a practical, approved way to use AI, or expect to learn about their alternatives after the documents have left the building.

8. The AI Agent With Administrator Privileges

The demonstration went beautifully, and then someone connected the agent to real systems. Broad permissions made deployment easier, so it received broad permissions. It can now change records, invoke tools and take actions at a speed that makes human supervision an optimistic description. OWASP identifies excessive functionality, permissions and autonomy as causes of damaging AI actions. That should sound familiar to anyone who has spent years trying to reduce unnecessary access. We have found a new reason to revisit an old discipline. Before celebrating what the agent can accomplish, establish where its authority ends, which actions require approval and how to stop it. Frankenstein’s creator could also have spent more time on operational controls.

OWASP excessive agency

7. The Call From the CEO That Isn’t the CEO

Imagine receiving an urgent call that sounds like your CEO, references a real project and asks you to make an exception. The request is confidential, time-sensitive and apparently too important for the usual process. That combination should earn additional scrutiny, although workplace culture can push employees in the opposite direction. If people have been trained never to question senior management, an impersonator has a useful advantage before the conversation begins. Verification through a separate, trusted channel needs to be routine and supported from the top. Executives should welcome an employee checking an unusual request. Being mildly inconvenienced beats discovering that your authority has become someone else’s attack tool.

6. The Tiny Dependency Holding Up the Entire Company

The application is critical, the business investment substantial and the architecture presentation impressive. Several layers down, an obscure component helps keep the whole thing functioning. Who maintains it? How are updates reviewed? What happens if it is compromised or abandoned? Those questions can produce an uncomfortable silence in an organization that considers the application thoroughly managed. Software reuse makes modern development possible, but responsibility travels with the components we choose. Open source deserves neither automatic suspicion nor automatic exemption from scrutiny. Commercial software needs examination, too. Somewhere between downloading a dependency and building a business around it, someone should understand what the organization is relying on.

5. The Patch You’re Afraid to Install on the System You’re Afraid to Leave Running

Security wants the vulnerability addressed immediately. Operations warns that the update could break an application the business cannot afford to lose. Both teams have legitimate concerns, and neither created this predicament during the current meeting. The replacement project was postponed, testing capacity was cut and maintenance kept losing to more visible priorities. Now years of deferred decisions have arrived as one urgent argument. Telling everyone to “patch faster” does little to resolve the underlying fragility. Leadership needs to fund the conditions that make timely patching possible, including testing, supported software and recovery preparation. Otherwise, the organization keeps handing its staff a choice between an exposed system and a potentially broken one.

4. The Vendor Renewal That Arrives With a Shovel

The renewal arrives, and apparently your vendor has been doing some creative work with packaging. A feature you depend on belongs to another tier. The old discount has disappeared. Moving would require a migration, retraining and time you don’t have. The salesperson remains wonderfully upbeat throughout this discussion. Every platform decision creates some switching costs, but organizations can be remarkably incurious about those costs until negotiations begin. By then, the leverage may be sitting entirely across the table. Understand your alternatives while you still have time to exercise them. An exit strategy assembled two weeks before renewal is more likely to become a justification for paying.

3. The Outage That Reveals Your Redundancy Was Mostly Decorative

There are two environments, multiple availability zones and enough arrows on the architecture diagram to suggest extraordinary resilience. Then a shared dependency fails, and everything stops together. Perhaps both paths need the same identity service, network connection or management system. The team would consult the architecture presentation, but it lives behind the login service that is currently unavailable. Redundancy needs to survive an examination of how systems actually fail, including the services required to recover them. A second copy offers limited protection when both copies depend on the same vulnerable foundation. Exercise the recovery plan while the consequences are manageable. Attractive diagrams are inexpensive compared with discovering their omissions during an outage.

2. The Last Person Who Understands the System Just Gave Notice

Everyone knew this employee was important. They solved the strange failures, remembered the hidden dependencies and could explain why an apparently unnecessary process had to run before midnight. Documentation was always something they would finish when the emergencies stopped. Management celebrated their dedication and allowed the dependency to deepen. Now there are two weeks to extract years of knowledge. This is the kind of organizational dependence I keep coming back to when discussing the indispensability trap. A person’s heroics can conceal a fragile operating model for years. Give people time to document, teach and improve the systems they support. They deserve vacations and career choices without the company treating their absence as a disaster scenario.

1. “We’re Doing More With Less. AI Will Handle the Rest.”

Here is the nightmare that can make every other entry worse. The budget books productivity gains before anyone has demonstrated them. Positions disappear while the remaining staff inherits additional systems and instructions to use AI more effectively. AI absolutely can help, but deploying it responsibly requires integration, testing, security, exception handling and people capable of judging its work. Those responsibilities need resources. Cut first and assume the benefits will follow, and the organization may lose the expertise necessary to achieve them. The same smaller team is now responsible for the zombie server, the untested restore, the mounting invoice and the agent with too much access. Management has approved the savings. Someone else gets the pager.