Establishing Consistency in Modality: Must vs Shall vs Should for Security Policies (Style Guide Essentials)

1) Purpose and Risks of Modality in Security Policies

In Governance, Risk, and Compliance (GRC) writing, modality is not a stylistic flourish; it is the mechanism by which you express enforceability. The modal verb you choose signals whether a statement is a non-negotiable control, a binding requirement drawn from a standard, or a recommended practice that allows managed exceptions. When modality is inconsistent across a policy set, auditors struggle to determine which statements are enforceable, legal teams face ambiguity during incidents or disputes, and implementers may under- or over-apply controls. These misalignments accumulate into audit findings, delays in remediation, and control failures that materially elevate risk. A unified style guide that clarifies “must vs shall vs should” across all security documents ensures that policy intent survives author turnover, cross-team collaboration, and versioning over time. In short, modality is your enforceability switch: choose it deliberately.

Within a policy style frame, the three modals carry distinct meanings with compliance implications. Use the following definitions precisely.

• Must indicates an unconditional, mandatory requirement tied to compliance or risk control. A “must” statement is meant to be measurable and auditable. If a policy sentence uses “must,” it commits the organization to demonstrable behavior: a specific actor takes a defined action within a defined timeframe, leaving evidence that can be inspected by internal audit, external assessors, or regulators. Because “must” carries enforceability, it should be used for all internal controls where non-compliance is not acceptable without formal exception.

• Shall historically signals a binding requirement and is prevalent in contracts and formal standards. Many international and industry standards—especially in legalistic or technical contexts—retain “shall” to denote obligations. However, in internal security policies, “shall” can introduce needless legal tone, vary by jurisdictional expectations, and invite interpretive disputes about intent. A common best practice is to avoid “shall” in internal policy language unless you are mirroring or quoting a cited standard verbatim for regulatory mapping. This approach reduces ambiguity while retaining fidelity to authoritative sources.

• Should conveys a recommended control or best practice. It signals that the organization encourages the behavior but allows exceptions when justified and approved. In a mature GRC environment, “should” statements are paired with a documented exception path, such as risk acceptance or compensating controls approved by a designated authority (e.g., the CISO). This preserves flexibility where context varies, while keeping decision rights and risk visibility centralized.

Anchoring this distinction in your style guide prevents policy drift across different authors and teams. Over time, documents are updated, merged, or localized; without a single, enforced modality rule set, well-intentioned writers mix terms, weakening enforceability. When auditors search for “must vs shall vs should style guide security,” they are often looking for precisely this alignment—clear, published norms that make policy intent consistent and testable.

2) Decision Tree for Selecting the Modal

A simple decision tree helps authors choose the correct modal based on intent, source authority, and measurability. Start with enforcement and work backward to wording. The following steps guide this selection and protect against accidental dilution of controls.

• Step A: Is non-compliance acceptable without formal exception? If no, use must. If the organization cannot tolerate deviation from a requirement without a documented exception process, then the statement is a mandatory control. “Must” is the correct modal. This keeps high-risk controls auditable and unambiguous. Even when operational realities are complex, choosing “must” ensures that any deviation is visible and governed through formal exception management rather than informal workarounds.

• Step B: Is the text mirroring an external standard that uses shall and needs verbatim citation? If yes, preserve shall in the quoted requirement; otherwise convert to must in internal policy language. Many frameworks (e.g., ISO/IEC standards) use “shall” in normative clauses. If you are citing a clause verbatim for compliance mapping or contractual alignment, retain “shall” within quotation marks or a clearly referenced citation block. Then, translate the requirement into your internal policy with “must” to maintain a consistent house style. This dual presentation keeps auditors satisfied with traceability while giving employees a clear, internal statement of obligation.

• Step C: Is it a recommended practice where risk owners may approve exceptions with justification? Use should. Some practices materially improve security but may not be universally feasible. “Should” communicates that the control is recommended, while the style guide must also require an explicit exception path and approver. This balances security outcomes with operational flexibility, ensuring that deviations do not occur silently or without compensating analysis.

• Step D: For permissions (allowed actions) use may; for capabilities (system ability) use can. Ensure these do not replace must/should in controls. Clarity is improved when you reserve “may” strictly for permissions and “can” strictly for describing capabilities or possibilities. Avoid letting either term stand in for requirements. For instance, “may” does not create an obligation and cannot be audited as a control; “can” simply describes that something is possible, not that it is required or recommended.

• Measurability check for must statements: Any sentence using “must” should be testable. Revise the clause to specify the actor (who), the action (what), timing or frequency (when), and the evidence (proof). This discipline converts policy intent into an auditable control. If a “must” statement cannot pass this test, its wording is incomplete and should be refined before publication.

This decision tree ensures that your policy corpus encodes decision rights and expectations consistently. It also prevents the common anti-pattern of mixing modals within a single requirement, which erodes clarity during audits and investigations.

3) Style Guide Essentials and Micro-Patterns

To operationalize modality, codify precise rules that apply to all writers and reviewers. These style guide essentials keep language enforceable, consistent, and aligned with common security standards (e.g., NIST, ISO) and legal drafting norms, while minimizing ambiguity for readers.

• Default mandatory modal = must. In internal policies, “must” is the standard for mandatory requirements. Reserve “shall” for direct quotations from external standards or contracts when exact wording is necessary for traceability. This rule reflects US policy-writing preferences for clarity and enforceability and reduces the risk of legalistic ambiguity.

• Recommendations = should, with a built-in exception path. Do not publish “should” statements without specifying how exceptions are handled and by whom. Link to your risk acceptance process or compensating control guidance, and state the approving authority. This converts a vague recommendation into a governed recommendation that can be tracked and reviewed.

• Permissions = may; Capabilities = can; do not use these in place of must/should for controls. Keep permissions and capabilities lexically distinct. When you intend to create a control, avoid “may” and “can,” which create either optionality or descriptive statements, not obligations.

• One modal per requirement sentence. Stacking modals within one sentence (e.g., “must/should”) creates conflict and undermines enforceability. If you need to express optional elements alongside mandatory ones, separate them into distinct sentences or clauses with clear subjects.

• Keep the subject explicit. Start requirement sentences with the role or system actor (e.g., “System Owners,” “Developers,” “Data Custodians,” “Service Accounts”). Avoid impersonal constructions that hide accountability. Explicit subjects support auditability and facilitate role-based training.

• Use present tense and active voice. Present, active formulations are easier to read and audit. They reduce interpretive ambiguity, especially for non-native speakers and cross-functional stakeholders.

• Capitalize defined terms consistently; do not capitalize modals. If your glossary defines specific roles (e.g., System Owner, Data Steward) or terms (e.g., Sensitive Data), capitalize them consistently. Keep “must,” “shall,” and “should” lowercase to avoid implying special legal status.

• Regional variants and house preference. In US policy writing, “must” is preferred over “shall” because it is clearer and avoids legal drafting pitfalls. In some EU legal texts, “shall” remains common. Your style guide should declare a house preference (typically “must” for internal documents) and document the narrow exceptions where “shall” is retained—primarily in verbatim quotations or contract language. This transparency helps global teams align their local practices with the enterprise standard.

These micro-patterns align your documents with the expectations of auditors and assessors from NIST, ISO, and similar frameworks. They also create a predictable reading experience across policies and procedures, which is essential when large audiences and diverse teams must implement controls uniformly.

4) Apply and Audit: How to Maintain Consistency Over Time

Establishing clear modality is only the first step; maintaining it across revisions, new documents, and regional adaptations requires disciplined application and auditing. Begin by integrating modality checks into your document lifecycle. At drafting, authors select the modal via the decision tree, verify measurability for “must” statements, and include exception paths for “should.” At peer review, editors confirm the single-modal rule per sentence, the explicit actor, and the alignment with defined terms and capitalization. Before publication, owners validate that any use of “shall” is either a direct quotation of an external standard or a contractual clause and that internal restatements employ “must.”

During audits—internal or external—consistency in modality reduces contention and accelerates testing. Auditors can map “must” statements directly to control tests, ask for evidence as specified, and evaluate timing or frequency without interpretive debates. “Should” statements become areas for advisory assessment, where auditors verify that exceptions follow the approved path and that compensating controls are documented. This clear separation lowers the risk of adverse findings rooted in drafting rather than control performance.

Create a concise audit checklist focused on modality. Confirm that each requirement uses exactly one modal and that the choice matches the decision tree. Validate that all “must” statements are measurable and include who/what/when/evidence. Verify that every “should” includes a defined exception path and approver. Ensure “shall” appears only in quotations or contract-bound sections. Scan for misuses of “may” and “can” to avoid accidental creation of pseudo-controls. Finally, check that actors are explicit and that capitalization aligns with the glossary. Making this checklist part of policy QA raises overall document quality and eases compliance reviews.

To sustain quality across a portfolio, align modality guidance with your procedures and standards. Policies set the “what” and “why,” while standards and procedures detail the “how.” Keep “must” in the policy tier for outcomes and control obligations; allow standards and procedures to elaborate measurable details such as frequencies, thresholds, and evidence formats that enable auditability. When standards change a frequency or metric, verify that every related “must” in the policy still remains testable and consistent. If a policy uses “should” to encourage improvement, pair it with procedure-level guidance that outlines common justifications for exceptions and acceptable compensating controls.

Integrating modality into training enhances adoption, especially for non-native English speakers. Teach writers and approvers the functional difference between “must,” “shall,” and “should,” and practice the decision tree with real policy scenarios. Clarify that changing a modal changes enforceability and may have legal and audit consequences. Reinforce that “must vs shall vs should style guide security” is more than SEO—it is a shorthand for your organization’s approach to clarity, accountability, and risk control.

Finally, document your house rules in a visible, version-controlled style guide. Include rationale for each modal, the decision tree, examples of correct and incorrect usage, and references to external standards where “shall” is commonly encountered. Link the style guide from your policy template so that every new document starts with the correct expectations. Over time, this discipline yields a policy corpus that is understandable, enforceable, and resilient to organizational change.

By anchoring modality to enforceability, using a clear decision tree, codifying strict style rules, and auditing for consistency, you ensure that every policy statement communicates precisely what the organization expects—and can prove—when it matters most.