The Security Requirements Nobody Wants to Write

Why CISOs Must Define the Rules That Operations Would Never Choose

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

Many organizations spend years building security capabilities.

They deploy modern cloud platforms. They implement endpoint protection. They establish Security Operations Centers. They achieve ISO/IEC 27001 certification. They invest in training, monitoring, and compliance.

From the outside, everything appears secure.

Yet over the years, I have noticed a recurring pattern.

The most important security requirements are often missing.

• Not because nobody understands security.
• Not because budgets are insufficient.
• Not because technology is unavailable.

They are missing because nobody is naturally incentivized to define them.

This observation changed how I think about the role of the CISO.

For many years, cybersecurity leadership focused on technologies, controls, and vulnerabilities. We built stronger walls. We improved detection. We accelerated response.

Those efforts remain important.

But today I believe one of the most critical responsibilities of a modern CISO is much simpler—and far more uncomfortable.

To define the security requirements that nobody else wants to write.

The Fundamental Tension

Every organization contains a natural tension between governance and operations.

Operations optimize for delivery.

Governance optimizes for resilience.

Neither perspective is wrong.

In fact, both are necessary.

Technology teams are measured on outcomes that make perfect sense:

• Service availability
• Project delivery
• Cost efficiency
• User satisfaction
• Operational simplicity
• Business enablement

Success means keeping systems running while supporting organizational objectives.

A CISO faces a different reality.

Success is often measured by events that never happen.

• The ransomware attack that fails.
• The data breach that never occurs.
• The regulatory crisis that never materializes.
• The geopolitical dependency that never becomes catastrophic.

The organization that survives because someone asked difficult questions before they became urgent.

This difference in incentives creates a governance gap.

And governance gaps rarely appear during normal operations.

They become visible during crises.

The Day After the Assumptions Fail

Most security failures are not technical failures.

They are assumption failures.

• Someone assumed backups would work.
• Someone assumed a supplier would remain trustworthy.
• Someone assumed cloud services would always be available.
• Someone assumed regulatory conditions would remain stable.
• Someone assumed that convenience and security would continue to align.

Then reality intervened.

The lesson is uncomfortable.

Organizations rarely fail because they lacked controls.

Organizations fail because they lacked governance around the controls they already possessed.

This distinction matters.

Because governance asks fundamentally different questions.

Not:

“Can we implement this?”

But:

“Under what conditions should we allow this to exist?”

That is where the role of the CISO begins.

The Cloud Exit Question Nobody Wants to Discuss

Imagine a successful cloud migration.

The project finishes on schedule.

Users are happy.

• Performance improves.
• Costs initially decrease.
• The vendor relationship is strong.

At this moment, most organizations consider the project complete.

The CISO should consider the governance discussion only partially finished.

A different question must be asked.

What happens if we need to leave?

The room often becomes uncomfortable.

• Nobody intends to leave.
• Nobody wants to discuss migration costs immediately after a successful migration.
• Nobody wants to allocate budget to a theoretical future event.

Yet strategic dependencies are security risks.

Not because cloud providers are unreliable.

But because dependency itself changes power relationships.

A mature security program therefore requires a requirement that operations might never create voluntarily:

Every critical cloud service must have a documented exit strategy and periodic dependency assessment.

This requirement does not improve performance.

• It does not reduce project timelines.
• It does not make implementation easier.
• It simply preserves future options.

And preserving options is one of the oldest principles of resilience.

Encryption Is Not About Mathematics

Many organizations believe encryption discussions are technical discussions.

In reality, they are governance discussions.

Consider two statements:

“We encrypt all data.”

“We control all encryption keys.”

These statements sound similar.

They are not.

The first describes a technical capability.

The second describes authority.

Control over encryption keys determines who ultimately controls access to information.

Cloud providers frequently offer robust encryption services.

From an operational perspective, provider-managed encryption is attractive.

It is simpler.

Cheaper.

Easier to maintain.

The governance perspective asks a different question.

Who ultimately holds power over access?

Who controls the final layer of trust?

Who determines whether access remains possible under extraordinary circumstances?

These are governance questions disguised as technical questions.

That is why mature security programs often require customer-managed keys for highly sensitive information.

Not because provider solutions are inadequate.

But because governance recognizes that control and convenience are not always identical.

The Backup Illusion

One of the most common conversations in cybersecurity sounds surprisingly familiar.

“We have backups.”

The statement is intended to reassure.

Unfortunately, it often creates false confidence.

• Backups are not resilience.
• Recovery is resilience.

Organizations frequently discover this distinction during their worst day.

• Files exist.
• Systems exist.
• Storage exists.

Yet restoration takes longer than expected.

Dependencies emerge.

Documentation is incomplete.

Recovery procedures have never been fully tested.

The backup existed.

The recovery capability did not.

A governance-focused CISO therefore introduces a requirement that operational teams often consider excessive:

Critical systems must be restored regularly in realistic recovery exercises.

Not because auditors request evidence.

Because reality eventually will.

Business Continuity Is Not an IT Project

One of the most persistent misconceptions in cybersecurity is that resilience belongs to technology teams.

It does not.

Technology supports resilience.

Organizations create resilience.

Imagine a complete ERP outage.

Technology teams begin recovery immediately.

That is necessary.

But another question matters more.

• Can the organization continue functioning tomorrow morning?
• Can suppliers be paid?
• Can salaries be processed?
• Can projects continue?
• Can leadership make decisions?
• Can critical services be delivered?

The answers rarely emerge from technical architecture diagrams.

They emerge from governance.

This is why mature CISOs increasingly focus on critical business process resilience rather than simply technical system resilience.

The objective is not merely restoring technology.

The objective is preserving organizational capability.

The Dependency Nobody Sees

One of the greatest risks in modern cybersecurity is invisible.

• It does not appear in vulnerability scanners.
• It does not generate alerts.
• It rarely appears on dashboards.
• It grows slowly.

Quietly.

Almost rationally.

It is dependency accumulation.

Organizations become dependent on:

• Cloud providers
• SaaS platforms
• AI providers
• Identity services
• External support structures
• Data ecosystems

Each individual dependency appears reasonable.

Collectively, they create strategic fragility.

Most operational teams will never identify this as a problem because each decision appears beneficial in isolation.

The CISO must see the aggregate picture.

This is one reason why cybersecurity leadership increasingly intersects with strategic governance.

The role is no longer limited to protecting systems.

The role increasingly involves protecting organizational freedom of action.

The Security Requirements Nobody Wants

If we examine many modern security disputes, a pattern emerges.

The requirements that create the most resistance are often the most valuable.

Requirements such as:

• Documenting cloud exit strategies.
• Testing recovery rather than assuming recovery.
• Assessing dependency risks.
• Maintaining customer control over critical encryption.
• Conducting executive cyber crisis exercises.
• Defining business degradation procedures.
• Evaluating geopolitical technology risks.
• Establishing AI governance before AI incidents occur.

These requirements often generate resistance because they reveal uncomfortable truths.

• They expose assumptions.
• They challenge convenience.
• They create accountability.
• They force conversations that organizations would rather postpone.

Yet postponing these conversations rarely removes the risk.

It merely delays the moment when reality exposes it.

Why This Matters More Than Ever

Cybersecurity is entering a new phase.

The challenge is no longer simply defending technology.

The challenge is governing dependency.

Cloud concentration.

AI concentration.

Data concentration.

Platform concentration.

Geopolitical concentration.

The organizations that thrive in this environment will not necessarily be those with the largest security budgets.

They will be the organizations that maintain strategic control over their choices.

And maintaining control begins with governance.

Not technology.

Governance.

Final Reflection

When I speak with executives, I increasingly ask a simple question:

What security requirement would disappear tomorrow if operations alone decided what was necessary?

The answer is often revealing.

Because the most valuable governance requirements rarely emerge from convenience.

They emerge from responsibility.

And that may be the most important lesson for modern CISOs.

Our role is not merely to ask whether systems are secure.

Our role is to define the conditions under which the organization remains in control—even when its assumptions fail.

Publication Note & Disclaimer

It reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.