Precision in Compliance Communication: When to Use Shall vs Should Across Frameworks

Understanding Modality in Compliance: Why “Shall” and “Should” Matter

In compliance writing, modal verbs signal the strength of obligation. The two that most often drive audit outcomes are “shall” and “should.” In standards and assurance contexts, this distinction is not stylistic; it encodes enforceability and shapes the auditor’s expectation of your evidence. Broadly:

• Shall = mandatory requirement. Nonconformance is a finding unless you can demonstrate an approved exception or compensating control that meets the same objective.
• Should = recommended or expected practice. You are encouraged—sometimes strongly—to do it, but you may justify a different approach if you still meet the control objective and risk acceptance criteria.

This difference becomes especially important because frameworks express requirements differently. If you mirror that expression faithfully in your documentation, you avoid unnecessary audit friction. If you blur it, you invite findings for either over-claiming (committing to more than you do) or under-committing (failing to meet a required baseline).

SOC 2’s principles-and-criteria model

SOC 2’s Trust Services Criteria (TSC), issued by the AICPA, are intentionally principles- and criteria-based. The criteria state what must be achieved, not the exact means. The TSC themselves largely avoid prescriptive modal verbs such as “shall” or “should.” Instead, they define criteria like “The entity identifies, selects, and develops controls to address risks …” This phrasing sets outcomes rather than specific obligations.

Modality enters SOC 2 practice through two channels:

• Your own controls and policies, which convert the criteria into commitments. Here, you choose whether a given control is mandatory (shall) or recommended (should), tied to your risk treatment.
• AICPA points of focus, which provide suggestive implementation ideas. Points of focus are not requirements; they are guidance—strongly indicative of what auditors expect to see if relevant. They implicitly align with “should,” not “shall,” unless you elevate them in your own documentation.

Because SOC 2 is outcome-focused, auditors evaluate whether your stated commitments are consistently implemented and monitored. The more you use “shall” in SOC 2 documentation, the more you bind yourself to evidence. Overuse of “shall” can inflate the audit burden; underuse can leave gaps where a reasonable auditor expects rigor. The art is to set “shall” where risk and criteria demand hard controls, and reserve “should” for methods or frequencies that are adaptable.

ISO/IEC 27001 and 27002’s split of requirement vs. guidance

ISO/IEC 27001 defines the requirements for an ISMS (Information Security Management System). The standard’s normative clauses and Annex A control set represent what your ISMS shall achieve. When a control appears in Annex A of ISO/IEC 27001:2022, it carries requirement status once you determine it is applicable via your Statement of Applicability (SoA). If you mark it applicable, you are committing to meet it—thus, a “shall.” If you deem it not applicable, you must justify that decision.

ISO/IEC 27002:2022, by contrast, is a guidance document: it explains intent, provides examples, and suggests implementation options. It uses “should” and “may” language. In other words:

• 27001 Annex A control statements = requirements (shall) for your applicable scope.
• 27002 guidance = implementation suggestions (should/may) you tailor based on risk and context.

This differentiation is the backbone for choosing modality in ISO-aligned documents. If you transpose Annex A into your policies or standards, you should maintain the mandatory force: “shall.” When you draw from 27002’s examples or notes, you signal they are recommendations: “should,” unless your risk treatment elevates them.

A Three-Layer Documentation Model: Where Shall and Should Belong

To encode obligation consistently, use a layered documentation structure. Each layer has a distinct purpose and a matching modal vocabulary.

• Policy (governance intent and mandatory principles)

  • Audience: executives, all staff, auditors
  • Modality: primarily shall
  • Purpose: define non-negotiable governance commitments, control objectives, and roles. Policies state what is mandatory for the organization as a whole and are stable over time.

• Standard (specific, mandatory control requirements)

  • Audience: system owners, security teams, IT operations, compliance
  • Modality: shall for requirements that must be uniformly met; carefully drafted with measurable criteria, thresholds, and frequencies.
  • Purpose: encode the technical and procedural minimums that implement policy objectives. Standards translate policy into testable requirements.

• Procedure/Guideline (recommended methods and options)

  • Audience: implementers, analysts, engineers
  • Modality: mainly should (and “may” for optional steps)
  • Purpose: suggest methods, tools, sequences, and templates. These documents evolve with technology and practice, and they permit acceptable variation as long as standards are still met.

This architecture prevents self-inflicted audit pain. By keeping “shall” concentrated in policy and standards, you commit only where you can provide consistent evidence. By using “should” in procedures and guidelines, you preserve agility without contradicting your mandatory posture. When auditors read across your documentation, the layering and language indicate what is enforceable and what is advisory, reducing ambiguity.

Cross-Framework Modality Crosswalk: Deciding Shall vs Should

When your organization aligns to both SOC 2 and ISO/IEC 27001, you need a systematic way to map source authority to modality. The following decision logic keeps your drafting defensible.

1) Identify the source and its authority level

• ISO/IEC 27001 Annex A control or normative clause: treat as a requirement once applicable in your SoA. Draft as shall in policy or standard.
• ISO/IEC 27002 guidance, examples, or notes: treat as recommended practice. Draft as should in procedure/guideline, unless risk elevates it.
• SOC 2 TSC criterion: outcome-based requirement without prescribed controls. Translate into your own shall statements at the policy/standard level to the extent needed to meet the criterion.
• SOC 2 points of focus: suggestive indicators. Draft as should unless you elevate them due to risk, customer/regulatory commitments, or to close a known audit expectation gap.

2) Consider your risk treatment, legal and contractual drivers

• If a recommended practice materially reduces a high-priority risk, or a regulation/contract requires it, elevate it to shall.
• If a practice is valuable but context-dependent, keep it as should and embed criteria to justify exceptions.

3) Align with evidence capability and operational maturity

• Only commit with “shall” where you can consistently produce evidence (logs, tickets, approvals, metrics).
• Where practices vary across environments or teams, keep the top-level requirement as “shall” but phrase the implementation method as “should,” preserving flexibility.

4) Use conditional commitments to manage justified variance

• Draft conditional modality for nuanced realities: “The organization shall [action] unless [defined condition], in which case [approved alternative] shall be applied.”
• This “shall… unless…” pattern ensures rigor while documenting legitimate exceptions and compensating controls.

Applying this crosswalk produces consistency: ISO-derived requirements appear as mandatory; SOC 2-aligned practices become mandatory only when necessary to meet criteria, risk, or external obligations. Everywhere else, “should” signals guidance rather than hard commitments.

Mini Drafting Workshop: From Requirement to Auditor-Ready Wording

When converting framework language into your internal documents, the goal is clarity, testability, and alignment to modality. Use this repeatable method each time you draft or update a control statement.

1) Name the objective and the source

• Start each control with a short objective and a reference to its source authority (e.g., ISO 27001 Annex A control identifier or SOC 2 criterion). This supports traceability and justifies your modality choice.

2) Declare the obligation with precise modality

• If the source is ISO 27001 Annex A and applicable, write a clear, outcome-focused shall statement. Keep it technology-neutral unless a specific technology is required to meet the objective.
• If drawing from 27002 or SOC 2 points of focus, write a should statement in procedures/guidelines, and attach rationale or conditions for elevation.

3) Make it testable

• Add measurable elements: frequency, threshold, scope, roles responsible, and evidence artifacts. The more measurable the statement, the more it belongs in a standard (shall). Guidance can remain descriptive (should) but should still be coherent and practical.

4) Embed conditional clauses where needed

• Use “shall … unless …” to pre-authorize exception paths. Define who approves, how to document the exception, and what compensating control must be in place.

5) Map to monitoring and metrics

• Tie each “shall” to monitoring activities and metrics that will surface nonconformance. For “should,” identify review cadences to assess continued suitability.

6) Maintain version control and ownership

• Assign document owners and review cycles. “Shall” content should have tighter change governance than “should” content.

This disciplined approach results in clean, auditable language that matches the strength of your commitments to the strength of your controls and evidence.

Quick Auditor-Alignment Checklist

Use this checklist before publishing or presenting your documentation to ensure modality consistency and audit readiness.

• Source mapping present: Each control statement cites its authority (27001 Annex A, ISO clause, SOC 2 criterion, or guidance/point of focus).
• Modality fidelity: Language mirrors the source’s nature—requirements become “shall,” guidance remains “should,” except where risk/regulatory drivers elevate it.
• Layer separation: Policies and standards contain “shall” statements; procedures/guidelines contain “should” statements and optional methods.
• Conditional coverage: Where variance is legitimate, “shall … unless …” clauses specify conditions, approvals, and compensating controls.
• Testability: Every “shall” includes measurable criteria (who, what, when, scope, evidence). “Should” statements avoid implying hard obligations.
• Evidence alignment: For each “shall,” evidence sources are identified (systems, logs, tickets, reports) and monitored.
• Consistency register: A modality register is maintained that lists controls, modality, source, and rationale for any elevations/downgrades.
• No internal contradictions: “Should” guidance does not conflict with any “shall” requirements; if conflict exists, revise or clarify hierarchy.
• Review cadence: Policies/standards have formal review cycles; procedures/guidelines have more dynamic update paths with documented approvals.

Why This Model Works Across Audits

This approach gives you a compact, repeatable mental model that aligns with how the frameworks themselves encode obligation:

• It respects SOC 2’s criteria-based nature by letting you define your mandatory commitments, while using points of focus as “should” guidance unless elevated by risk or obligation.
• It respects ISO/IEC 27001’s requirement/guidance split by converting Annex A into “shall” statements and keeping 27002-derived practices as “should,” tailored to context.
• It aligns your documentation layers with audit expectations: policies and standards articulate the non-negotiables; procedures explain how to meet them without overspecifying; guidelines allow evolution.
• It produces evidence-ready controls because “shall” statements are measurable and monitored, while “should” statements remain advisory, minimizing avoidable nonconformities.

Ultimately, precision in compliance communication is about credibility. When auditors see that your “shall” and “should” are intentional, sourced, and consistently applied, they can focus on whether your controls are effective, not on ambiguities in your documentation. That shift reduces audit risk, shortens fieldwork, and strengthens your overall control environment. By adopting the modality crosswalk, the three-layer documentation model, and the auditor-alignment checklist, you create a defensible, scalable writing practice that travels well across SOC 2 and ISO/IEC 27001—and any other framework that differentiates between requirements and guidance.