A Cybersecurity Policy Is Not Governance Until Someone Enforces It

GOVERN: Cybersecurity Governance in Plain English

Part 5 of the TCGB Subscriber Series

Somewhere in your organization is a cybersecurity policy.

Probably several.

Perhaps dozens.

They may cover passwords.

Access control.

Acceptable use.

Vulnerability management.

Incident response.

Data protection.

Third-party risk.

Remote access.

Artificial intelligence.

Cloud services.

Software development.

Maybe employees acknowledge them annually.

Maybe auditors review them.

Maybe executives approve them.

Maybe they are beautifully formatted, carefully versioned, and stored in a document repository.

None of that proves you have cybersecurity governance.

It proves you have documents.

Governance begins when those documents actually influence decisions and behavior.

That is why two Categories within the GOVERN Function of the NIST Cybersecurity Framework 2.0 belong together in this discussion:

Policy — GV.PO

and

Oversight — GV.OV.

In plain English:

Policy establishes what is supposed to happen.

Oversight determines whether it actually does.

The distance between those two statements is where many cybersecurity governance programs fail.

Consider a Simple Policy

Suppose your vulnerability management policy says:

Critical vulnerabilities must be remediated within 15 days.

Clear.

Measurable.

Reasonable.

Now day 15 arrives.

The vulnerability remains.

What happens?

Does someone receive an alert?

Does the system owner have to explain the delay?

Is an exception required?

Who can approve it?

Must compensating controls be implemented?

Does the risk owner accept the residual exposure?

Does the exception expire?

Does anyone verify that remediation eventually occurs?

Does leadership see repeated failures?

Or does the vulnerability simply become:

17 days overdue.

Then 30.

Then 60.

Then 120.

The policy still says 15 days.

The dashboard still shows the violation.

Everyone still knows the requirement.

But nothing meaningful happens.

At that point, the organization does not have a 15-day remediation requirement.

It has a 15-day aspiration.

Writing the Rule Is the Easy Part

Organizations are generally good at writing policies.

There are templates.

Consultants.

Standards.

Regulatory requirements.

Industry examples.

Policy libraries.

AI can now produce a respectable first draft of almost any cybersecurity policy in seconds.

But governance has never been primarily about the difficulty of writing sentences.

The difficult part is turning those sentences into organizational behavior.

Suppose policy requires multifactor authentication.

Is MFA actually enabled everywhere required?

Suppose policy prohibits sharing credentials.

Can shared accounts still be found?

Suppose policy requires annual vendor security assessments.

Were they performed?

Suppose policy requires terminated employees to lose access immediately.

How often does that actually occur?

Suppose policy says sensitive information cannot be entered into unapproved AI systems.

Can leadership demonstrate that employees understand the requirement and that meaningful controls support it?

The policy answers:

What should happen?

Governance asks:

How do we know?

NIST Treats Policy as Something That Must Be Managed

NIST CSF 2.0 does not treat cybersecurity policy as a one-time publication exercise.

Within GV.PO, the framework addresses establishing cybersecurity risk-management policy based on organizational context, cybersecurity strategy, and priorities.

It also expects policy to be communicated and enforced.

And importantly, NIST calls for policy to be reviewed, updated, communicated, and enforced as requirements, threats, technology, and organizational circumstances change.

That last point matters.

A policy can be perfectly reasonable when written and dangerously obsolete three years later.

The organization changes.

Technology changes.

Threats change.

Regulations change.

Business models change.

Suppliers change.

Employees work differently.

AI alone has forced organizations to reconsider policies that were perfectly adequate only a few years ago.

A policy that is never revisited slowly becomes a description of the organization that used to exist.

Policy Should Come From Risk

There is another common mistake.

Organizations sometimes begin with:

What cybersecurity policies are we supposed to have?

That is backwards.

The better question is:

What risks and obligations require us to establish organizational rules?

Remember the progression through this series.

Part 2 examined Organizational Context.

What matters?

What are our obligations?

What services are critical?

What dependencies support them?

Part 3 examined Risk Management Strategy.

What risks are we willing to accept?

What are our tolerances?

How will risk be prioritized and escalated?

Part 4 examined Roles, Responsibilities, and Authorities.

Who does what?

Who decides?

Who is accountable?

Now policy turns those governance decisions into expectations.

That means policy should not exist independently of context, risk strategy, and authority.

It should express them.

A Policy Without an Owner Is Already in Trouble

Who owns your vulnerability management policy?

Who owns your acceptable use policy?

Who owns your third-party risk policy?

Who owns your AI use policy?

And what does “owns” mean?

Does the owner review it?

Monitor compliance?

Approve changes?

Evaluate exceptions?

Report significant violations?

Coordinate enforcement?

Recommend updates?

Policies frequently become orphaned documents.

Someone wrote them.

Someone approved them.

Someone uploaded them.

Then everyone assumed the policy would somehow govern the organization by its mere existence.

Documents do not enforce themselves.

Someone needs responsibility for ensuring that policy remains connected to actual operations.

Enforcement Does Not Mean Punishment

The word “enforcement” can sound unnecessarily harsh.

It does not mean every policy violation results in disciplinary action.

Enforcement means the organization treats its stated requirements as real.

If a requirement cannot be met, something should happen.

Perhaps the issue is corrected.

Perhaps an exception is evaluated.

Perhaps a compensating control is implemented.

Perhaps the risk is escalated.

Perhaps the policy itself is discovered to be unrealistic and needs revision.

Perhaps repeated noncompliance does eventually require disciplinary action.

The exact response depends on the situation.

But there must be a response.

Otherwise, the organization teaches employees a dangerous lesson:

Policies are optional when they become inconvenient.

Exceptions Are Not the Enemy

Some leaders fear policy exceptions because they appear to weaken governance.

Properly designed exceptions do the opposite.

They make governance visible.

Suppose policy prohibits a particular configuration.

A legacy system cannot comply.

The organization has several choices.

Ignore the violation.

Rewrite the policy to accommodate one system.

Pretend the requirement is being met.

Or create a controlled exception.

A mature exception might identify:

The policy requirement.

The reason compliance is not currently possible.

The risk created by the exception.

The affected assets or business processes.

Compensating controls.

The person requesting the exception.

The person authorized to approve it.

The risk owner.

The expiration date.

The remediation plan.

The conditions requiring earlier reconsideration.

Now leadership can distinguish between deliberate risk acceptance and uncontrolled noncompliance.

That distinction is enormously important.

Then Comes Oversight

Policy tells people what is expected.

Oversight asks whether the overall cybersecurity risk-management system is working.

NIST places this responsibility within GV.OV.

The framework addresses reviewing cybersecurity risk-management outcomes to inform and adjust strategy.

It addresses reviewing the organization’s cybersecurity risk-management strategy to ensure it continues to address organizational requirements and risks.

And it calls for evaluating cybersecurity risk-management performance and making adjustments where necessary.

That makes oversight more than checking whether policies exist.

Oversight is a feedback mechanism.

Leadership establishes expectations.

The organization operates.

Results are measured.

Exceptions appear.

Incidents occur.

Threats change.

Controls fail.

Business priorities shift.

Leadership evaluates what happened.

Strategy and policy are adjusted.

Then the cycle continues.

That is governance as a living system.

Dashboards Can Create an Illusion of Oversight

A board receives a cybersecurity dashboard every quarter.

There are charts.

Risk ratings.

Trend lines.

Green indicators.

Yellow indicators.

Red indicators.

Is that oversight?

Maybe.

The better question is:

What decisions does the dashboard enable?

Suppose the board sees:

97% patch compliance.

Is that good?

Perhaps.

What is in the missing 3%?

Administrative laptops?

Or the systems supporting the company’s most critical business service?

A percentage without context can create false confidence.

Or suppose the dashboard reports:

14 policy exceptions.

Is that good or bad?

You cannot know without understanding:

Which policies?

What risks?

How long have the exceptions existed?

Who approved them?

Are they concentrated in one business unit?

Are compensating controls operating?

Are exceptions repeatedly renewed?

Is residual risk increasing?

Oversight is not the receipt of information.

It is the ability to use information to determine whether governance is producing acceptable outcomes.

Measure the System, Not Just the Activity

Cybersecurity programs generate enormous quantities of metrics.

Alerts investigated.

Vulnerabilities patched.

Phishing tests completed.

Endpoints monitored.

Incidents closed.

Employees trained.

Vendor assessments performed.

Those tell us something about activity.

Governance needs another layer of questions.

Are critical risks being reduced?

Are material risks being escalated?

Are policy exceptions being resolved?

Are the same control failures recurring?

Are risk decisions being made at the appropriate authority level?

Are accepted risks being reviewed?

Are critical suppliers meeting expectations?

Are cybersecurity investments reducing the risks they were intended to address?

Is the organization’s risk posture remaining within established tolerance?

Those questions measure the effectiveness of the governance system rather than merely the volume of cybersecurity work.

This Is Where Evidence Becomes Essential

Suppose leadership asks:

Are privileged accounts protected by multifactor authentication?

There are several possible answers.

“We have a policy requiring it.”

That is evidence of expectation.

“The system owner says it is enabled.”

That is an assertion.

“The dashboard shows 99% coverage.”

That is a measurement.

“We independently verified the configuration across all privileged accounts last week, identified three exceptions, assigned owners, documented compensating controls, and established remediation dates.”

That is evidence of governance operating.

The distinction matters.

A policy is not proof of implementation.

A control design is not proof of execution.

A dashboard is not necessarily proof of effectiveness.

Governance requires a credible connection between:

Expectation → Control → Execution → Evidence → Exception → Response → Outcome

Without that chain, leadership may believe it is overseeing cybersecurity when it is actually overseeing representations about cybersecurity.

The Board Should Ask Different Questions

Instead of asking:

“Do we have a cybersecurity policy?”

Ask:

Which cybersecurity policies govern our most significant risks?

Instead of:

“Are employees complying?”

Ask:

Where are we repeatedly failing to meet our own requirements?

Instead of:

“How many exceptions do we have?”

Ask:

Which exceptions expose critical business services or exceed our risk tolerance?

Instead of:

“Is the dashboard green?”

Ask:

What evidence gives us confidence that these indicators reflect reality?

Instead of:

“Did we pass the audit?”

Ask:

What did the audit tell us about whether our governance system is actually working?

Those are oversight questions.

Beware of the Policy Written for the Auditor

There is a particularly dangerous form of governance theater.

The policy describes a mature process.

The actual organization operates differently.

Everyone knows it.

The policy says access reviews occur quarterly.

They do not.

The policy says critical vendors undergo security assessments.

Some do.

The policy says incidents are escalated according to defined criteria.

In reality, escalation depends on who hears about the incident.

The policy says exceptions require approval.

Teams work around the requirement informally.

Then audit season arrives.

Everyone scrambles to produce evidence that resembles the documented process.

This creates two organizations.

The organization described by policy.

And the organization that actually exists.

Good governance closes the distance between them.

Repeated Exceptions Are Data

One exception may indicate an unusual circumstance.

Twenty exceptions to the same requirement may indicate something else.

Perhaps the policy is unrealistic.

Perhaps the control is poorly designed.

Perhaps a legacy platform needs replacement.

Perhaps one business unit lacks resources.

Perhaps accountability is weak.

Perhaps leadership is tolerating a level of risk inconsistent with its stated appetite.

Exceptions are not merely administrative paperwork.

They are governance signals.

Patterns matter.

If leadership treats exceptions as data, they can reveal where the cybersecurity governance system is under stress.

Enforcement Must Apply Upward Too

Cybersecurity policies lose credibility quickly when they apply only to employees below a certain level.

Suppose policy requires MFA.

A senior executive requests an exemption because it is inconvenient.

What happens?

Suppose policy prohibits storing sensitive information in personal cloud services.

A high-performing business leader ignores the requirement.

What happens?

Suppose procurement policy requires a security review before signing a technology contract.

An executive sponsor wants to bypass the review to meet a deadline.

What happens?

Culture learns from exceptions at the top.

If organizational status determines whether cybersecurity rules apply, the real policy is not the document.

The real policy is:

Security requirements apply until someone sufficiently powerful objects.

That is a governance failure.

Five Questions Reveal Whether Policy Is Real

Choose one important cybersecurity policy and ask:

Who owns it?

Someone should be responsible for keeping it relevant.

How do we know the requirements are being followed?

There should be evidence.

What happens when they are not?

There should be a defined response.

Who can approve an exception?

Authority should be explicit.

How does leadership know whether the policy is producing the intended outcome?

That is oversight.

If those questions are difficult to answer, the policy may exist without functioning as governance.

Policy Is a Promise

A cybersecurity policy is more than an internal rule.

It is a statement about how the organization says it intends to behave.

Sometimes that statement supports regulatory obligations.

Sometimes contractual commitments.

Sometimes customer expectations.

Sometimes board-approved risk boundaries.

Sometimes all of them.

That makes policy consequential.

When an organization repeatedly ignores its own policies, the problem is larger than procedural noncompliance.

It creates a gap between declared governance and actual behavior.

And when something eventually goes wrong, that gap can become difficult to explain.

Governance Requires a Closed Loop

Good cybersecurity governance does not end when leadership approves a policy.

That is where the cycle begins.

Establish the expectation.

Communicate it.

Implement controls.

Operate them.

Measure performance.

Collect evidence.

Identify exceptions.

Respond to failures.

Evaluate outcomes.

Adjust strategy and policy.

Repeat.

That is the relationship between Policy and Oversight.

One establishes direction.

The other determines whether the organization is actually moving in that direction.

Together, they turn governance from documentation into behavior.

The Real Test

There is a simple way to determine whether a cybersecurity policy matters.

Watch what happens when following it becomes inconvenient.

When a product launch is threatened.

When production must stop.

When an executive wants an exception.

When a strategic vendor cannot comply.

When remediation becomes expensive.

When a deadline is at risk.

When revenue is involved.

If the policy still influences the decision, governance may be working.

If the policy quietly disappears, it never really governed anything.

A cybersecurity policy is not governance because someone wrote it.

It is not governance because executives approved it.

It is not governance because employees acknowledged it.

And it is not governance because an auditor received a copy.

A cybersecurity policy becomes governance when it shapes decisions, deviations require accountable action, and leadership can verify that the organization is actually doing what it says.

That is the connection between policy and oversight.

And it brings us to the final installment of this series.

Because even if your organization gets all of this right internally, much of the technology, data, infrastructure, and services upon which you depend may belong to someone else.

Your governance responsibility does not disappear when your dependency crosses the corporate boundary.

Part 6:

Your Cybersecurity Governance Boundary Does Not Stop at Your Firewall.