alihusains Purpose
Two failures dominate policy work. First, control statements nobody can test — "appropriate measures shall be taken" cannot pass or fail, so it cannot be audited and does not change behaviour. Second, silent edits: a reviewer approves a "tidied" document and unknowingly approves a changed obligation. This skill makes every statement testable and every change declared.
Data classification
Internal in draft; classification of the published document is stated in its own header. Policies quoting regulatory findings, incident detail, or counsel's advice are Confidential and potentially privileged.
STOP CONDITIONS:
| Trigger | Action |
|---|---|
| Counsel's advice, an investigation file, or regulator correspondence is pasted as source material | Stop. Do not reproduce privileged content in a document that will be widely published. Ask for the obligation, not the advice. |
| Real incident detail naming employees or customers is offered as an example | Stop. Policies use constructed illustrations, not real cases. Ask for it to be removed. |
| Customer or employee personal data, account numbers, or positions appear | Stop. Name the category, never the value. |
| The user asks to weaken or remove a control to close an audit finding without a compensating control | Stop. Say plainly that this converts a finding into an accepted risk that nobody accepted. Route to the risk owner and the approval forum. |
| The policy asserts compliance with a named law or rule | Do not write that assertion unless the provision reference was supplied. Route the mapping to legal-compliance-regulatory-change-impact. |
NON-FABRICATION RULE. Never invent a regulatory citation, an internal reference number, an owner, an approval date, a version history entry, or a threshold. Never state that a control exists because the policy says it should. Never carry forward a prior version's "approved by" line into a new version. If the source obligation, the current version, or the accountable owner is not supplied, list what is missing and stop.
Prerequisites
- Inputs (new policy): the obligation or risk driving it, with its source; the scope (entities, jurisdictions, populations); the accountable owner role; the approval forum.
- Inputs (revision): the current version in full — not extracts — plus its version number and the reason for change.
- Inputs (jurisdiction): which jurisdictions and regulators the policy must satisfy. Ask. A single global policy that silently encodes one jurisdiction's thresholds fails everywhere else.
- Access: none required.
For a revision, if only extracts of the current version are supplied, stop: a diff against a partial document is not a diff.
Procedure
1. Fix the document's place in the hierarchy
State which level this is and hold the line — mixing levels is why policies become unmaintainable:
| Level | Contains | Changes |
|---|---|---|
| Policy | Principles and mandatory outcomes; who is accountable | Rarely; senior approval |
| Standard | Testable requirements that must be met | Occasionally; owner approval |
| Procedure | Step-by-step how, tool-specific | Often; local approval |
| Guidance | Recommended practice, non-binding | Freely |
If a draft contains a screenshot or a named tool's menu path, it is a procedure wearing a policy's title. Split it.
2. Write control statements that can pass or fail
Every requirement must state: who · must do what · when or how often · evidenced by what. Use "must" for mandatory and "should" for recommended, and use them consistently — mixed modality is the most common reason a policy is unenforceable.
| Reject | Because | Replace with |
|---|---|---|
| "Appropriate controls shall be maintained" | No actor, no test | "The system owner must review access quarterly and retain the signed review." |
| "Staff should be aware of their obligations" | Awareness is not testable | "All staff in scope must complete the training within 30 days of joining." |
| "Where practicable" | Self-cancelling | Name the exception route instead |
| "Regularly" / "periodically" / "in a timely manner" | No frequency | State the interval or the elapsed time |
| "Best endeavours" | Contract language, not control language | State the required outcome |
| "As soon as possible" | Unmeasurable | State the clock: from what event, how many hours |
Test each statement: could an auditor sample this and record a pass or fail? If not, it is not a control.
3. Include the sections that get omitted and then cause the incident
Scope — including who and what is out of scope, explicitly · roles and accountabilities as roles, never names · the control statements · the exception process: who can grant one, on what evidence, for how long, where it is recorded, and who reviews expiry · consequences of breach, consistent with the disciplinary policy and not inventing new sanctions · related documents · definitions for every term used in a control statement · version, owner, approver, effective date, review cycle · a change record.
A policy with no exception route generates undocumented non-compliance the first week it is live. This is not optional.
4. Test the draft against reality before issuing it
- Walk one real scenario end to end. Where does it stall?
- Does any requirement depend on a system capability, a data field, or a report that does not exist? That is a project, not a policy line.
- Does it conflict with another internal document? Name it and resolve it now; contradictory policies mean neither is enforced.
- Can the accountable owner actually direct the people the policy binds?
- Does anything here require training, and is there time before the effective date?
5. MANDATORY SELF-AUDIT OF CHANGES
Do not deliver a revised policy without this section. A revision with no change log is an unreviewable document.
For every change, list: clause reference · text before · text after · why · and crucially whether the user asked for it. Improvements made on your own initiative — tightening vague wording, fixing an inconsistency, adding a missing definition, harmonising modality — are legitimate and often the most valuable part of the work, and they are exactly the changes a reviewer must be told about, because an unrequested edit is invisible in an approval meeting.
| Field | Requirement |
|---|---|
| Clause | Reference in the new version |
| Change type | Obligation changed / scope changed / wording only / addition / deletion |
| Requested | Yes — with the instruction, or No — unrequested |
| Rationale | Why, in one sentence |
| Effect on obligations | Does anyone now have to do something different? Yes/No |
Then list separately, at the top: every change where "Effect on obligations" is Yes. These are the ones the approver must see, and they must not be buried in a table of forty formatting fixes. Any deletion of a control statement goes on this short list regardless of rationale.
6. Package for approval
Deliver: the clean document · the change log · the obligations-changed short list · the open questions · what the approver is being asked to accept. If the policy implements a regulatory obligation, carry the provision reference through so the mapping survives the next audit.
Boundaries
- Not for reviewing counterparty contracts — that is
legal-compliance-contract-review; contract drafting language and policy control language are different registers and mixing them produces both a weak policy and a weak contract. - Not for determining what a regulation requires — that is
legal-compliance-regulatory-change-impact, which must run first. - Not for assembling evidence that a policy operated in practice; that sits with the control owner and the assurance function.
- Not for disciplinary decisions arising from a breach; route to HR/ER.
Hand-offs
- Receives from:
legal-compliance-regulatory-change-impactwith the obligation register and provision references. - Receives from:
finance-expense-policy-triagewhen repeated ambiguity shows a defective clause. - Routes to: the control owner and assurance function (outside this skill set) so each new control statement has a defined evidence artefact from day one.
- Routes to:
hr-training-needs-analysiswhen the policy creates a competence requirement.