The Confusion
Ask ten compliance professionals to define the difference between a "governance statement" and a "policy," and you'll get ten different answers. The terminology is used inconsistently across the industry, and that inconsistency causes real problems — teams talk past each other, auditors interpret requirements differently, and organizations build governance programs on shaky foundations.
Let's fix that.
What Is a Governance Statement?
A governance statement is a single, discrete requirement that prescribes, prohibits, or permits a specific behavior or condition within an organization.
Here are examples of governance statements:
- "All employees must complete security awareness training within 30 days of hire."
- "Customer data must be encrypted at rest using AES-256 or equivalent."
- "System access must be revoked within 24 hours of an employee's termination."
- "Risk assessments must be conducted annually for all critical business processes."
Each of these is atomic — it can't be meaningfully broken down further. It has a clear subject, a clear action, and (ideally) clear criteria for measurement.
The Taxonomy of a Statement
A well-crafted governance statement typically contains:
| Element | Description | Example |
|---|---|---|
| Subject | Who or what the statement applies to | "All employees" |
| Modality | The obligation level (must, should, may) | "must" |
| Action | What must be done | "complete security awareness training" |
| Condition | When or under what circumstances | "within 30 days of hire" |
| Scope | Where the requirement applies | Organization-wide |
This structure makes statements measurable. You can verify whether "all employees completed training within 30 days" in a way you can't verify whether "the organization has a security awareness program."
What Is a Policy?
A policy is a document that communicates organizational intent on a topic. It's composed of multiple governance statements, plus contextual information like scope, purpose, and definitions.
Think of it this way:
A policy is an assembly of governance statements, arranged to communicate a coherent message about how the organization handles a specific governance domain.
A password policy might contain statements about:
- Minimum password length
- Password complexity requirements
- Password rotation frequency
- Multi-factor authentication requirements
- Account lockout thresholds
Each of those is a separate governance statement. Together, they form a policy.
Why the Distinction Matters
For Compliance Mapping
Regulations don't require "policies" — they require specific behaviors. GDPR Article 32 doesn't say "have a security policy." It says organizations must implement "appropriate technical and organizational measures" including "encryption of personal data" and "regular testing and evaluating of security measures."
When you map compliance at the statement level, you can demonstrate exactly which statements satisfy which regulatory requirements. When you map at the policy level, you're hand-waving — "our security policy covers this."
For Change Management
When a regulation changes, you need to know which specific requirement was affected. If your compliance program tracks statements, you can identify the impacted statement, update it, and see every policy (assembly) that includes it.
If your program tracks documents, you have to manually search through every policy to find and update the relevant paragraphs.
For Gap Analysis
A gap analysis at the policy level asks: "Do we have a policy for this?" The answer is almost always "yes" — organizations love writing policies.
A gap analysis at the statement level asks: "Do we have a specific, measurable requirement for this?" That's a much harder question — and a much more useful one.
The Assembly Model
In Dictiva, we use the term assembly for what most organizations call a "policy document." An assembly is:
- A collection of governance statements
- Organized into sections
- Published as a versioned document
- Available for acknowledgment by stakeholders
The same statement can appear in multiple assemblies. This eliminates duplication while maintaining the familiar document format that stakeholders expect.
When you update a statement, every assembly that includes it reflects the change — automatically.
Practical Recommendations
- Start by decomposing. Take your existing policies and identify the individual statements within them. You'll likely find 10-30 statements per policy.
- Consolidate duplicates. The same requirement often appears in multiple policies with different wording. Pick the best version and standardize.
- Adopt a maturity model. Not all statements need the same level of rigor. Start with "foundational" statements and evolve toward "advanced" as your program matures.
- Use a tool built for statements. Spreadsheets and document editors aren't designed for statement-level governance. Use a platform like Dictiva that treats statements as first-class objects.