grcskills
Menu

Policy gap review against practice

Use this skill when a team suspects its policies describe a company that does not exist, before an audit or customer review, or asks "do our policies match what we actually do", "check the policy against reality", "paper versus practice", "will the auditor find gaps in our policies", "our policy says quarterly but we never do it" or "align policies with how we work". Turns each policy into testable statements, samples the systems and records that show the practice, classifies every gap and proposes whether to fix the policy or the practice, with owners and priorities.

Policies and documentationGeneralISO 27001SOC 2

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:

  • Matches: the record agrees with the text.
  • Practice stronger: the company does more than written (phishing-resistant sign-in everywhere, the policy says "where feasible").
  • Practice weaker: the text promises more than happens (a yearly penetration test promised, the last report is 20 months old).
  • No record: the activity may happen, but nothing proves it.
  • Not observable: the agent cannot reach the system; listed for the owner to show.

Step 3: decide which side to fix

The reflex is to fix the practice to match the paper. Often the paper is wrong. Rules of thumb:

  • The gap touches a customer contract, a legal obligation or a risk the register rates high: fix the practice; the text stays.
  • The policy promises a frequency the team cannot sustain and the risk does not need (daily manual log review by a team of three): change the text to what the risk needs, then hold them to it. A commitment met every time beats a stricter one missed every time.
  • Practice is stronger: raise the text only if the company wants to be held to the stronger level; otherwise remove the contradiction and keep headroom.
  • No record: the fix is a record (a recurring ticket, a log export, a sign-off line), not a rewrite.

Where a framework expects a particular policy element or frequency, run a framework lookup instead of guessing.

Step 4: write the outputs

The comparison table (gap-table.md): a header with the review date, the evidence window and the policy versions tested, then one row per statement with the id, the policy text quoted exactly, the evidence examined and sample, the classification, the proposed side to fix, the owner role, and an empty decision column (accepted, rejected or deferred, with the owner's reason). Add a short section listing contradictions between policies (two review frequencies for one activity, two definitions of sensitive data). For each accepted practice fix, add a ready-to-paste tracker row; the owner enters it in the corrective action tracker so the next audit can verify closure.

The fix list (fix-list.md): grouped by owner, each fix written as an action someone can start tomorrow ("create a recurring ticket for the backup restore test with the report attached"), with effort S, M or L. Order the list: weaker practice on high-risk or contractual commitments first, then missing records, then text corrections. End with the "not observable" list so the owner knows what to bring to the review meeting.

What good looks like

  • The best reviewer goes first to the promises with numbers in them: frequencies, deadlines, percentages, "all" and "every". That is where auditors sample and where gaps live.
  • The common mistake is checking the policy against a framework checklist and calling it a gap review. That shows the document is complete, not that it is true. The tell: the evidence column is empty, or every row says "matches" with no sample named.
  • The second mistake is rewriting every policy down to current practice, including commitments customers relied on. The tell: the fix list weakens contractual promises with no owner decision recorded.
  • Good output lets an owner accept or reject every fix in one meeting, and an auditor sampling the same items afterwards would find what the table says.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-policy-gap-review-against-practice

Rules

  • MUST quote policy text exactly and cite the record or system behind every classification.
  • MUST record the sample size and how the sample was picked for every tested statement.
  • MUST write outputs only inside ./policy-gap-review-against-practice/ and ask before overwriting.
  • NEVER edit a policy or change a system setting; propose the fix and let the owner decide.
  • NEVER classify a statement as "matches" on an interview answer or a claim alone.
  • NEVER copy personal data from records into the outputs; use counts, ticket ids and roles.