grcskills
Menu

Privacy and AI control applicability

Use this skill when a company with a security applicability statement extends its management system to privacy or to AI, and asks "extend our SoA for privacy", "which privacy controls apply to a processor", "AI controls applicability", "SoA for our AI management system", "are we controller or processor for this" or "do the AI development controls apply if we only use a model". Settles the company's role per processing activity and per AI system, decides applicability of the additional controls from those roles and the risk or impact assessments, and writes an extension to the applicability statement plus role and scope notes.

Statement of applicabilityISO 27701ISO 42001

Use this when a privacy or AI extension is added to an existing security management system, and again when a new product, processing activity or AI system enters scope. You get two files in a new folder, ./privacy-and-ai-control-applicability/: a spreadsheet you can open in Excel listing each extra privacy or AI control, whether it applies and why, in the same layout as your existing applicability statement (soa-extension.csv), and notes recording the company's role for each processing activity and AI system, with open questions (role-and-scope-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Role decisions with legal effect are confirmed by the company's privacy or legal owner.

Inputs to gather

For privacy: the records of processing, data processing agreements (both directions), the privacy notice, the subprocessor list and impact assessments. For AI: the AI system inventory, product documentation, model and vendor contracts, and AI impact or risk assessments. For both: the existing statement of applicability, the risk register and the scope statement. Load the additional control identifiers from the reader's licensed copy of the extension standard or their compliance platform; if neither is available, stop and ask. Ask the reader which extension is in scope and who confirms role decisions.

Step 1: settle roles, activity by activity

Privacy. For each processing activity, decide whether the company determines why and how the data is processed (controller), processes it only on a customer's instructions (processor), decides jointly with a partner (joint controller, which needs a GDPR Article 26 arrangement), or holds different roles across different activities. Base each decision on the contract and on what actually happens, not the preferred label. Patterns to check: every employer is a controller for staff data; marketing lists, product analytics and support tooling are usually controller activities even for a company that sells a processor service; using customer data to improve the product moves that use towards controller.

AI. For each AI system, record what the company does with it: develops or trains a model, builds a system on a third-party model (prompts, retrieval, tools, fine-tuning), supplies AI components to others, or uses an AI tool internally. One company often holds several roles across systems. Building a product feature on a hosted model is more than use. Where the EU AI Act may apply, record the likely provider or deployer classification per system as a flag for the legal owner, not a determination.

Write the role table in the notes (role-and-scope-notes.md) with the source for each decision.

Step 2: map roles to candidate controls

Which additional controls are candidates depends on the roles from step 1. Run a framework lookup or read the licensed text to find which controls attach to each privacy role and to each kind of AI activity; never assume that link from memory. A control is a candidate whenever at least one in-scope activity or system holds a matching role.

Step 3: decide each control

For each candidate control record: control id (bare identifier), included or excluded, the role and the activity or AI system that drives it, the risk or impact assessment id, the obligation or commitment id where a law or contract is the reason, implementation status, evidence path and owner role. Exclude only on a fact about roles or activities ("no AI system is trained or fine-tuned by the company; all models are used through vendor APIs without customer data in training; see the AI inventory and vendor terms"). Every exclusion carries a revisit trigger that names its signal (a contract renewal, a new model vendor, a roadmap event, an annual re-check) and the role that watches for it. Flag, outside the control list, obligations the role table triggers: whether the company needs a data protection officer (GDPR Article 37) and which activities transfer data outside the EU and need Chapter V safeguards.

Step 4: connect to the security statement

Many additional controls are delivered by practices the security statement already covers. Then reference the security control id and its evidence instead of creating a parallel record, and note what the extension adds on top (purpose limitation, transparency to individuals, impact on affected people, data quality for models). Check for contradictions between the two statements; an excluded security control that a privacy or AI control depends on is a defect to raise.

Step 5: write the extension

Write the extension spreadsheet (soa-extension.csv) in the same column layout as the security statement plus three columns: extension, role, activity or system. Add the open role questions, the controls awaiting a fact, and the approver role to the notes. An extension also adds management system elements that are not controls (for AI, impact assessment, objectives and responsibilities, for example); run a framework lookup and list them separately for the approver, since the control flow will not surface them. Ask before overwriting either file.

What good looks like

  • Roles are decided per activity and per system with a source, and the controller and processor split matches the contracts.
  • The common mistake is declaring "processor only" or "AI user only" to exclude whole control groups. The tell is an extension with no controller rows in a company that has employees and a marketing list, or no development rows in a company whose product ships an AI feature.
  • Each inclusion points to a role and a risk or impact assessment id; each exclusion to a checkable fact and a revisit trigger.
  • The approver can read the role table in five minutes and agree or correct it before the controls are argued.

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-and-ai-control-applicability

Rules

  • MUST decide the role per processing activity and per AI system, citing the contract or record behind it.
  • MUST take additional control identifiers and their role grouping from the reader's licensed source or a framework lookup.
  • MUST write outputs only inside ./privacy-and-ai-control-applicability/ and ask before overwriting.
  • NEVER exclude a control group on a role claim the contracts or records contradict.
  • NEVER copy personal data from processing records into the outputs; describe activities and categories.
  • NEVER write official control titles or requirement text; use bare identifiers and the company's own words.