grcskills
Menu

Data processing agreement security annex review

Use this skill when a data processing agreement is being negotiated or renewed and someone asks "review the TOMs annex", "check the security measures in this DPA", "can we sign this annex", "the customer sent their DPA with a security schedule", "is our standard annex still true" or "does this vendor's annex promise enough". Breaks the technical and organisational measures annex into single commitments, compares each one with what the company actually runs or with what the use case needs, and writes a line-by-line review, proposed redlines and a list of practice gaps for owners.

Vendors and third partiesGDPR

Use this for one agreement at a time, or once a year on the company's own standard annex, and earlier when a subprocessor changes, a new tool touches the data, a security incident happens or a certificate lapses. You get three files in a new subfolder per agreement, ./dpa-security-annex-review/<agreement>/: a spreadsheet you can open in Excel with one line per security promise in the annex, whether it is true today and the proof (annex-review.csv); the wording changes to propose in the negotiation, each with a one-line reason (redlines.md); and a list of promises the company does not keep today, with an owner and a fix (practice-gaps.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The reader's legal counsel or data protection officer decides what is signed.

Inputs to gather

Read the agreement and its security annex, the company's security policies, subprocessor list, incident response plan, and any assurance report or certificate. Ask the reader, in one message: is the company the processor making these promises, or the controller receiving them from a supplier; what personal data and volume the agreement covers; whether the other party wrote the annex or the company's own template is used; and the negotiation deadline.

Step 1: establish the direction

The same annex is read two ways. As a processor, the company is promising: the risk is over-promising, because every measure in the annex becomes a contractual obligation and a potential breach. As a controller, the company is receiving: the risk is vague measures that commit the supplier to nothing. GDPR Art. 28 sets what a processor contract covers, and Art. 32 asks for security appropriate to the risk; this skill does not interpret either beyond that. For any question on what the law or a supervisory authority expects in the annex, run a framework lookup or ask counsel.

Step 2: split the annex into single commitments

One row per commitment, in the review spreadsheet (annex-review.csv): the annex wording copied unchanged, the topic (access, encryption, logging, backup, incident notice, staff, physical, testing, deletion, subprocessors, location), and whether it is specific and testable ("multi-factor authentication for all administrative access") or vague ("appropriate access controls").

Step 3: test each commitment against reality

Record the agreement and annex version and the review date; counterparties update annexes without saying so. As processor, compare each commitment with what the company runs, and record the evidence path, pointing to evidence the company already keeps for its controls (logs, test reports, the control register) rather than building a parallel set:

  • True and evidenced: a configuration, record or report shows it.
  • True, no evidence at hand: the owner believes it; find the record.
  • Partly true: true for some systems, data or times only. A frequent example: encryption at rest promised everywhere, while one backup bucket or a support tool export is not covered.
  • Not true: an annual penetration test promised and none performed; round-the-clock monitoring promised and one engineer on call; data kept in one region promised while a support or analytics tool processes it elsewhere.

Check every location promise against the subprocessor list and where each subprocessor processes; support and analytics tools are where those promises break. Check the deletion promise against backup rotation: deletion or return at the end of the contract is an Art. 28(3)(g) term, and the honest wording says data in backups is put beyond use and removed as backups rotate.

As controller, test each commitment against the use case instead: does it cover the data and risk the company is handing over, and is it specific enough to check?

Step 4: propose redlines

For each gap choose a side and say which: change the practice (owner, effort and date for the owner to agree), or change the text to accurate, outcome-focused wording that will stay true. Avoid numbers the company cannot hold, such as a fixed hour count for incident notice that is shorter than the main agreement or the incident plan allows. The notice must still leave the controller time to meet its own 72-hour deadline to the supervisory authority under Art. 33, so the processor commitment is "without undue delay" plus a number the incident plan can actually deliver. Keep the annex consistent with the main agreement body, the subprocessor list and the incident plan; contradictions between them are what the other side's lawyers find first. As controller, propose the specific measures the use case needs in place of vague ones.

Step 5: write the outputs

annex-review.csv: commitment, topic, specificity, status, evidence path, proposed change. redlines.md: the proposed wording change per line, with a one-line reason the reader can paste into the negotiation. practice-gaps.md: each commitment that is not true today, with the owner role and the proposed fix; draft the material ones as proposed risk register entries for the risk owner to add.

If the output folder exists, ask before overwriting and offer a new subfolder instead.

What good looks like

  • Every commitment is tested one by one; the review reads like a checklist with evidence, not an opinion on the annex.
  • The common mistake is a long generic list of measures copied from a template into the company's own annex. The tell: the annex names tools, certifications or a security team the company does not have, and nobody can show the record for half the lines.
  • Gaps are resolved on the right side: real weaknesses get fixed, over-specific promises get rewritten.
  • The annex, the main agreement, the subprocessor list and the incident plan say the same thing about the same topic.
  • As controller, the reviewer can say in one line why the supplier's measures fit the data the company sends.

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-dpa-security-annex-review

Rules

  • MUST copy each annex commitment unchanged before assessing it.
  • MUST flag every processor commitment that is not true today, with its evidence status.
  • MUST write outputs only inside ./dpa-security-annex-review/ and ask before overwriting.
  • NEVER sign, accept or send redlines to the other party; counsel or the data protection officer decides.
  • NEVER present the review as legal advice.
  • NEVER copy personal data from the agreement or its schedules into the outputs; use roles.