grcskills
Menu

Stage 1 readiness walk

Use this skill when a certification audit is booked and the team wants to know whether the first stage will go through, and asks "are we ready for stage 1", "pre-audit readiness check", "what will the auditor read first", "documentation review before the certification audit", "mock stage 1" or "what would stop the audit". Walks the documentation set the way a certification auditor reads it, checks that documents agree with each other and with the records, and writes a list of stoppers, likely findings and polish items with an owner and a fix for each.

Gap and readinessISO 27001ISO 27701ISO 42001

Use this four to eight weeks before a first certification audit, or before a scope extension audit. You get two files in a new folder, ./stage-1-readiness-walk/: a short report of what would stop the audit (readiness-walk.md), and a spreadsheet you can open in Excel listing every document with its version, owner, approval and whether it goes to the auditor (document-map.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. Only the certification body decides whether an audit proceeds.

Inputs to gather

Collect the exact set the auditor will receive: the folder, platform export or document list the company plans to send, plus the audit plan or booking confirmation if the certification body sent one. Ask the reader, in one message: audit dates, the scope as written in the certification application, which documents are still drafts, and whether an internal audit and a management review have already been held over the full scope.

Step 1: map the document set

List every document in the document spreadsheet (document-map.csv): path, title, version, approval record (who and when, as a role), last review, owner role, the topic it serves, and whether it goes to the auditor or stays internal. Mark the drafts the reader named as present but unapproved, and reconcile the pack against any evidence request in the booking confirmation; an auditor credits only what was sent. Then build the list of documented information the target framework expects from the reader's licensed copy or a framework lookup, and mark each as present, present but unapproved, or missing. Do not assume the list from memory; the expected set differs between frameworks and extensions.

Step 2: read in the auditor's order

An auditor reads for the system first and the controls second. Walk in this order, noting what an auditor would question:

  1. Scope: the scope statement, the application form and the applicability statement name the same entities, sites, products and exclusions.
  2. Context and obligations: the issues, interested parties and legal or contractual obligations the documents list are the ones the scope and risks reflect.
  3. Risk method and results: the method exists, the assessment followed it, the results carry dates and owners, and the treatment plan uses the same risk ids.
  4. Applicability: every included control traces to a risk, obligation or stated reason; every exclusion has a factual justification.
  5. Objectives and measurement: objectives are measurable and at least one measurement has been taken.
  6. The improvement loop: internal audit, management review and corrective actions exist as records, not as templates.
  7. Operational records: a small sample of records proves the main processes run (one access review, one incident or event record, one supplier assessment, one change).

Step 3: test consistency, not existence

The cheapest findings are documents that contradict each other. Check at least:

  • Risk counts and ids match between the register, the treatment plan and the applicability statement.
  • Review periods, severity scales, retention periods and role names agree across documents.
  • Approval dates come before the audit and after the content they approve; a register or policy edited after its recorded approval needs a new approval. Propose a freeze: everything in the pack approved before sending, and no version change between sending and the audit.
  • Implementation status claims match what the records show.
  • No template residue: placeholder brackets, another company's name, controls for a data centre or office the company does not have.

Step 4: grade each issue

  • Stopper: an issue the auditor could treat as a reason not to continue to the next stage. In practice these are things like an undefined scope, risk results that do not exist yet, a scope that contradicts the application, or an improvement loop that has never run. Confirm which items the framework and the certification body treat as blocking, and what operating history they expect before the second stage, through a framework lookup or the certification body's own audit rules.
  • Likely finding: a gap the auditor would raise but would not stop on.
  • Polish: wording, formatting, version labels.

For each issue write the document, what an auditor would say, the fix, the owner role and the days needed. Mark which audit stage each stopper threatens: scope and application contradictions tend to block the first stage, while an improvement loop that has not run usually blocks the second; confirm with the certification body's rules. Order stoppers by lead time: an internal audit cannot be held, reported and reviewed in three days.

Step 5: write the walk

Write the readiness report (readiness-walk.md): a go, go with fixes, or postpone recommendation with reasons; the stoppers; likely findings; polish; and the question list for the auditor's opening meeting. Set a re-walk date after the stopper fixes fall due, to confirm the recommendation still stands. Ask before overwriting existing files.

What good looks like

  • The walk finds contradictions between documents, because that is what an auditor finds in the first hour. The common mistake is a checklist of document titles ticked as present; the tell is a readiness report with no finding that cites two documents at once.
  • Stoppers are few, specific and dated against the audit. A list of forty equally weighted issues helps nobody decide whether to postpone.
  • Records are sampled, not assumed. One real access review record says more than the access control policy.
  • Template residue is hunted deliberately; an auditor who finds another company's name stops trusting the set.
  • The recommendation is honest: postponing two weeks is cheaper than a failed first stage.

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-stage-1-readiness-walk

Rules

  • MUST cite the document path behind every issue, and both paths for a contradiction.
  • MUST grade every issue as stopper, likely finding or polish, with an owner role and a fix.
  • MUST write outputs only inside ./stage-1-readiness-walk/ and ask before overwriting.
  • NEVER edit, approve or re-date the company's documents; recommend and let the owner act.
  • NEVER tell the reader the audit will pass; only the certification body decides.
  • NEVER contact the certification body or send any document outside the reader's machine.