The GRC.md convention

A thin repo-root GRC.md your agent reads before every compliance maintenance run: operating rules and pointers only (workspace, systems of record, what the agent may change, approvers, schedule, output location, audit date), never a copy of your compliance content. Template included.

GRC.md is a short Markdown file at the root of a repository that tells your coding agent how to operate before it runs any compliance maintenance. It plays the same role for GRC work that AGENTS.md or CLAUDE.md plays for code: the agent reads it first, so every run starts from the same pointers and the same limits.

It is your file. It carries no vendor branding, it lives in your repository, and you change it through your normal review process. The maintenance recipes on these docs all start by reading it.

Why thin

GRC.md holds operating rules and pointers, never a copy of your compliance content. Your scope, entities, frameworks, policies, risks and evidence already live in systems of record: your compliance platform or rulebook, your document register, your risk register, and the Company Context in ISMS Copilot. GRC.md says where those are and what the agent may do with them. Because it copies no compliance facts, it cannot go stale when those facts change; it only needs an edit when a location, an approver, the audit date, the schedule or a rule changes.

Why a separate file

Your routing rule in CLAUDE.md, AGENTS.md or a Cursor rule says how to delegate compliance questions (see Delegate GRC work from your agent). GRC.md says where things are and what the agent may do in this repository. Keeping the two apart means:

the routing rule stays the same across all your repositories, while GRC.md changes with your setup;
a person reviewing a scheduled run can check the agent's output against one short file;
changes to approvers or to what the agent may change go through a pull request, like any other change that matters.

Where it goes

Put GRC.md at the root of the repository your scheduled agent runs in, usually a dedicated, private compliance repository. Reports can contain sensitive internal data (who has access, open risks, evidence gaps): never run these recipes in, or commit their reports to, a public repository. Add one line to your routing rule so the agent always reads it:

Before any compliance maintenance run, read GRC.md at the repository root and follow it. If GRC.md is missing or a section is empty, stop and report what is missing instead of guessing.

Template

Copy this into GRC.md and replace every placeholder. Delete any section that does not apply rather than leaving it vague: the agent treats an empty section as "not set" and stops.

# GRC.md

Read this file before any compliance maintenance run. It holds operating
rules and pointers only. Facts live in the systems of record below.
Last reviewed: YYYY-MM-DD by <role>

## 1. Scope, entities and frameworks

- Scope and entities: see Company Context in ISMS Copilot / <your compliance platform>.
- Frameworks in scope: see Company Context in ISMS Copilot / <your compliance platform>.

## 2. Audit date

- Next audit: YYYY-MM-DD (<framework>, <certification body or auditor>)

## 3. ISMS Copilot workspace

- Workspace: <name> (workspace_id: <id>), or "personal". Put the exact workspace_id here: list_workspaces only returns workspaces your token's user owns, so a team workspace shared with you will not resolve by name.

## 4. Systems of record and where evidence lives

| What | Where |
| --- | --- |
| Company rules | <your compliance platform / rulebook source> |
| Document register (owner, review date or interval) | <path or URL> |
| People and access register | <path or URL> |
| Risk register | <path or URL> |
| Statement of Applicability | <path or URL> |
| Evidence | <path, drive folder or URL> |
| Questions inbox | <e.g. grc-questions/inbox.md> |

## 5. What the agent may change and what it may only propose

The agent MAY, without asking:
- read the locations above that it has access to;
- ask ISMS Copilot questions and create conversations for a run;
- write its report to the output location in section 8.

The agent MAY ONLY PROPOSE (a human applies or approves first):
- any change to a policy, procedure, register, risk score or the Statement of Applicability;
- any edit to ISMS Copilot memories;
- any removal or change of access rights;
- any statement that a control is implemented, effective or compliant.

The agent MUST NOT:
- change Company Context, approvers, or this file;
- close audit findings, accept risks or sign off documents;
- send anything outside the organisation.

## 6. Approvers

| Area | Approver (role) | Backup |
| --- | --- | --- |
| Policies and procedures | <role> | <role> |
| Access reviews | <role> | <role> |
| Risk register | <role> | <role> |
| ISMS Copilot memories | <role> | <role> |
| Audit evidence | <role> | <role> |

## 7. Schedule

| Run | Cadence | Where it runs |
| --- | --- | --- |
| Document staleness sweep | <e.g. monthly, 2nd at 07:30 UTC> | <runner> |
| Memory hygiene | <e.g. quarterly, plus by hand after an audit closes> | <runner> |
| Question triage | <e.g. Tuesday and Thursday 08:00 UTC> | <runner> |
| Pre-audit evidence checklist | <e.g. monthly, weekly in the 30 days before the audit> | <runner> |
| Access review prep | <e.g. quarterly, plus by hand when someone leaves> | <runner> |
| Risk register review | <e.g. quarterly, plus by hand after a significant change> | <runner> |

## 8. Output location

- Reports go to: <e.g. grc-reports/YYYY-MM-DD-<run>.md>
- Each report: summary, proposed actions, a "Verified" note, and a last
  line "Ran YYYY-MM-DD: N findings" (including 0).
- Reports are proposals for human review. Nothing in a report is a
  compliance conclusion until an approver in section 6 accepts it.

Writing it well

Point, do not copy. If you catch yourself pasting a scope statement, a control list or a policy excerpt into GRC.md, put a pointer to where it lives instead.
Be specific about locations. "Evidence is in the drive" gives the agent nothing to check. A folder path, a file pattern or a register file lets it compare what exists against what is expected.
Keep the change boundary narrow. Start with the agent proposing everything and applying nothing. Widen section 5 only after you have reviewed several runs.
Name roles, not people. Roles survive staff changes; put names in your internal directory.
Keep secrets out. Tokens belong in your harness configuration or your CI secret store, never in GRC.md (see Tokens, scopes, and security).

GRC.md is a convention, not a feature of ISMS Copilot. ISMS Copilot does not read the file itself: your agent reads it and passes the relevant facts along in its questions. Durable facts you want ISMS Copilot to use belong in your Company Context (added to conversations your own account starts, not in team-shared workspaces or temporary chats) or in a workspace memory.