Write GRC Policies That Work: Using Must vs. Should

You've been tasked with writing security policies for your organization. After hours of research, you find yourself staring at a blank document, unsure where to begin. The senior leadership expects clear, enforceable policies, but everywhere you look, you find only vague advice: "Write policies and enforce them."

Sound familiar?

What no one tells you is that the power of an effective policy often hinges on a single word choice. Consider these two statements:

"All sensitive data should be encrypted at rest." "All sensitive data must be encrypted at rest."

Though seemingly similar, these statements have drastically different implications for enforcement, compliance, and security. The first suggests encryption is advisable but optional. The second makes encryption a non-negotiable requirement.

This distinction isn't merely semantic—it's the difference between a policy that works and one that fails when you need it most.

The 'G' in GRC: Why Governance Hinges on Language

Governance, Risk, and Compliance (GRC) isn't just a department or function. According to the Open Compliance and Ethics Group (OCEG), GRC is "an integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity"—a concept known as Principled Performance.

Policies are the tools that translate GRC strategy into action. As one experienced practitioner puts it, "Policy is just a tool... defined by the processes it needs to support and the people who need to use it."

When policies use imprecise language, the consequences ripple throughout the organization:

• Employees don't understand what's truly required versus merely suggested
• Auditors can't effectively measure compliance
• The organization's risk appetite is not properly managed
• Security gaps emerge in areas where compliance is treated as optional

The precision of your policy language directly reflects your organization's commitment to governance. Vague policies lead to inconsistent implementation, which undermines the entire GRC framework. This is especially crucial when referencing frameworks like NIST governance risk standards or CIS Controls, where ambiguity can lead to incomplete implementation.

The Gold Standard for Clarity: Decoding RFC 2119

To eliminate ambiguity in technical documents, the Internet Engineering Task Force created RFC 2119—a standard that defines how directive words should be used. While originally created for network protocols, its definitions have become the gold standard for policy writing.

Here's what these critical terms mean according to the standard:

MUST / REQUIRED / SHALL

These terms indicate an absolute requirement. Following this directive is non-negotiable.

Example: "The system must enforce multi-factor authentication for all administrative accounts."

MUST NOT / SHALL NOT

These terms signify an absolute prohibition.

Example: "Confidential data shall not be transferred to removable media without approval from the CISO."

SHOULD / RECOMMENDED

These terms mean there may exist valid reasons in particular circumstances to ignore the requirement, but the full implications must be understood and carefully weighed before choosing a different course.

Example: "The application should log all failed authentication attempts to the central security monitoring system."

SHOULD NOT / NOT RECOMMENDED

These indicate that a particular behavior is discouraged but not prohibited.

Example: "Developers should not use hard-coded credentials in application source code."

MAY / OPTIONAL

These terms mean that an item is truly optional.

Example: "The user may change their display theme."

RFC 2119 also highlights a crucial security consideration: "These terms are frequently used to specify behavior with security implications. Authors who follow these guidelines should incorporate a discussion of the security implications of not following recommendations."

This underscores why the distinction matters so much in security policies.

Must vs. Should: The Impact on Enforceability and Audits

Let's examine a clear example that demonstrates the critical difference in enforceability:

Policy Statement with "Must": "Employees who are absent for two days or more must provide a doctor's note."

Auditability: An auditor's job is straightforward. They can create a simple checklist: For every employee absent 2+ days, is there a doctor's note in the file? The answer is a clear yes or no. Compliance is measurable, and violations are easily identified.

Policy Statement with "Should": "Employees who are absent for two days or more should provide a doctor's note."

Auditability: This becomes much harder to verify for compliance. If an employee doesn't provide a note, they haven't technically violated the policy. The word "should" is a "hedging word" that allows for discretion and exceptions without documentation.

This example, though simple, illustrates why many policies fail during audits or security incidents. When a security breach occurs and you review your policies to determine if they were followed, a "should" statement leaves too much room for interpretation and excuses.

The implications for security and compliance are significant:

• Must statements create clear accountability
• Should statements create ambiguity and weaken your security posture
• Must statements are auditable against SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound)
• Should statements make your cross reference map to compliance frameworks less reliable

The bottom line:

• Use MUST when the action is required for legal, regulatory, or security compliance
• Use SHOULD for best practices where flexibility is acceptable, but be aware that any deviations should be documented in a risk register
• Never use "should" when you actually mean "must"

A Practical Walk-through for Writing Clearer Policies

Let's walk through a step-by-step process for writing policies that are both clear and enforceable:

Step 1: Define Your Intent

Before writing a single word, determine whether the control is:

• Mandatory (required by law, regulation, or essential for security)
• A best practice (recommended but with allowable exceptions)
• Truly optional

Your intent will dictate your language choice.

Step 2: Choose Your Words Deliberately (with RFC 2119)

Match your directive words to your intent:

Vague: "Vendor assessments need to be done."

Clear: "A security assessment must be completed and approved before onboarding any new vendor handling sensitive data."

By using "must" in the revised statement, you've created an auditable requirement with no ambiguity about whether the assessment is optional.

Step 3: Eliminate Ambiguity and Define Terms

Avoid jargon where possible. When technical terms are necessary, define them for your audience. For example, don't assume everyone knows what SFTP means—define it parenthetically as "Secure File Transfer Protocol (SFTP)."

Be specific about expectations and timing:

Instead of: "Access should be reviewed periodically."

Write: "User access rights to financial systems must be reviewed on a quarterly basis by the user's direct manager."

The revised statement answers the key questions: Who must do what, to what, and when?

Step 4: Write for Readability

Use short sentences and active voice to make responsibilities clear:

Passive/Weak: "The policy must be adhered to by all staff."

Active/Strong: "All staff must adhere to this policy."

The active voice clearly identifies who is responsible for compliance, making the policy more actionable and enforceable.

Step 5: Review for Enforceability

Read your policy from an auditor's perspective. Can every "must" statement be turned into a "Yes/No" question to check for compliance? If the answer is "maybe" or "it depends," the statement is too vague and needs to be rewritten.

This approach helps create an evergreen document—one that remains relevant and enforceable over time, reducing the burden of policy maintenance.

Applying Your Knowledge in Real-world Scenarios

Let's apply these principles to common policy scenarios:

Example 1: Password Policy

Weak Version:
"Passwords should be strong and changed regularly."

Strong Version:
"All system passwords must:

• Contain at least 12 characters
• Include uppercase, lowercase, numbers, and special characters
• Be changed every 90 days
• Not be reused within a 24-month period"

The revised version defines exactly what constitutes compliance, making it straightforward to implement technical controls and verify adherence.

Example 2: Data Classification

Weak Version:
"Sensitive data should be protected appropriately."

Strong Version:
"Data classified as 'Confidential' must be:

• Encrypted with AES-256 or stronger encryption when stored
• Transmitted only via secure channels (TLS 1.2+)
• Accessible only to authorized personnel with a business need
• Backed up daily with backups retained for 90 days"

The strong version leaves no question about what protections are required, making compliance verification straightforward during audits.

Conclusion: From Confusing to Compliant

The choice between "must" and "should" is not a minor detail—it is the foundation of an effective GRC program. It defines whether your policies are enforceable mandates or merely suggestions.

By embracing the clarity of RFC 2119, you can:

• Eliminate ambiguity that leads to security gaps
• Create policies that pass audit scrutiny
• Align your organization's actions with its stated risk appetite
• Transform policies from dusty documents into effective security controls

For GRC professionals looking to enhance their policy-writing skills, consider pursuing a managerial SANS certification, which often covers these critical governance topics in depth.

Remember that effective policies aren't created in isolation. The best approach is often reverse-engineering from your compliance requirements and security goals, ensuring that every "must" and "should" serves a clear purpose in your security framework.

By being deliberate with your language choices, you'll create policies that not only exist on paper but actually work to protect your organization when it matters most.

Frequently Asked Questions

What is the difference between "must" and "should" in security policies?

In security policies, "must" indicates an absolute, non-negotiable requirement, while "should" signifies a strong recommendation that can have valid exceptions. Using "must" makes a policy statement mandatory and easily auditable. In contrast, "should" introduces flexibility, but any deviation from the recommendation should be understood and documented.

Why is precise language so critical for Governance, Risk, and Compliance (GRC)?

Precise language is critical for GRC because it translates strategy into clear, enforceable actions. Vague terms lead to inconsistent implementation, create security gaps, and make it difficult for auditors to measure compliance. Clear, unambiguous policies ensure that everyone understands their responsibilities, the organization's risk appetite is properly managed, and the entire GRC framework functions effectively.

How do I decide when to use "must" versus "should"?

Use "must" for actions that are absolutely required for legal, regulatory, or essential security compliance. If non-compliance would result in a significant security risk, a failed audit, or a legal violation, the directive is a "must." Use "should" for best practices where some flexibility is acceptable, but be prepared to document any deviations and the associated risks in a risk register.

What is RFC 2119 and why is it important for policy writing?

RFC 2119 is a document from the Internet Engineering Task Force (IETF) that defines key directive words like "must," "should," and "may" to eliminate ambiguity in technical documents. While created for network protocols, its definitions have become the gold standard for writing clear and enforceable policies, ensuring that requirements are understood and applied consistently across an organization.

What happens if we can't follow a "must" requirement?

If a "must" requirement cannot be followed, it signals a significant issue that requires immediate attention, as it represents a deviation from a mandatory control. This situation should trigger a formal exception process. This typically involves documenting the reason for non-compliance, performing a risk assessment to understand the impact, and implementing compensating controls to mitigate the risk. The exception must be approved by management and tracked in a risk register.

How can I improve my organization's existing policies for better enforcement?

To improve existing policies, review them from an auditor's perspective. Replace vague terms like "periodically" with specific timelines (e.g., "quarterly"). Change passive voice to active voice to clarify responsibility (e.g., "All staff must..." instead of "The policy must be adhered to..."). Finally, ensure every "must" statement can be tested with a simple "Yes/No" question to confirm compliance.

Further Resources

• IETF's RFC 2119 - The definitive guide for policy language
• NIST Special Publication 800-53 - Security and Privacy Controls for Information Systems and Organizations
• CIS Controls - Includes policy templates that demonstrate proper use of directive language
• OCEG GRC Capability Model - Comprehensive framework for integrating governance, risk, and compliance