grcskills
Menu

Records of processing first draft

Use this skill when a company needs its record of processing activities for the first time, or has one that is really a list of tools, and asks "build our RoPA", "records of processing", "data map for GDPR", "Article 30 record", "what personal data do we process and why", "data inventory for privacy" or "our DPO needs a processing register". Drafts the record by processing activity from systems, vendors and team interviews, with purposes, data and subject categories, proposed legal bases, recipients, transfers and concrete retention, plus a separate processor record when the company processes data for customers, and a notes file of open questions per owner.

PrivacyGDPRISO 27701

Use this when there is no record, when the record is a system inventory with a privacy heading, or after new products, markets or vendors changed the processing. You get two or three files in a new folder, ./ropa-first-draft/: a spreadsheet you can open in Excel listing everything the company does with personal data for its own purposes, one row per activity with its data, people, legal basis and retention (ropa-controller.csv); a second spreadsheet for the data the company handles on behalf of customers, only if it does (ropa-processor.csv); and a short note of open questions per team (ropa-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Legal bases and retention periods are decisions for the controller's privacy lead or counsel; the agent proposes them.

Inputs to gather

Read before asking: the system and application inventory, the vendor list and signed data processing agreements, the privacy notice and cookie settings, the product data model or schema descriptions, HR and payroll system lists, marketing and sales tool lists, retention settings where the agent can see them, and customer contracts that make the company a processor. Ask the reader, in one message: which teams own which processing (HR, sales, marketing, support, product, finance, IT), whether the company processes data on behalf of customers, and who can confirm legal bases.

Step 1: list activities by purpose, not by system

A processing activity is a purpose with its data, people and systems: "payroll", "recruiting", "customer support tickets", "product analytics", "newsletter", "fraud screening". One system can serve several activities; one activity can span several systems. Walk team by team and list the activities. A company of 20 to 300 people usually lands at 15 to 40 controller activities. Fewer than 10 means purposes have been lumped ("business operations"); split them where the legal basis, retention or data subjects differ.

Step 2: fill each row

Article 30 of the GDPR sets out what the record covers; use it as the backbone and add the columns the rest of the programme needs. Per activity, one row of the controller spreadsheet (ropa-controller.csv):

  • Purpose in one plain sentence, owner role, and whether the company is controller, joint controller or processor for it. A joint controller row points to its Article 26 arrangement, or the missing arrangement becomes an open question.
  • Data subject categories and personal data categories. Flag special category data (Article 9) and criminal offence data (Article 10) in their own column.
  • Proposed legal basis under Article 6, and for special category data the Article 9 condition. Where the proposal is legitimate interests, add a line to the notes: a balancing test is needed. Consent is rarely the right basis for employee data, because of the imbalance between employer and employee.
  • Source of the data (the person, the customer, a third party, public sources).
  • Systems used, and recipients: internal teams, processors, other controllers.
  • Transfers outside the EEA, with destination and the mechanism the contracts rely on, or "unknown".
  • Retention as a period plus the trigger that starts it ("7 years after the end of the financial year", "6 months after the recruitment decision"), with the reason (law, contract, defence of claims, business need). "As long as necessary" is not a retention period.
  • A pointer to the security measures that cover the systems, not a copy of them.

Step 3: draft the processor record if it applies

If the company processes personal data for customers (a software provider hosting customer data, for example), keep a separate record, the processor spreadsheet (ropa-processor.csv), organised by service: categories of processing done for customers, sub-processors, transfers, and security measures. Do not list every customer by name; the record describes processing categories, and the customer list stays in the contract system.

Step 4: cross-check and collect questions

  • Every vendor in the vendor list that touches personal data appears as a recipient somewhere; every recipient has an agreement. List mismatches.
  • Every purpose in the privacy notice appears in the record and the reverse. List mismatches for a privacy notice gap check.
  • Every transfer marked "unknown" becomes an open question with an owner and a date; no transfer should continue past the review without a documented mechanism.
  • Activities with special category data, large-scale monitoring, profiling or new technology go on a list of DPIA screening candidates, each with the trigger that put it there, so the privacy lead's decision is documented.
  • Write the open questions per owner role in the notes file (ropa-notes.md), so confirmation is a short session per team. Name the role that maintains the record and a review date per team; the supervisory authority can ask for it at any time.

The general exemption for organisations under 250 employees is narrow: it does not apply when processing is more than occasional, carries risk, or involves special category data or criminal offence data. Do not rely on it without counsel's view.

What good looks like

  • The best practitioner starts with HR and payroll, because every company has employee data with long retention and special category fields, and that is the part most often forgotten.
  • The common mistake is a renamed system inventory: one row per tool, purpose "business operations", legal basis "consent" everywhere, retention "as long as necessary". The tell: rows named after software products, and no row that a team member would recognise as something they do.
  • Good output has activities a team owner recognises, a legal basis per purpose, retention with a trigger and a reason, every processor reconciled with the vendor list, and an open-question list short enough to close in a week.

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-ropa-first-draft

Rules

  • MUST organise the record by processing activity and purpose, never by system alone.
  • MUST mark every proposed legal basis and retention period as proposed until the privacy lead confirms it.
  • MUST write outputs only inside ./ropa-first-draft/ and ask before overwriting.
  • NEVER copy actual personal data, customer names or employee names into the record; record categories.
  • NEVER mark a transfer mechanism as in place without the contract that shows it.
  • NEVER rely on the small-organisation exemption without counsel's documented view.