Lesson · 8 min · Stage 1
Writing policy that can be enforced
Learning goal: Draft policy statements that can be followed, checked and approved.
For reference purposes only. Not legal advice.
Draft: not yet fact-checked or legally reviewed
Key points
- Use a standard structure: purpose, scope, policy statements, roles, enforcement, related standards.
- Each statement uses "shall" or "must", names a role, and sets a measurable frequency or threshold.
- Start every policy with an administrative header: ID, version, author, revision date, review cadence and approval status.
- Put framework citations at the end of the statement they support, not only in a list at the back.
- Handle exceptions through a time-bound, recorded workflow.
Who this is for: anyone new to the topic. Related stage: Set up governance.
A six-section structure
- Purpose
- Scope
- Policy statements (enforceable requirements)
- Roles and responsibilities
- Enforcement and compliance
- Related standards and framework mappings
Begin with an administrative header: title, document ID, version, author, last revision, review cadence and approval status. A policy with no header looks like it has no process behind it.
Three rules for enforceable language
| Rule | Instead of | Write |
|---|---|---|
| Mandatory verb | “should consider” | “shall” or “must” |
| Named role | “teams” | a specific title |
| Measurable | “regularly” | “every 90 days” |
Flawed: “Teams should consider reviewing model access controls regularly.” Enforceable: “The System Administrator shall review inference endpoint access rights every 90 days.”
Scope: be specific
“This policy applies to all AI across the company” cannot be enforced or audited. Name the environments, asset types and users it covers.
Citations next to the statement
When a statement relies on a standard, cite it right after the requirement, in one parenthetical. Naming the clause beside the rule shows the link; a list at the end of the document does not. If a framework does not cover an emerging risk, say so in an assumptions section, log the gap in your governance backlog and set a date to revisit it.
Three approval gates
- Draft complete: all content sections written in mandatory language with roles and citations.
- Peer reviewed: at least one subject-matter peer, with reviewer, date and open feedback recorded.
- Ready for the CISO or approver: header complete, version history locked, open assumptions flagged with proposed resolutions, sign-off marked pending.
Exceptions
When a team cannot comply, they ask for an exception. A good request names the requester and system, the exact policy clause, the business justification, compensating controls (with owner and frequency), a fixed duration and a signed risk acknowledgment. A decision is approved, denied or escalated, with a recorded rationale and an expiry date. No open-ended approvals.
What to do now
- Rewrite one of your policy sentences with a verb, a role and a frequency.
- Check your scope statement: could an auditor tell what is in and out?
- Use the AI use policy template.
Sources
- Supplied governance study notes (module 6)
Reviewed 2 Oct 2026. Sources: ISO/IEC 42001 standard page; OWASP Top 10 for LLM Applications.
Part of: Compliance and legal path.
Was this page useful? Tell us what is missing or wrong ↗ · Report a correction