But the business …

There is a paradox at the heart of modern software development.

Business decisions drive revenue. That's expected. But increasingly, the business is also allowed to directly drive software development decisions - often without meaningful technical or security guardrails. The result? Products are shipped at ever-increasing speed and velocity - while risk builds in the background. Customers are imperiled. The company itself is imperiled. And everyone pretends this is normal.

Picture this - a company releases a new toy for children. The toy records their voices so parents can listen while they’re away on business trips - or just stuck at work for the day. It's comforting. It's emotional. It sells.

The toys are connected to the Internet so parents can hear their children talking to their stuffed animals.

Only the company moved so fast that no security assessment was ever performed.

Scary, right? You can already picture what's going to happen.

Except this isn't hypothetical. It already happened.

The company was CloudPets. They never recovered.

Every day, companies play roulette with our data. Software is released with little to no security oversight, all in the name of not blocking the business. Security reviews are framed as friction. Architecture reviews are seen as delays. Engineers are told to "just make it work" and "we'll fix it later."

Later rarely comes.

Companies today are under immense internal and external pressure to deliver "more AI." Investors expect it. Marketing demands it. Executives want to say they have it. And once again, speed wins over discipline.

But we already have plenty of examples showing why AI systems should never be deployed without checks in place.

Consider a second scenario - a customer visits a car dealership's website and interacts with an AI-driven chatbot. Through a series of prompts, they convinced the chatbot to agree to sell them a car for one dollar. Fortunately for the dealership, the car was not sold, but the company should never have been in that position.

It was a predictable outcome of releasing a system without validating its boundaries, authority, or failure modes. The chatbot was given the appearance of agency without the safeguards required to control it.

Once again, the feature shipped before anyone stopped to ask whether it should.

How management styles drive change

Many companies are metaphorically drowning because they rely on a purely bottom-up management model for security.

Security teams are expected to respond to business needs, absorb risk, and clean up failures - yet they are rarely empowered with the top-down authority required to enforce standards, halt unsafe releases, or meaningfully shape architecture. Enforcement without authority is not governance; it is theater.

In practice, this allows organizations to subtly offload responsibility. Accountability is pushed downward onto understaffed, under-resourced security teams, while decision-makers retain the ability to override risk without owning the consequences. When something goes wrong, the narrative becomes "security missed it", rather than "the organization chose speed over safety."

How do we solve this?

Imagine pulling up to a security gate at a high-security building.

You aren't waved through because you look busy or because stopping you would be inconvenient. You're asked to verify who you are, why you're there, and whether you're authorized to be there at all. If something goes wrong inside, responsibility is clear - and it doesn’t fall on the guard alone.

Security gates in information security should function the same way.

Applications - and their owners - must prove why they exist, that they are ready to operate, and that they accept responsibility for the risk they introduce. This isn't about obstruction or gatekeeping. It's about shared accountability.

Information security is responsible for assessing whether those claims are valid and validating the assumptions:

• Is the system designed responsibly?
• Are known risks understood and addressed?
• Are compensating controls real, not aspirational?

Application owners, in turn, retain ownership of development, operation, and long-term maintenance. The excuse of "it's being deprecated" should not be allowed to linger for years without scrutiny and enforcement. Gates must be re-validated regularly. Risks must be remediated, or explicitly accepted by management, in writing, with full awareness of the consequences. There must be consequences. Even if those consequences are reduced bonuses. Management must be held accountable.

This is where leadership matters.

Management must empower security teams with the authority to enforce these gates through top-down governance. Without that authority, gates become suggestions. Reviews become paperwork. And security staff become scapegoats.

Security cannot be responsible for outcomes it is not allowed to control. If organizations want resilience, they must align authority with responsibility - before the employees drown.

Companies that take information security and privacy seriously don't skip those gates. They automate them where appropriate, staff them, and respect them.

In Closing

If we continue down this path - prioritizing "the business" over moral, ethical, and often legal obligations to protect customer privacy - but the business will become the final words uttered before a company takes its customers and employees down with it.