Skip to content
cccskills
FreePublished on GitHub

control-owner-raci

Use this skill when controls have no clear owner, or "security" owns everything, and the team asks "who owns each control", "build a RACI for our controls", "assign control owners", "nobody knows who runs the access review", "set a review cadence per control" or "the auditor asked who is accountable". Assigns one accountable role and the operators to every applicable control, checks workload and segregation of duties, sets a review cadence from how each control runs, and writes a RACI table plus a one-page brief per owner role.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md7.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Use this after the applicable controls are known (statement of applicability or control matrix), and again after a reorganisation, a change to which controls apply, the departure of anyone who owns several controls, or at the annual management review. You get two files in a new folder, ./control-owner-raci/: a spreadsheet you can open in Excel with one row per control, showing which role answers for it, who runs it, who is consulted and informed, how often it is reviewed and any conflict found (raci.csv), and a one-page brief per owner explaining the controls they own and what an auditor will ask them (owner-briefs.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Owners accept their role; the agent only proposes it.

Inputs to gather

Read: the applicability statement or control matrix, the org chart or team list, job descriptions if any, policies that already name roles, the supplier list (some controls are operated by suppliers), and tickets or records that show who actually does the work today. Ask the reader, in one message: who can approve spending, which roles are held by a single person, and which suppliers run parts of operations.

Step 1: find who does the work today

For each control, look for evidence of who performs it: the person by role who closes the access review ticket, approves changes, runs the backup test, signs supplier assessments. Record it as observed, with the source. Where nobody does it, write "no operator" rather than guessing; those rows are the real findings of this work.

Step 2: assign the four letters

  • Accountable (A): exactly one role per control, someone who can decide, fund and answer for it, with the authority to stop a release, block a supplier or pause a process when the control fails. A team name is not an owner; a function head is.
  • Responsible (R): the roles or suppliers that operate it. Several are fine.
  • Consulted (C): roles whose input is needed before a decision (legal for retention, HR for disciplinary steps).
  • Informed (I): roles that receive the output (leadership for metrics, the security lead for exceptions).

Use role names in the RACI. Keep any role-to-person list in a separate file the reader holds, so the table survives staff changes.

Step 3: check load and segregation

  • Flag any role accountable for more than a third of all controls, and any role responsible for more than it can run in its stated hours: estimate the monthly hours each cadence implies per role and flag anything above a threshold the reader sets. The usual fix is to move accountability for people, supplier and physical controls to the business functions that run them.
  • Flag any control where the same role performs and approves (grants access and reviews access, writes and approves the change, requests and approves payment to a supplier). Propose a second role, or a compensating review, for small teams.
  • Flag every role held by one person with no deputy; name a deputy role.
  • Where a supplier is responsible, the accountable role stays inside the company, and a named internal role monitors the supplier's operation through its reports, attestations or tickets.

Step 4: set the review cadence

Base cadence on how the control runs, not on a uniform yearly date:

  • Automated or configured: the owner checks monthly that alerts and exports still work.
  • Recurring: the owner reviews after each run and confirms the next one is scheduled.
  • Event-driven: the owner samples a few events each quarter.
  • Documented: the owner reviews once a year and after any significant change.

Raise the cadence for controls that treat the top risks or were the subject of an audit finding. Where a framework sets its own expectations on review frequency or roles, run a framework lookup.

Step 5: write the outputs

Write the spreadsheet (raci.csv) with columns: control id, control description in the company's words, A, R, C, I, observed operator, cadence, next review, flags. Write the owner briefs (owner-briefs.md) with one section per accountable role: the controls they own, what each one produces, the cadence, and the three questions an auditor is likely to ask them. Ask before overwriting either file. Add an acceptance column, left blank, for the reader to fill once each owner confirms (an acknowledgement in the GRC tool, a signed brief or a logged email), because an assignment nobody can show was communicated does not survive an audit.

What good looks like

  • Every applicable control has one accountable role that is not a team, and the observed operator matches the assigned one or the gap is named.
  • The common mistake is the security lead or a compliance officer accountable for everything. The tell is one role holding most of the A column; when that person leaves, the whole programme stops.
  • Segregation conflicts are found and solved for the team size, not ignored because the company is small.
  • Cadence differs by control type, and the next review date is real.
  • Each owner can read their brief in five minutes and explain their controls to an auditor without the compliance lead in the room.

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-control-owner-raci

Rules

  • MUST assign exactly one accountable role per control, inside the company.
  • MUST flag every perform-and-approve conflict and every single-person role without a deputy.
  • MUST write outputs only inside ./control-owner-raci/ and ask before overwriting.
  • NEVER put personal names in the RACI table; use roles.
  • NEVER record an owner as having accepted a role; the owner confirms it.
  • NEVER assign accountability for a control to a supplier.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

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.

The English summary is being prepared. Showing the original description.

better-isms/grcskills10Updated Oct 20, 2026

See all skills by better-isms

Report a problem with this skill