GRC Building Blocks: Policy, Standard, Procedure, and Control

Welcome to GRC Building Blocks, an educational series for people learning the language and practice of governance, risk, and compliance.

Experienced practitioners often use familiar terminology quickly because they already understand the vocabulary. Someone new to GRC may encounter several related terms in the same meeting, policy library, audit request, or software platform without anyone stopping to explain how they fit together.

Building Blocks takes important concepts that appear inside longer practitioner conversations and slows them down. The podcast is our source. The GRC concept is the lesson.

We will begin with four foundational terms:

Policy. Standard. Procedure. Control.

They are related, but they are not interchangeable. Keep the GRC Terms Explorer handy for short explanations and examples as you read.

Hear it in the practitioner conversation

Long practitioner conversations often assume some background knowledge. Building Blocks pulls out individual ideas worth understanding while preserving the original conversation for readers who want to go deeper.

The featured guest, Tom Cornelius, is the creator of the Secure Controls Framework (SCF), a comprehensive cybersecurity and data privacy metaframework. His experience building and mapping controls across laws, regulations, and frameworks gives particular weight to this discussion about using authoritative definitions.

Start around 23:42. The relevant discussion continues to approximately 24:42.

Note: The supplied timestamp focuses this lesson on one short portion of a much longer exchange.

Why definitions matter

Definitions are not merely labels. They determine how teams translate external obligations into documents, operating practices, and evidence.

“Go back to the source, be it a law, regulation, framework, and be able to cite it because if you're not citing it, you're just building on bad practice…”

Tom Cornelius, speaking in the highlighted Building Blocks segment, captures the practical lesson: foundational vocabulary should not change every time a practitioner joins a new organization or opens a different software platform.

Shared definitions make GRC work easier to explain and defend. They also help teams connect requirements to operations, organize evidence, and automate repeatable activities. When legal, security, audit, engineering, and compliance teams use the same word to mean different things, even a well-designed program can become difficult to operate.

Imagine that one team calls an MFA requirement a policy, another calls it a control, and a platform labels the related framework statement a control too. The people involved may agree that MFA matters, but they may still be talking about different artifacts and activities.

Authoritative sources provide a more stable starting point. The conversation references organizations and professional bodies such as NIST, ISO, AICPA, and ISACA. These sources do not necessarily define every term in exactly the same way, and a specific framework may use terminology for its own purpose. The important habit is to know where a definition came from instead of casually inventing one or allowing a tool to make that decision for the entire organization.

An organization may still document how it uses important terms. It should do so deliberately, cite the source or framework it follows, and explain any necessary differences.

The four building blocks

Policy

The what: the requirement. A policy expresses high-level organizational direction, expectations, or requirements. It establishes the position the organization intends people and systems to follow.

A policy usually answers questions such as:

• What do we require?
• What is our position?
• What must happen?

For example, an organization might state: “The organization requires MFA for access to sensitive systems.”

That example is not presented as an authoritative definition or a complete policy. It simply illustrates the level at which policy often operates. It tells us what the organization expects without describing every approved technology or each step needed to comply.

Standard

What you need to do the “what” well. A standard makes an expectation more specific, consistent, and measurable. It translates high-level direction into criteria that teams can apply across the organization.

Building on the MFA example, a standard might state: “Privileged accounts for specified systems must use an approved phishing-resistant MFA method.”

The policy established the broad requirement. The standard narrows it by identifying which accounts or systems are covered and what qualifies as an acceptable implementation. A useful standard gives teams enough precision to build consistently and gives reviewers something concrete to evaluate.

Procedure

The how, usually step by step. A procedure describes how people perform an activity. Procedures are operational instructions rather than the high-level requirement itself.

For MFA, a procedure could document the steps for enrolling an administrator in the approved identity system. It might explain how to verify the administrator, issue the approved authentication method, test access, document completion, and recover access when a device is lost.

Procedures help people complete work repeatedly and correctly. They may vary by team or technology even when everyone follows the same policy and standard.

Control

The actual implementation of the “what.” Control terminology varies across frameworks, so context and source matter. In practical GRC work, a control can be understood as a safeguard, mechanism, activity, or practice used to address risk and help satisfy an objective or requirement.

In our example, the identity platform technically enforcing MFA before privileged access is granted is a control. A recurring review that identifies privileged accounts without the required MFA method may also operate as a control activity.

The control is not merely the sentence written in the policy. It is something that actually operates. Practitioners look for evidence that the control was designed appropriately, put in place, and performed as expected.

See them together

Here is the same scenario viewed through all four building blocks.

POLICY
Privileged access must use MFA.

STANDARD
Privileged accounts must use an approved MFA method.

PROCEDURE
IT follows documented enrollment and recovery steps.

CONTROL
The identity system blocks privileged login unless MFA succeeds.

Each statement contributes to the same assurance system, but each does a different job. The policy establishes the expectation. The standard makes it specific. The procedure helps someone perform the work. The control helps make the expectation real and addresses the underlying access risk.

This is why using all four words interchangeably creates problems. Teams may request the wrong artifact, test the wrong thing, or mistake written intent for an operating safeguard.

Try the control translator

The same framework outcome can lead to several different organizational artifacts and activities. Select an outcome below to see how policy, standard, procedure, and control can work together without becoming the same thing.

What this looks like in the wild

An auditor asks for a policy and receives a screenshot

An auditor requests the Access Control Policy. The response is a screenshot showing that MFA is enabled in the identity platform.

The screenshot may be useful control evidence because it helps demonstrate a technical configuration. It is not necessarily the policy. The policy is the organizational statement that establishes the requirement.

An engineer asks how to configure MFA and receives a policy

A security engineer needs to configure MFA for a group of administrators. Someone sends the company’s Access Control Policy.

The policy may confirm that MFA is required, but it probably does not provide enough detail to complete the task. The engineer may need the applicable standard to identify approved methods and a procedure that explains enrollment, configuration, testing, and recovery.

A platform labels every framework requirement a control

A compliance platform may use the word “control” as a convenient label for framework requirements, mapped statements, safeguards, or internal records. That does not automatically make the platform wrong. Products often simplify terminology so users can organize work consistently within the tool.

Practitioners should still understand the underlying concepts. A platform’s labels should not become the organization’s entire GRC vocabulary without considering the framework, source, and operating environment behind them.

Building Block takeaway

Policy tells us what the organization expects.

Standards make expectations specific.

Procedures explain how work gets done.

Controls are mechanisms or activities that help make those expectations real and address risk.

Terminology can vary across frameworks and organizations. That is exactly why practitioners should know their sources and define important terms deliberately.

Keep learning

Part of learning GRC is knowing where to go when a term or framework comes up in conversation. These are good places to keep exploring.

NIST CSRC Glossary

Use this when you encounter unfamiliar cybersecurity or privacy terminology. The glossary collects definitions from NIST publications and other cited sources and shows where each definition came from. It is not a single universal source of truth, so read each definition in the context of its cited source document.

NIST Cybersecurity Framework 2.0

Use this to understand how organizations can organize cybersecurity risk outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. CSF 2.0 is outcome-oriented and does not prescribe one exact implementation for every organization.

Secure Controls Framework

Use this when you want to see how requirements from many cybersecurity and privacy sources can be organized and mapped into a common control catalog. The SCF is a free metaframework that can help practitioners connect requirements to controls, but it does not make every source interchangeable or determine which requirements apply to an organization.

CIS Controls

Use this when you want a practical view of common cybersecurity safeguards. The CIS Controls are prioritized and intentionally practical, which can help beginners connect security concepts to technical work. They complement rather than replace the NIST resources, and they are not universally required.

Next, Building Blocks can return to this conversation to explore control applicability and materiality.