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: