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

privacy-notice-gap-check

Use this skill when a published privacy notice may no longer match what the company does, or someone asks "is our privacy policy accurate", "check our privacy notice against the RoPA", "privacy notice review", "Article 13 and 14 check", "does our website privacy policy cover our vendors and cookies" or "update the privacy notice for the new product". Maps every collection point, compares each notice with the processing record, the vendor list and what the site and product actually collect, classifies what is missing, wrong, vague or stale, and drafts a redline plus the practice fixes that a notice edit cannot solve.

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

インストール方法を見る

含まれるファイル(1)

  • SKILL.md7.8 KB

SKILL.md(原文)

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

Use this after the processing record changes, before a product launch, after vendor changes, or on the privacy programme's review cadence. You get three documents in a new folder, ./privacy-notice-gap-check/: a list of every place the company collects personal data and which notice covers it (collection-points.md), a table of what the notice gets right, misses or gets wrong (gap-matrix.md), and a marked-up draft of the notice changes, old text next to new (notice-redline.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The privacy lead or counsel approves any change to a published notice.

Inputs to gather

Read every notice in use: the website and product privacy notice, the cookie notice, and the notices for employees, candidates and event or newsletter audiences. Read the record of processing activities, the vendor and sub-processor lists, sign-up and contact forms, and the consent tool configuration. Ask the reader, in one message: which collection points exist outside the website (sales events, purchased or enriched lead lists, partner referrals, phone support), which countries the audiences are in, and whether the processing record is current.

Step 1: map the collection points

In the collection list (collection-points.md), list every place personal data enters the company: account sign-up, contact and demo forms, newsletter, checkout, product telemetry, support channels, job applications, events, data received from customers, partners or data providers. For each, note who the people are, whether data comes from them directly or from another source, which notice covers it, and how the notice is surfaced (a link at the point of collection, or buried in a footer). Data obtained from someone other than the person falls under Article 14 of the GDPR rather than Article 13, which brings the source of the data and the timing of the information into play; mark those points clearly, because they are the most often forgotten. Check the timing too: Article 14(3) sets a reasonable period of at most one month after obtaining the data, earlier at the first communication or disclosure, and Article 14(5) holds the narrow exemptions. Note any collection point that may reach children, and the national consent age under Article 8 that applies there.

Step 2: check what the site and product really collect

With the reader, open the public site and the product in a browser and use its developer tools to list cookies, local storage and third-party requests on first load, before any consent choice, and again after accepting and after refusing. Compare with the cookie notice and the vendor list. Trackers that fire before consent are a practice problem, not a wording problem; route them to the consent tool owner. Check the consent tool as a record too: choices are logged, refusing is as easy as accepting, and withdrawal is as easy as giving consent (Article 7(3)). Non-essential cookies need consent under the ePrivacy rules whatever legal basis the notice claims.

Step 3: build the gap matrix

In the gap table (gap-matrix.md), rows are processing activities from the record and collection points from Step 1. Columns are the information items Articles 13 and 14 list, such as purposes and legal basis, the legitimate interest where relied on, recipients, transfers and their safeguard, retention, rights including withdrawing consent and complaining to a supervisory authority, automated decision-making, and for Article 14 the categories and source of the data. Mark each cell:

  • Covered: the notice says it, accurately.
  • Missing: the activity or item is not in the notice.
  • Wrong: the notice contradicts the record or reality ("we do not transfer data outside the EU" while a support vendor sits elsewhere).
  • Vague: present but not informative ("trusted partners", "as long as necessary", "to improve our services").
  • Stale: describes vendors, products or purposes that no longer exist.

Also check readability against Article 12: concise, plain language, easy to find. Check that each rights channel the notice names works: the privacy lead, or a colleague they name, sends a test request through it; the agent sends nothing. Record only the outcome that person reports (day sent, relative to this check; whether an owner who could answer got it; time to answer) against the one month Article 12(3) allows.

Step 4: decide the fix and draft the redline

For each gap, decide which side moves. If the processing should not happen as it does (no legal basis, trackers before consent, a vendor without an agreement), the fix is the practice; list it for the owner and do not paper over it in the notice. Otherwise, draft the notice change in the marked-up draft (notice-redline.md) as old text, new text and the gap it closes. Prefer a layered notice: a short first layer at each collection point and the full notice one click away. Keep retention specific (a period and its trigger), name recipient categories precisely, and state the transfer safeguard actually in the contracts. Give the redline a proposed version number and effective date, and note where today's version will be archived for later comparison.

What good looks like

  • The best reviewer starts with the browser and the vendor list, not the notice text, because undeclared trackers and new vendors are what a regulator finds first.
  • The common mistake is polishing the notice against a generic checklist while ignoring the processing record. The tell: every item is "present", but a vendor on the sub-processor page is nowhere in the notice, and retention still says "as long as necessary".
  • Good output ties every redline to a row in the processing record or a fact seen in the browser, separates notice fixes from practice fixes, and leaves a notice a customer can read in five minutes.

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-privacy-notice-gap-check

Rules

  • MUST trace every gap to a processing record row, a vendor entry or an observed collection.
  • MUST list practice fixes separately from notice edits.
  • MUST write outputs only inside ./privacy-notice-gap-check/ and ask before overwriting.
  • NEVER publish or edit the live notice; the privacy lead approves and publishes.
  • NEVER describe a transfer safeguard or legal basis the contracts and record do not show.
  • NEVER copy personal data seen in forms, tools or browser storage into the outputs.

レビュー

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

コメント

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

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

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。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 のスキルをすべて見る

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