本文へ移動
cccskills
無料GitHub で公開

risk-to-control-traceability-check

Use this skill when the risk register and the statement of applicability were written separately and may not agree, and the team asks "do our risks link to our controls", "traceability between risk treatment and the SoA", "why is this control applicable", "the auditor could not trace a risk to a control", "check our risk treatment plan against the SoA" or "orphan controls". Checks in both directions that every treated risk points to controls and actions, and every applicable control traces back to a risk or obligation, then writes a traceability matrix and a list of orphans and contradictions with proposed fixes.

日本語の概要は準備中です。原文の説明を表示しています。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md7.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Use this after any update to the risk register, the treatment plan or the applicability statement, and before every external audit. You get two files in a new folder, ./risk-to-control-traceability-check/: a spreadsheet you can open in Excel with one row per link between a risk and a security measure, showing where each link breaks (traceability-matrix.csv), and a short report of the broken links, each with a proposed fix and the person who decides it (orphans.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Fixes are proposals for the risk owners and the statement approver.

Inputs to gather

Read: the risk register, the treatment plan, the statement of applicability (and its AI or privacy extension if any), the obligations register, AI impact assessments where the scope covers AI systems, and the evidence index. Ask the reader which document is the master when they disagree, and who approves changes to each.

Step 1: normalise the identifiers

List every risk id with its treatment option (reduce, avoid, transfer, accept), inherent and residual scores and owner role. List every control id from the statement with its inclusion decision and status. If the documents use different id schemes or free text for control references ("access policy", "MFA"), map each mention to a control id and note the ambiguous ones for the owner. Traceability fails silently when references are prose.

Step 2: trace forward, from risk to control

For each risk:

  • Reduce: at least one control id or treatment action is named. Each named control is included in the statement. The residual score is lower than the inherent score, and the reduction is credited only to controls whose status is implemented.
  • Transfer: the instrument is named (insurance policy, contract clause) and the controls that manage the counterparty are included.
  • Avoid: the decision record and the activity that stopped are named.
  • Accept: an acceptance record exists, signed by the owner role, within the acceptance threshold or with a leadership decision. The controls its residual score assumes are included and implemented, and no finding elsewhere in the matrix breaks one of its conditions.

For the top ten risks by residual score, check depth: a serious risk treated by one preventive control and nothing that would detect failure is fragile. Note where a detective or recovery control is missing.

Step 3: trace backward, from control to reason

For each included control, find at least one reason: a risk id, an obligation id, a customer commitment or a recorded baseline decision. Controls with no reason are orphans. They are not automatically wrong (some practices are baseline), but each needs its reason written down. For each excluded control, check that no risk names it in its treatment (if one does, that is a contradiction) and that the reason for exclusion is recorded.

Step 4: list the defects

Classify every problem found:

  • Orphan risk: treatment says reduce, no control or action named.
  • Orphan control: included, no reason recorded.
  • Contradiction: a risk names a control the statement excludes.
  • Phantom credit: the residual score assumes a control whose status is planned or in progress.
  • Claimed, not evidenced: status says implemented, but the evidence index has no entry for the control.
  • Unjustified exclusion: excluded, no reason recorded.
  • Generic mapping: the same two or three controls (a policy, awareness training, access control) mapped to most risks, which shows the mapping was not thought through.
  • Ambiguous reference: a prose mention that could mean several controls.

For an AI management system, also check that each significant finding of an AI impact assessment appears as a risk or as a documented decision, and that it reaches a control. Run a framework lookup for how the framework expects risk treatment and control determination to connect, instead of assuming.

Step 5: write the outputs

Write the link spreadsheet (traceability-matrix.csv), headed by the versions and dates of the register, treatment plan and statement it was built from, with one row per risk to control link: risk id, treatment, control id, control inclusion, control status, link source, defect type. Write the broken-links report (orphans.md) grouped by defect type, each with the proposed fix and the owner role who decides. End it with the defects that block the next approval of the statement or belong in the next management review. Ask before overwriting either file.

What good looks like

  • Every link in the matrix cites the document where it was found, so the reviewer can see whether the register or the statement needs to change.
  • The common mistake is checking only one direction, risk to control, and missing the controls nobody can justify. The tell is a statement of applicability where dozens of controls carry the same generic reason.
  • Phantom credit is caught: a residual score is only as good as the controls that actually run.
  • Top risks have layered treatment, not one policy.
  • After the fixes, an auditor can pick any risk or any control and follow the chain in under a minute.

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-risk-to-control-traceability-check

Rules

  • MUST trace in both directions, risk to control and control to reason.
  • MUST cite the source document for every link and every defect.
  • MUST write outputs only inside ./risk-to-control-traceability-check/ and ask before overwriting.
  • NEVER change a risk score, treatment or inclusion decision; propose it to the owner role.
  • NEVER treat a missing acceptance record as an acceptance.
  • NEVER credit a planned or in-progress control in a residual score.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Use this skill when a company needs rules for how staff use company systems, data, devices and AI tools, or asks "write our acceptable use policy", "AUP for employees", "can staff use ChatGPT at work", "AI usage policy", "BYOD rules", "remote work security rules" or "a policy people will actually read". Finds how people really work (devices, apps, AI tools, travel), puts the choices to the reader as decisions, drafts a short plain-language policy with concrete do and do not examples, and adds a comprehension check and an acknowledgement text for onboarding.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

Use this skill when a periodic user access review is due, an auditor asked for access review evidence, or someone says "prepare the access review", "run the quarterly user recertification", "who still has admin", "check leavers still have access", "build the access review sheets for managers" or "our last review was a rubber stamp". Picks the systems in scope, builds account populations reconciled against HR, pre-flags leavers, orphans, shared and dormant accounts, assigns independent reviewers, defines the decisions to record, and plans the removal follow-up.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

Use this skill when staff already use AI assistants, coding tools or AI features and the company needs rules people will follow, and asks "write our AI usage policy", "can staff use ChatGPT", "generative AI policy", "what data can we put into AI tools", "approved AI tools list", "rules for AI agents and connectors" or "AI literacy for staff". Finds out what people actually use, sets a short list of approved tools with a data traffic light, rules for checking outputs and for agents that act, a fast route to request a new tool, and writes a two-page rule set, the approved tools list and rollout notes.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

Use this skill when a company must work out where each of its AI systems sits under the EU AI Act, and asks "is this high-risk", "classify our AI systems", "AI Act risk tier", "are we a provider or a deployer", "does Annex III apply to us", "is this a prohibited practice", "what does the AI Act mean for our chatbot" or "which AI Act obligations do we have". Tests each system, one at a time, for scope, role, prohibited practices, the two high-risk routes, the narrow exemption, transparency duties and general-purpose models, and writes a reasoned classification record per system plus a summary table of resulting obligations to confirm with whoever owns legal interpretation.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

Use this skill when one AI system needs its impact on people and on the company assessed before launch, after a significant change, or because a customer, auditor or regulator asks for it, and the team says "AI impact assessment", "assess the impact of this model", "fundamental rights impact assessment", "who could this AI harm", "bias assessment before launch" or "sign-off for the AI feature". Describes the system in its context, works through impacts on the people it affects with evidence, sizes them, proposes mitigations with measurable triggers, and writes one assessment ready for the system owner and an accountable executive to sign.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

Use this skill when a company that already runs a security management system wants to add an AI management system, or is preparing for an AI governance certification, and asks "scope our AI management system", "what should the AIMS cover", "AI governance roles", "who owns AI governance", "extend our ISMS to AI" or "write the AI management system scope statement". Decides which AI systems, roles, teams and lifecycle stages are in, maps interfaces and dependencies, reuses the processes the security system already runs, assigns roles with a RACI, and writes the scope statement, the roles file and the open questions for leadership.

日本語の概要は準備中です。原文の説明を表示しています。

better-isms/grcskills102026年10月20日 更新

better-isms のスキルをすべて見る

このスキルの問題を報告する