grcskills
Menu

Applicability status reconciliation

Use this skill when the implementation status column of a statement of applicability may not match reality, and the team asks "is our SoA accurate", "check the implemented column", "do we have evidence for every implemented control", "reconcile the SoA with our evidence", "pre-audit evidence check" or "the auditor found a control marked implemented with no records". Samples the records behind every control marked implemented, grades the evidence, proposes a corrected status for each row and writes a reconciliation table plus an evidence gap list with owners.

Statement of applicabilityISO 27001

Use this six to ten weeks before an external audit, and at each internal audit of the management system. You get two files in a new folder, ./soa-status-reconciliation/: a spreadsheet you can open in Excel comparing, control by control, the status the company claims with what its records actually show, and the status they support (status-reconciliation.csv), and a to-do list per owner of the proof that is missing and how long it takes to produce (evidence-gaps.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The reconciliation proposes statuses; the control owner and the approver of the statement decide them.

Inputs to gather

Read: the statement of applicability, the treatment plan, the evidence index or compliance platform export, policies and procedures, and the records the agent can reach (ticket exports, review records, logs exported by the reader, training records, supplier assessments). Ask the reader for the audit period the next audit will cover and which systems are the source of truth for people, assets and changes. Write the period's start and end dates in the gap list; a record outside them supports nothing.

Step 1: list the claims

For each control marked implemented or partially implemented, add a row to the reconciliation spreadsheet (status-reconciliation.csv): the control id, the claimed status, the owner, and the evidence the statement or index points to. Note controls with no evidence pointer at all; they go straight to the gap list (evidence-gaps.md).

Step 2: classify what the control is

The type sets what evidence proves it:

  • Recurring: runs on a schedule (access review, backup test, vulnerability scan review). Proof is a record per run in the period.
  • Event-driven: runs on a trigger (leaver, new supplier, change, incident). Proof is the record for a sample of triggers.
  • Configured: a technical setting (disk encryption, multi-factor sign-in, logging). Proof is a current configuration export plus the process that keeps it true.
  • Documented: a policy or plan that must exist and be approved. Proof is the approved version, communicated to the people it applies to.

Step 3: sample and grade the evidence

Sample sizes that hold up for a first pass: for recurring controls, every run in the audit period up to the last four; for event-driven controls, five from the population, chosen across the period and not from the last week; for configured controls, the current export plus one check that the population is complete (every laptop, every production account), and the mechanism that keeps the setting true (drift alert, enforced policy, periodic re-export); without one, the control is supported only as of the export date. Where a population is smaller than the sample, test all of it. An empty population needs a check that it really was empty: no leaver records is fine in a year with no leavers, and untested if the HR export shows departures. Grade each control:

  • Supported: records exist for the sample, are dated in the period, cover the population and show the practice ran.
  • Design only: a policy or procedure exists, no operating record.
  • Stale: records exist but are older than the period or the stated frequency.
  • Partial population: records cover some systems, teams or sites only.
  • Missing: nothing found.
  • Contradicted: a record shows the opposite (a leaver active after the stated removal time, an encryption export with exceptions).

Step 4: propose the status

The proposed status follows the weakest grade in the sample. Supported keeps implemented; design only or stale becomes implemented, evidence pending or in progress with an action; missing becomes planned or in progress; contradicted becomes in progress with a correction raised to the owner at once. For each change, write one line on why, with the record paths, and mark that the statement needs updating, so the approver changes the governed document before the audit. Where the standard's expectations on what the status column means matter, run a framework lookup rather than assuming.

Step 5: write the gap list

Write the gap list grouped by owner role: control id, what is missing, the exact artefact that would close it, and how long before it can exist (a quarterly control needs a quarter). Put contradictions first; they are likely audit findings and may be incidents. Then rank by how likely the auditor is to sample the control: controls tied to top risks, recent incidents or customer claims come before low-traffic ones. Ask before overwriting either file.

What good looks like

  • Every proposed status rests on sampled records with paths, not on interviews.
  • The common mistake is accepting a policy or a single screenshot as proof that a recurring or event-driven practice runs. The tell is a reconciliation where every row is Supported and the evidence column lists policy documents.
  • Evidence created in bulk just before the audit is noticed: a cluster of records with creation dates in the same few days is something an auditor sees too.
  • Population completeness is checked. Encryption on 40 laptops proves little if the asset list has 55.
  • The gap list is short enough to close before the audit, or honest that it cannot be.

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-soa-status-reconciliation

Rules

  • MUST cite record paths for every grade and every proposed status change.
  • MUST raise every contradicted control to its owner role as the first item in the gap list.
  • MUST write outputs only inside ./soa-status-reconciliation/ and ask before overwriting.
  • NEVER change the statement of applicability or any record; propose and let the owner act.
  • NEVER grade a recurring or event-driven control as supported on a policy alone.
  • NEVER copy personal data from sampled records into the outputs; refer to records by path and id.