Why policies fail when nobody owns the control

A policy is a statement of intent. It says what the organisation expects. It does not, by itself, do anything. The work happens in controls, and controls only produce evidence when a specific person is responsible for running them. When ownership is missing, the policy stays neat and the control quietly does nothing.

Policies are not controls

Teams often confuse having a policy with having a control. The access control policy says access is granted on least privilege and reviewed quarterly. That sentence is not a control. The control is the quarterly review actually happening, being recorded, and driving removals. Without an owner, the policy is aspirational and the review never runs.

The pattern repeats across the ISMS:

• A vulnerability management policy with no one accountable for triaging findings.
• A backup policy nobody tests.
• An onboarding policy where no single person confirms provisioning was correct.

The document exists. The control does not.

What ownership actually means

Owning a control is more than being named in a spreadsheet. A real owner:

• Understands what the control is meant to achieve and how it can fail.
• Runs or oversees the control on its defined cadence.
• Produces the evidence - the log, the ticket, the signed review - as a by-product of doing the work.
• Raises a risk when the control cannot be met, rather than staying silent.

The last point matters most. An owner who flags "we cannot review access this quarter because the tooling broke" is doing their job. Silence is what turns a missed control into an audit finding.

Spread ownership where the work lives

In SaaS and fintech teams, most technical controls belong with product, engineering and operations, not with a central compliance function. Compliance can coordinate, but it cannot own a control it does not operate.

• Access provisioning and reviews often sit with engineering leads or platform teams.
• Secure development and code review sit with product engineering.
• Change management and deployment controls sit with whoever owns the pipeline.
• Vendor and subprocessor reviews often sit with the team that introduced the tool.

The test is simple: the owner should be the person who already touches the system. Ownership assigned to someone with no hands on the control is ownership in name only.

Assign it and hold it

Naming an owner is the start, not the end. To make ownership stick:

• Record it in one place - a control matrix or the Statement of Applicability - so every control maps to a named person and a cadence.
• Confirm each owner has accepted the responsibility and understands what evidence looks like.
• Review ownership when people change roles or leave. Orphaned controls are a common cause of gaps.
• Check that evidence is being produced on schedule, not just that a name is filled in.

This is where an ISMS stays alive or dies. A control matrix full of names but empty of recent evidence tells you ownership is nominal. Fresh, dated evidence against each owner tells you the system is working.

Bottom line

Policies set direction; owners make controls real. When every control maps to a named person who runs it, raises risks when it slips, and produces evidence as a matter of routine, the ISMS holds together under scrutiny. If your policies read well but you are not certain each control has a real owner behind it, a readiness review can surface the orphaned controls before an auditor does.