Weekly audit-readiness check

An ISMS rarely fails an audit on a missing policy. It fails on drift: a register that no longer matches the compliance platform, a scope list that misses vendors another record names, a deadline nobody saw coming, an inventory that does not match what is running. This page gives you one weekly routine that catches that drift before your auditor does. Your own coding agent (Claude Code, Codex, Cursor) runs it on your schedule, and ISMS Copilot supplies the judgment over the account MCP.

How the work splits:

• Your agent does the mechanical work on files and systems it can read: comparing lists, reading dates, checking live systems with read-only access.
• ISMS Copilot judges what the agent sends: which differences an auditor would raise, what a clause requires, what the fix is.
• You decide. The routine writes no new policy, risk, control text or objective, and never signs, approves, closes or contacts anyone.

Nothing runs on ISMS Copilot's side. There is no scheduler in ISMS Copilot: the schedule is yours (cron, launchd, GitHub Actions or any other runner), and each run is an ordinary MCP session from your agent.

What it needs (data access)

ISMS Copilot works from what your agent sends (up to 100,000 characters per message), plus your company context, memories and any files you pinned to the workspace in the ISMS Copilot web app. It has no connector to your repository or to Vanta, Drata, Probo or any other compliance platform, and over MCP your agent cannot upload files to it: list_documents returns the names and details of documents uploaded in the web app, not their content. So every check below depends on what your agent can read:

A check the agent cannot complete is reported as BLIND with the reason. It is never reported clean.

On the ISMS Copilot side, the run needs only conversations:create, plus workspaces:read if your GRC.md names a workspace. The Agent delegation token preset covers both. The prompt batches all judgment questions into at most three messages in one conversation, which stays inside the Free plan's 10 messages per 4 hours if nothing else is using that window. If a plan limit is hit, the run writes the packet anyway and marks the open items "Copilot view: unavailable".

The six checks

The agent runs all six every week.

1. Source of truth vs the compliance platform. Compare documents (titles, versions, text), risks, tasks and due dates, and findings. Report every difference.
2. Lists vs their single source. Where one list repeats another, compare them: scope categories against the scope statement, vendors and DPA evidence against the third-party register, inventories against the registers that cite them.
3. Records that contradict themselves. A table that disagrees with a dated correction further down the same document, a version header that disagrees with the newest revision-history row, a status in one register that disagrees with the same item in another.
4. Deadlines in the next 14 days. Finding and improvement target dates, platform tasks, document review dates. Name each one that is due or already overdue.
5. Recurring evidence due. For every recurring process with a stated cadence (access review, restore test, backup health, objectives measurement, risk review and the rest of your list), find the newest record and say whether the next one is due within 14 days or late. When one is due, the agent prepares a draft of the record from what it read (for example the current access list for a quarterly access review), with every owner-only cell left empty.
6. Reality vs claims. Read-only live checks of the systems the ISMS describes (machines and tokens, source-control members, platform users, backup job runs) against the infrastructure inventory and the access records. Report every claim reality does not support.

Before relying on any fact ISMS Copilot states about your own records (a version, a date, a status), the agent checks it against the source: ISMS Copilot knows only the records the agent sent or you pinned to the workspace, and those can be out of date.

What the agent may do

Alone: read everything it can reach, read-only. If you already have a documented one-way sync from your source of truth to your compliance platform, it may run that sync in its safe mode, and only within the guards the sync already enforces.

Prepares, for your yes: one proposed fix per mechanical drift, where the correct value is already decided somewhere in your ISMS and only needs copying (a version header, a date, a list row, a status a register already decided). It opens these as draft pull requests if GRC.md section 5 allows it, otherwise it lists them in the packet. When recurring evidence is due, it prepares a draft of the record from data it read and leaves every owner-only cell (sign-off, conclusions, risk decisions) empty.

Flags only: anything that needs judgment (a risk score or acceptance, the meaning of a policy, closing a finding, moving a deadline). For each one it asks ISMS Copilot for a short opinion and quotes it next to the flag, marked as advice.

Never: sign, approve or publish anything on the compliance platform; close a finding, accept a risk or change a score; merge a pull request; contact anyone (no email, chat message or comment addressed to a person); wait for an answer. It runs headless and finishes on its own.

The weekly packet

The output is one packet of at most 10 problem lines, ready for your weekly ISMS sitting, followed by three fixed lines: the checks as run, a "Verified" note and the heartbeat. Each problem line is one problem:

problem | evidence (file, line, record or live reading) | proposed fix (draft PR link, or "owner decision") | yes/no

Most important first: anything that threatens the audit date, then overdue items, then items due within 14 days, then drift. If there are more than 10 problems, the agent also writes the full list to a second file next to the packet (YYYY-MM-DD-audit-readiness-full.md), and the 10th line says how many more there are and points to it. A clean week is one line that says so and lists the six checks as run. The last line is the heartbeat: Ran YYYY-MM-DD: N findings, including when N is 0. A missing heartbeat means the run is broken, not that all is well.

What a real run finds

We run these checks on our own ISO 27001 ISMS. Items they surfaced in September and October 2026:

• Lists vs their source: the ISMS scope list missed three sub-processors that the infrastructure inventory, the third-party register and the records of processing already named.
• Records vs themselves: an access review table contradicted its own later correction.
• Reality vs claims: a read-only check of the hosting account found 20 deploy tokens that had never been revoked, several unnamed, one left from an app that no longer existed.

ISMS Copilot said which of these an auditor would raise and what the fix was. The fixes themselves stayed with the owner.

Before you start

1. Connect your agent to ISMS Copilot: Set up with your agent, or Connect Claude Code and Connect Cursor and Codex.
2. Add the routing rule from Delegate GRC work from your agent to your CLAUDE.md, AGENTS.md or Cursor rule.
3. Write a thin GRC.md at the repository root: pointers to your source of truth, compliance platform, registers, inventory and records folder, what the agent may change, approvers, schedule, output folder and audit date. See The GRC.md convention.
4. Create one token in Settings → Connected apps with the Agent delegation preset, or a token with only conversations:create and workspaces:read. See Tokens, scopes, and security.
5. Create read-only credentials for the systems check 6 reads (for example a GitHub token with only read:org, a hosting token limited to reading). The credential, not the prompt, is what prevents changes.

The prompt

Save it in your repository (for example prompts/weekly-audit-readiness.txt) so the prompt is reviewed like code.

Run the weekly audit-readiness check. You catch drift; you write no new
policy, risk, control text or objective.

Do every check in this turn. Do not start background subagents or background
tasks, and never end your turn waiting for one: nothing wakes you up again.
Write the packet before you finish.

1. Read GRC.md at the repository root. If it is missing or a section you need
   is empty, write a one-line packet saying what is missing and stop.
2. Run the six checks, using the locations in GRC.md section 4:
   1) source of truth vs the compliance platform (documents, versions, risks,
      tasks and due dates, findings);
   2) lists that repeat another list vs their single source;
   3) records that contradict themselves (tables vs later dated corrections,
      version headers vs the newest revision-history row, one status in two
      registers);
   4) deadlines in the next 14 days (finding targets, tasks, review dates);
   5) recurring evidence due within 14 days or late (newest record per
      process, against the cadence your ISMS defines);
   6) reality vs claims: read-only live checks of the systems the inventory
      and access records describe. Never print a secret or token value.
   A check you cannot complete is BLIND, with the reason. Never report it clean.
3. Collect every problem that needs judgment, then use one ISMS Copilot
   conversation for the run: create_conversation once (mode fast,
   answer_format "brief", workspace_id from GRC.md section 3 if set) and send
   the judgment questions batched, at most three messages in total. Send the
   facts and short excerpts, not whole documents. If a call returns status
   "generating", poll get_reply every few seconds; after 10 minutes, or on a
   plan-limit error, stop and mark the open items "Copilot view: unavailable".
   Quote each answer in at most 25 words as "Copilot view: ...", marked as
   advice.
4. Check every fact ISMS Copilot states about our own records against the
   source before using it. Verify only what ISMS Copilot marks as unconfirmed
   against the official text; list anything you cannot verify as "not
   verified".
5. For mechanical drift (the right value is already decided in the ISMS),
   prepare the fix: a draft pull request if GRC.md section 5 allows it,
   otherwise a proposed change in the packet. When recurring evidence is due,
   prepare a draft of the record from data you read, owner-only cells empty.
   Never merge.
6. Never sign, approve, publish, close a finding, accept a risk, change a
   score, or contact anyone.
7. Write YYYY-MM-DD-audit-readiness.md to the output location in GRC.md
   section 8: at most 10 problem lines, most important first, each
   "problem | evidence | proposed fix or owner decision | yes/no"; with more
   than 10 problems, also write the full list to
   YYYY-MM-DD-audit-readiness-full.md in the same folder, and make the 10th
   line say how many more there are and point to that file. Then one line
   naming the six checks as run (ok, N lines, or BLIND and why), one
   "Verified" note line, and last "Ran YYYY-MM-DD: N findings".

Running on a schedule

Run it once a week, finished before your weekly ISMS sitting, so the packet is the agenda. The examples use Claude Code in headless mode (claude -p). --allowedTools pre-approves the tools the run needs so it does not stop for a permission prompt. It does not block other tools on its own: the ISMS Copilot token's scopes limit what the agent can do in ISMS Copilot, and your read-only credentials limit what it can do in your systems, but neither limits local files. Run it from a dedicated clone or runner account that holds only the GRC repository, and deny tools you do not need in your Claude Code settings or with --disallowedTools. Other harnesses have their own headless mode (for example codex exec for Codex).

A claude -p run exits after the agent returns its response. If the agent hands checks to background subagents and returns without collecting their results, the command can exit before the packet is written. That is why the prompt asks for every check and the packet in one turn. Keep that paragraph if you edit the prompt. Other harnesses may handle background work differently; the single-turn instruction keeps the routine portable.

The Bash patterns in the examples are placeholders for your own read-only commands (here the GitHub CLI and a hosting CLI). Allow only the commands check 6 needs.

cron (Linux)

Mondays at 07:00, for a Tuesday sitting:

0 7 * * 1 cd /path/to/grc-repo && timeout 30m claude -p "$(cat prompts/weekly-audit-readiness.txt)" --allowedTools "Read,Glob,Grep,Write,Bash(git log:*),Bash(gh api:*),Bash(flyctl:*),mcp__ismscopilot__list_workspaces,mcp__ismscopilot__create_conversation,mcp__ismscopilot__send_message,mcp__ismscopilot__get_reply" >> grc-reports/cron.log 2>&1

timeout 30m stops a stuck run; the next week's packet then shows the missing heartbeat. Cron assumes the ISMS Copilot server is registered for the user that runs it (see Connect Claude Code) and that claude is on cron's PATH. Use absolute paths if the job cannot find it.

launchd (macOS)

On a Mac, prefer launchd over cron: a job whose time passes while the Mac sleeps runs when it wakes. Put a plist in ~/Library/LaunchAgents/, with ProgramArguments running a small shell script that contains the command above, and a StartCalendarInterval of Weekday 1, Hour 7, Minute 0. Load it with launchctl load ~/Library/LaunchAgents/<your-label>.plist. A laptop that is off does not run the job, so use a shared runner for anything the team depends on.

GitHub Actions

A scheduled workflow runs the check on GitHub's runners. Store the ISMS Copilot token as a repository secret (here ISMS_COPILOT_TOKEN), your Claude Code credential as another (here ANTHROPIC_API_KEY), and each read-only system credential as its own secret.

name: grc-weekly-audit-readiness
on:
  schedule:
    - cron: "0 7 * * 1"   # Mondays, 07:00 UTC
  workflow_dispatch: {}
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: npm install -g @anthropic-ai/claude-code
      - name: Register ISMS Copilot MCP
        run: claude mcp add --transport http ismscopilot https://account.ismscopilot.com/v1/account/mcp --header "Authorization: Bearer $ISMS_COPILOT_TOKEN"
        env:
          ISMS_COPILOT_TOKEN: ${{ secrets.ISMS_COPILOT_TOKEN }}
      - name: Run the check
        run: |
          mkdir -p grc-reports
          claude -p "$(cat prompts/weekly-audit-readiness.txt)" \
            --allowedTools "Read,Glob,Grep,Write,Bash(git log:*),Bash(gh api:*),mcp__ismscopilot__list_workspaces,mcp__ismscopilot__create_conversation,mcp__ismscopilot__send_message,mcp__ismscopilot__get_reply"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ secrets.GRC_READ_ONLY_GH_TOKEN }}
      - uses: actions/upload-artifact@v4
        with:
          name: grc-reports
          path: grc-reports/

GitHub schedules run in UTC and can start a few minutes late. To keep each packet in the repository rather than as an artifact, add a step that opens a pull request with it (this needs contents: write and pull-requests: write), and your approver merges it like any other change.

Variations

The same split of work (your agent reads, ISMS Copilot judges, you decide) covers other recurring jobs. Each needs its own data access:

• Access review prep (quarterly, and when someone leaves): your agent lists who has access with read-only credentials for each system, for example gh api orgs/<org>/members. ISMS Copilot says what the review should check under ISO 27001 A.5.18 or SOC 2 CC6.2 and CC6.3. ISMS Copilot never sees your systems.
• Risk register review (quarterly, and after a significant change): your agent reads the register and the change history. ISMS Copilot proposes new risks or rescoring for your review. The agent never edits scores.
• Memory hygiene (quarterly): your agent reads ISMS Copilot memories (memories:read) and compares them with your records. Changing a memory needs a separate token with memories:write, used by a person after approval.
• Question triage (twice a week): people add compliance questions to an inbox file in the repository. Your agent sends each one and drafts an answer for an owner to review. It never sends an answer to anyone.
• Evidence checklist before an audit (weekly in the last 30 days): your agent compares what your evidence folder holds with what ISMS Copilot says an auditor will ask for. list_documents shows only the names of files uploaded to ISMS Copilot, not their content.
• Document review dates (monthly): dates come from your document register or the interval each policy states. ISMS Copilot stores no review dates, and an upload time is not a review date.

Reviewing the packet

1. Check the heartbeat line. If a packet is missing, or its last line is not Ran YYYY-MM-DD: N findings, fix the run before trusting the silence.
2. Read the BLIND checks first. A blind check is a gap in coverage, not a clean result.
3. Answer yes or no per line. Merge the draft fixes you accept; take the owner decisions to your sitting.
4. If the packet is noisy, tighten GRC.md (more precise locations) before changing the prompt.