# Legal Compliance Policy Drafting

> Drafts or revises an internal policy or standard with testable control statements, named accountable roles, a real exception route, and a mandatory self-audit that lists every change made to the source text — including changes nobody asked for — so a reviewer approves the actual diff rather than a summary of it. Use when writing a new policy or standard, implementing a regulatory change into internal rules, revising a policy after an audit finding or incident, harmonising conflicting policies, or preparing a policy for approval and publication. Trigger on 'draft a policy', 'update the standard', 'write the procedure', 'revise this policy', 'policy review', 'turn this into a standard', 'implement this rule internally'. Not for reviewing a counterparty contract (use legal-compliance-contract-review) or for assessing what a new regulation requires in the first place (use legal-compliance-regulatory-change-impact).

- Skill: `alihusains/legal-compliance-policy-drafting` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alihusains/legal-compliance-policy-drafting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/legal-compliance-policy-drafting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: alihusains (https://skillmd.com/u/alihusains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alihusains/legal-compliance-policy-drafting

---


## 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-impact` with the obligation
  register and provision references.
- Receives from: `finance-expense-policy-triage` when 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-analysis` when the policy creates a competence
  requirement.