What Is the Difference Between a Policy, a Standard, and a Control?

A policy states what your organisation requires and why. A standard defines the specific, measurable requirement that supports the policy. A control is the mechanism, technical or procedural, that enforces the standard and can be tested to prove it works. Policies set direction. Standards set the bar. Controls do the work.

That distinction sounds straightforward. In practice, many organisations blur the three layers together, creating governance documents that are difficult to maintain, difficult to test and difficult to translate into meaningful assurance.

What is a security policy?

A security policy sets the organisation's overall direction, principles and expectations for managing risk.

Policies are generally approved at board or executive level. They should be principle based and technology agnostic, which means they should not need to be rewritten every time a platform, system or technical process changes.

For example, an access management policy might state that:

Access to information and systems must be authorised, appropriate to business need and limited according to the principle of least privilege.

The policy explains what the organisation expects and why the principle matters.

It does not need to specify the exact technology used to manage access or the precise frequency of every review. Those details belong further down the hierarchy.

A common failure is writing policies at too much technical detail. When a policy contains specific implementation requirements, even minor technical changes can require a formal policy change and potentially another approval cycle.

A good policy sets direction without trying to describe every operational detail.

What is a security standard?

A security standard translates a policy into a specific and measurable requirement that the organisation expects to be met.

Using the access management example, the policy establishes the principle of least privilege. An internal standard might then define requirements such as:

• Privileged accounts must use multi factor authentication.

• Access must be reviewed at defined intervals.

• Access must be removed when it is no longer required.

• Administrative access must be separated from standard user access where appropriate.

The standard is more specific than the policy. It establishes the level of performance required.

Internal standards are normally owned by the relevant technical or operational function and can be updated more frequently than board level policies.

It is also important to distinguish internal standards from external standards.

ISO 27001 and the NIST Cybersecurity Framework, for example, are external frameworks that organisations may use to inform their governance and control environments. They are not usually policies written for a specific organisation.

External standards provide useful reference points. Internal standards translate relevant requirements into your organisation's own operating environment.

What is a security control?

A control is the technical or procedural mechanism that helps achieve a defined control objective and can be tested for operating effectiveness.

Continuing the access management example, the control might require all privileged accounts to have multi factor authentication enabled.

The control could then be implemented through an identity platform, a privileged access management system or another technical mechanism.

This is the layer that can be tested.

The organisation can examine the relevant data and determine whether the requirement is being met. It can identify exceptions, assign responsibility and assess whether the control is operating as intended.

It is also useful to distinguish between a control objective and a control requirement.

A control objective describes the outcome the organisation needs to achieve.

For example:

Privileged access is restricted to authorised individuals and protected against unauthorised use.

A control requirement is more specific:

All privileged user accounts must use multi factor authentication.

The objective describes what needs to be achieved. The requirement describes what must be in place to achieve it.

Controls can also be categorised according to how they operate:

• Preventative controls aim to stop an unwanted event from occurring.

• Detective controls identify an event or failure after it has occurred.

• Corrective controls help restore the intended position after a failure.

The control is therefore the point at which governance becomes operational.

How do policies, standards and controls fit together?

The relationship can be understood as a simple hierarchy.

Layer	What it answers	Typical owner	How often it changes	Is it directly testable?
Policy	Why and what	Board or executive leadership	Rarely	No
Standard	To what level	Technical or operational function	Periodically	Indirectly
Control	How, in practice	Control owner	As needed	Yes

The access management example would therefore look like this:

Policy: Access must be authorised and based on business need.

Standard: Privileged access must use multi factor authentication and be reviewed at defined intervals.

Control: The identity management platform automatically enforces multi factor authentication for all privileged accounts, with exceptions identified and investigated.

Procedure: The relevant team follows a defined process for reviewing an exception and removing or correcting access where required.

Each layer serves a different purpose.

The policy provides direction. The standard defines the required level of performance. The control implements that requirement. The procedure explains how an individual or team carries out the activity.

The control is the layer that assurance, metrics and Continuous Controls Monitoring ultimately need to assess.

Why does the distinction between policy, standard and control matter?

The distinction matters because the three layers behave differently.

It improves audit and regulatory assurance

A policy can state that access should be appropriately managed. That does not, by itself, demonstrate that access is being managed effectively.

To provide assurance, you need to identify the relevant control and test whether it is operating.

A policy provides intent. A control provides evidence.

It makes technical change easier to manage

When technical requirements are embedded directly in a board approved policy, routine changes can become unnecessarily difficult.

Separating the policy from the standard allows the organisation to maintain stable principles while updating technical requirements as the operating environment changes.

This creates a more flexible governance model without weakening oversight.

It makes control mapping possible

Assurance frameworks, metrics and Continuous Controls Monitoring all depend on clearly defined controls. If policies, standards and controls are treated as interchangeable, it becomes difficult to understand which requirement is being tested, what evidence is needed and who owns the outcome.

If the control layer is unclear, everything downstream becomes harder to measure.

This is why a strong control framework should map requirements clearly across the relevant policies, standards and control objectives.

How many standards does an organisation need?

There is no universal number.

The right number of standards depends on the organisation's risk profile, regulatory environment, technology landscape and control requirements.

The objective should not be to create as many documents as possible. It should be to define the requirements necessary to support the organisation's policies and control environment.

A large collection of overlapping standards can create its own problems. Different documents may contain contradictory requirements, duplicate controls or unclear ownership.

A better approach is to start with the requirements that need to be managed and then determine the most effective way to structure them.

For example, i-confidential's control framework covers more than 25 standards and 130 key control requirements. The value is not simply in the number of documents. It is in how the requirements are structured, mapped and used to support assurance.

The question is therefore not:

How many standards should we have?

It is:

Do our standards provide clear, measurable requirements that can be translated into effective controls?

Should you build or buy your policy and standards framework?

There is no single right answer.

Building a framework internally gives you maximum control over the language, structure and alignment with your organisation. It can also be the right approach where your requirements are highly specialised.

The trade off is time and resource.

A framework built from scratch requires significant effort to research requirements, define terminology, map controls, establish ownership and maintain the content over time.

Using an existing framework can accelerate the process and provide a more structured

starting point. However, it still needs to be reviewed and tailored to your organisation's risks, regulatory requirements and operating model.

The important point is that a framework should be usable.

A technically comprehensive framework that nobody understands or maintains will not improve the control environment.

What this means for you

If your policies are long, your standards are unclear and your controls are not mapped to either, assurance will always be more manual and more contested than it needs to be.

The practical hierarchy is straightforward:

Policies set direction. Standards define requirements. Controls deliver and evidence the outcome.

Once those layers are separated, it becomes easier to assign ownership, manage change, map external requirements and assess operating effectiveness.

At i-confidential, we help organisations structure governance and control environments around clear, usable requirements rather than disconnected documents. Our approach supports the connection between policy, standards, control objectives, control requirements and ongoing assurance.

If your organisation is reviewing its governance and control framework, our governance and control services provide a practical starting point.

Frequently asked questions

Is a procedure the same as a standard?

No. A standard defines the requirement that must be met. A procedure explains the steps an individual or team follows to carry out an activity.

For example, a standard might require privileged access to be reviewed every quarter. A procedure would explain how the review is performed, who completes it and what happens when an exception is identified.

Does a policy need board approval?

A policy often requires approval at board or executive level because it establishes the organisation's overall direction and expectations. The exact approval process depends on the organisation's governance structure.

Technical standards and procedures are usually approved at the appropriate operational or functional level.

Can one policy have multiple standards?

Yes. A single policy can be supported by multiple standards.

For example, an access management policy might be supported by standards covering privileged access, user authentication, access reviews and joiners, movers and leavers.

The policy establishes the overall principle. Different standards can then define the specific requirements needed to apply that principle across different areas.

Are ISO 27001 and NIST CSF policies or standards?

No. ISO 27001 and the NIST Cybersecurity Framework are external standards or frameworks that organisations can use as reference points for developing their own governance and control environments.

They are not normally internal policies.

An organisation may use requirements from external frameworks to inform its own policies, standards and controls, but those internal documents should reflect the organisation's specific risk profile and operating environment.