Use this when policies were written before the practice settled, when an audit is close, or after a reorganisation, a new tool or a new team changed how work is done. You get two files in a new folder, ./policy-gap-review-against-practice/: a table comparing each promise in your policies with what the records show actually happens (gap-table.md), and a to-do list of fixes grouped by owner, most urgent first (fix-list.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Whether the policy or the practice changes is the policy owner's decision.

Inputs to gather

Read the policies in scope with their version and approval record. Then find what shows the practice: access review records, ticket and change history, backup reports, joiner and leaver checklists, training completion, vendor files, and configuration the agent can read (repository settings, infrastructure code). Ask the reader in one message: which policies matter most for the next audit or customer review, who owns each one, and which systems the agent cannot see.

Step 1: turn each policy into testable statements

Extract every sentence that commits the company to something observable: who does what, how often, within what time, leaving which record. "System owners review access every quarter" is testable. "We take security seriously" is not; note it for the owner as wording to cut or sharpen. Give each statement an id such as ACC-03. A substantial policy yields 15 to 40 testable statements; fewer than 10 means it is too vague to audit, a finding in itself. Add statements for the policy's own record: approved, reviewed by its due date, published where staff find it. An unapproved or overdue policy is a gap whatever the practice.

Step 2: find the evidence for each statement

For each statement, find the record that would prove it and sample it:

Recurring activity: the last three or four occurrences (a quarterly review means the last year).
Event-driven activity: 5 to 10 items picked across the period, not the latest five. Build the population from the source of truth (HR leaver export, deployment history, vendor payments), not the ticket queue: a leaver who never got a ticket never shows up in a ticket sample.
Configuration: the setting itself, read where it lives, not a screenshot in a folder.

Record what you looked at, by path or system, and what you saw. Then classify: