The Data Processing Agreement Is an Architecture Decision

Procurement signs the DPA. Engineering never reads it. Then a subprocessor notice lands in a mailbox nobody watches, and the right to object turns out to mean terminate, not refuse. Article 28 clauses are engineering requirements with a signature block attached, and the ones that constrain architecture are rarely the ones redlined.

Eight Obligations, Eight Control Surfaces

Article 28(1) does not ask whether you trust a vendor: the controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures" — guarantees, plural, and sufficient against a standard someone must assess. Article 28(3) then lists what the contract must bind the processor to, lettered (a) through (h): documented instructions only; confidentiality commitments; the Article 32 measures; the paragraph 2 and 4 conditions before engaging another processor; assistance with data-subject requests; assistance with Articles 32 to 36; deletion or return at the end of the service; and information plus audits, including inspections.

Read that list as capabilities, not promises: each letter names something that must be observable, enforceable and evidenced in a running system; the contract only decides which side of the boundary it sits on. Article 28(4) closes the chain — where a sub-processor "fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller." Liability flows to your counterparty; accountability never leaves the controller. The security half of this is Article 32 work. This is the contract half.

Click to zoom

The Right to Object Is a Right to Leave

Article 28(2) is the clause everyone thinks they understand. Under general written authorisation, "the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes." The Regulation does not say what objecting achieves, nor how much notice you get — the Commission's own clauses leave that blank. In the transfer clauses of Decision (EU) 2021/914, Clause 9(a) Option 2 reads "at least [ Specify time period ] in advance"; the Article 28(7) clauses of Decision (EU) 2021/915 leave the same blank at Clause 7.7(a) Option 2.

Both hyperscalers fill it with at least 30 days, each measured from a different event. The AWS DPA, as published on 3 September 2026: "At least 30 days before AWS engages a Sub-processor, AWS will update the applicable website and provide Customer with a mechanism to obtain notice of that update." The Google Cloud DPA, Section 11.4(a): notice "at least 30 days before the New Subprocessor starts processing any Customer Data." Both are lead time, but before different events: AWS engaging the sub-processor, the New Subprocessor starting to process Customer Data. A register storing "30 days" for both has lost the distinction.

What the objection buys diverges further. Under the AWS DPA a customer objects by "(i) terminate the Agreement pursuant to its terms; (ii) cease using the Service for which AWS has engaged the Sub-processor; or (iii) move the relevant Customer Data to another Region where AWS has not engaged the Sub-processor." Three remedies, all yours to execute, none of them making AWS stop. The Google Cloud DPA's general terms, Section 11.4(b), give one: object "by immediately terminating the applicable Agreement for convenience" within 90 days of being notified. That is the path for Google Cloud Services, and not the only one in the document.

One more trap: that 30 days is lead time, not a deadline for objecting. Google's objection window is a separate 90 days from notification; the AWS DPA states none at all. One shared "objection window" field across a vendor list produces a date wrong for every vendor on it.

Click to zoom

A Subprocessor Register You Can Diff

EDPB Opinion 22/2024, adopted 7 October 2024, is blunt about what a controller must produce: the "identity (i.e. name, address, contact person) of all processors, sub-processors etc." must be "readily available at all times," and the processor "should proactively provide to the controller all this information and should keep them up to date at all times." Readily available at all times is not a PDF attached to a 2023 procurement ticket. It is a data structure.

The register below is a proposed design, not a regulator's template. The EDPB requires the identity, at every level of the chain, on demand; the notice and objection fields are this article's addition, because a register recording only who processes cannot tell you what you can do about it.

version: 3
generated_at: "2026-09-03T00:00:00Z"
processing_activities:
  - id: PA-014
    name: Customer support ticketing
    processors:
      - depth: 1
        name: Example Cloud Ltd
        address: "1 Example Way, Dublin 2, Ireland"
        contact_person: dpo@example.com
        authorisation: general            # general | specific
        notice_days: 30
        notice_trigger: engagement        # engagement | start_of_processing
        notice_channel: vendor_page       # vendor_page | email
        objection_remedy:
          - terminate_agreement
          - cease_affected_service
          - relocate_region
        objection_deadline_days: null     # this DPA states none
        subprocessors:
          - depth: 2
            name: Example Relay BV
            address: "Voorbeeldstraat 1, Amsterdam, Netherlands"
            contact_person: privacy@example.com
            country: NL
            activity: transactional email delivery
            source: vendor_page
            first_seen: "2026-04-11"

A register is only as current as whatever updates it, and the two vendors deliver notice differently. For AWS the website update quoted above is the notice, plus a mechanism to subscribe — an event you observe. Google delivers to you: Section 13 sends Addendum notices "to the Notification Email Address," and its subprocessors page says a customer with a designated address need not subscribe. Google's 90-day clock runs from that email, not from a page edit; the published list is only a reconciliation source. A detector that fetches, normalises, hashes and diffs is the observer for AWS and a second pair of eyes for Google — with one caveat: a hash over a public page also fires on nav chrome, cookie banners and layout churn, so triage is human.

#!/usr/bin/env bash
set -euo pipefail

STATE_DIR="${STATE_DIR:-.subprocessor-state}"
mkdir -p "$STATE_DIR"
changed=0

# vendors.tsv: vendor, url, notice_days, objection_deadline_days, channel
#   objection_deadline_days: positive integer (Google Cloud: 90), or EMPTY when
#   the DPA states none (AWS). Empty is not zero.
#   channel: vendor_page (the page IS the notice) | email (page is only a
#   reconciliation source; the clock runs from the notice email).
while IFS=$'\t' read -r vendor url notice_days deadline_days channel; do
  [ -z "${vendor:-}" ] && continue

  hash="$(curl -fsSL --max-time 30 "$url" \
    | sed -e 's/<[^>]*>/ /g' -e 's/[[:space:]][[:space:]]*/ /g' \
    | tr ' ' '\n' | sed '/^$/d' | LC_ALL=C sort | sha256sum | cut -c1-64)"

  prev_file="$STATE_DIR/$vendor.sha256"
  prev="$(cat "$prev_file" 2>/dev/null || true)"
  printf '%s\n' "$hash" > "$prev_file"

  if [ -n "$prev" ] && [ "$prev" != "$hash" ]; then
    observed="$(date -u +%Y-%m-%d)"
    if [ "${channel:-}" = email ]; then
      deadline=pending_email_notice   # a page edit is not the notice; reconcile
    elif [[ "${deadline_days:-}" =~ ^[1-9][0-9]*$ ]]; then
      deadline="$(date -u -d "$observed + $deadline_days days" +%Y-%m-%d)"
    else
      deadline=none
    fi
    printf 'page_observed=%s\tvendor=%s\tnotice_days=%s\tobjection_deadline=%s\n' \
      "$observed" "$vendor" "$notice_days" "$deadline" >> "$STATE_DIR/notices.tsv"
    changed=1
  fi
done < vendors.tsv

[ "$changed" -eq 0 ] || { echo "vendor page changed - triage required"; exit 2; }

The Audit Right and What It Actually Buys

Article 28(3)(h) is the strongest-sounding sentence in the article: audits, "including inspections," by the controller or an auditor it mandates. Clause 8.9(d) of the Module Two transfer clauses agrees — "Audits may include inspections at the premises or physical facilities of the data importer." Then read what your own contract does with that right.

The AWS DPA spends it in advance. The customer "chooses to conduct any audit, including any inspection … by instructing AWS to carry out the audit described in Section 10" — the audit AWS already performs "at least annually," to "ISO 27001 standards or such other alternative standards that are substantially equivalent," by third-party professionals "at AWS's selection and expense," producing a report that is AWS's Confidential Information. If AWS "declines to follow any instruction requested by Customer regarding audits, including inspections, Customer is entitled to terminate the Agreement."

The Google Cloud DPA forks instead. Section 7.5.2(a) offers an inspection-style audit only "if required under Applicable Privacy Law," and Section 7.5.3(b)(ii) has the parties agree in advance on "the reasonable start date, scope and duration of" it. Section 7.5.2(b) then gives an unconditional second route: the customer "may conduct an audit … by reviewing the Security Documentation (which reflects the outcome of audits conducted by Google's Third-Party Auditor)."

Neither shape hands you the unmediated inspection right Article 28(3)(h) describes: AWS substitutes its own audit, Google conditions and pre-schedules yours. Opinion 22/2024 says the controller "does not have a duty to systematically ask for the sub-processing contracts," but that in exercising its 28(3)(h) right it "should have a process in place to undertake audit campaigns in order to check by sampling verifications that the contracts with its sub-processors contain the necessary data protection obligations." A scheduled programme with a sample frame and retained findings — the discipline of any third-party risk instrument, applied to contract text. Financial entities carry a heavier statutory version under DORA.

Deletion You Can Evidence, Not Just Request

The entitlement to a deletion certificate does not come from Article 28(3)(g): that requires the processor, at the controller's choice, to delete or return the data and delete existing copies, and stops. Certification is a standard-clauses artefact — Module Two Clause 8.5 of Decision (EU) 2021/914 has the importer "delete all personal data … and certify to the data exporter that it has done so," and the Article 28(7) clauses of Decision (EU) 2021/915 say the same at Clause 10(d).

Do those clauses even attach to your data? The AWS DPA states that "the Standard Contractual Clauses will only apply to Customer Data subject to the GDPR that is transferred … to any Third Country." Read plainly, a controller that kept its data in an EEA Region is outside the trigger for the SCCs, and so outside the clause carrying the certification duty — clause text, not a supervisory-authority finding, so check the contract you hold. What AWS gives is self-service deletion through Service Controls, up to the termination date and for 90 days after. Google's Section 6.2 runs a different schedule: deletion after "a recovery period of up to 30 days," then "within a maximum period of 180 days." Neither attaches a certificate.

So generate the evidence yourself. An attestation your own systems emit beats a vendor PDF: it names the systems, the method and a query anyone can re-run — the same artefact a CCPA deletion pipeline needs, and the one thing entirely within your control.

{
  "attestation_id": "DEL-2026-0912",
  "instruction_ref": "DPA-2024-118 s6.2 controller instruction 2026-09-01",
  "scope": {
    "processing_activity": "PA-014",
    "data_categories": ["contact details", "support ticket content"],
    "period": { "from": "2021-06-01", "to": "2026-08-31" }
  },
  "systems": [
    {
      "system": "postgres/support",
      "method": "row delete + VACUUM FULL",
      "rows": 4182233,
      "completed_at": "2026-09-01T22:14:05Z"
    },
    {
      "system": "s3/support-attachments",
      "method": "key destruction",
      "key_id": "kms/tenant-014",
      "completed_at": "2026-09-01T22:31:40Z"
    },
    {
      "system": "backup/borg-support",
      "method": "crypto-shredding, key destroyed",
      "key_id": "kms/backup-014",
      "completed_at": "2026-09-02T03:02:11Z"
    }
  ],
  "residual": [
    { "system": "wal-archive", "reason": "statutory bookkeeping law", "expires": "2026-11-30" }
  ],
  "verification_query": "SELECT count(*) FROM support.tickets WHERE tenant_id = '014'",
  "verification_result": 0,
  "operator": "platform-oncall"
}

Annex II Is a Configuration Document

That sentence invalidates most of what gets pasted into the annex. Note the instrument: Annex II belongs to the transfer clauses of Decision (EU) 2021/914, while the Article 28(7) clauses of Decision (EU) 2021/915 carry theirs in Annex III — mislabelling them is the fastest way to lose an auditor's confidence. Nor are the clauses decorative: Clause 5 of the transfer set provides that where they contradict related agreements, "these Clauses shall prevail."

Specific and not generic means the annex describes running configuration — so generate it from configuration. Give every measure a control, the enforcing system, and an evidence query returning zero rows.

generated_at: "2026-09-03T04:00:00Z"
source_of_truth: cluster-state
measures:
  - id: M-01
    measure: Encryption of personal data at rest
    control: LUKS2 on node volumes; envelope encryption for object storage
    enforced_by: policy/kyverno/require-encrypted-storageclass.yaml
    evidence_query: >-
      SELECT namespace, pvc FROM volumes WHERE encrypted = false
    expected_rows: 0
  - id: M-02
    measure: Pseudonymisation of identifiers in analytics
    control: HMAC-SHA256 under a per-tenant KMS key, rotated every 90 days
    enforced_by: services/etl/pseudonymise.py
    evidence_query: >-
      SELECT column_name FROM analytics.columns
      WHERE classification = 'direct_identifier'
    expected_rows: 0
  - id: M-03
    measure: Logging of access to personal data
    control: audit policy at RequestResponse for secrets; 400-day retention
    enforced_by: cluster/audit-policy.yaml
    evidence_query: SELECT day FROM audit_index WHERE events = 0
    expected_rows: 0

Breach Clocks: The Processor Has No Number

Article 33(1) puts a number on the controller: notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it." Article 33(2) puts none on the processor — it "shall notify the controller without undue delay." A hard deadline resting on a soft one, and the gap is entirely contractual.

Two consequences. First, the number belongs in the DPA, because the Regulation will not supply it: a duty expressed only as "without undue delay" leaves you counting 72 hours from a moment the vendor controls. Second, awareness has to be instrumented on your side — if the only detection path for a breach in a processor's estate is that processor's own notice, your clock starts when their process decides it should. Detection you own keeps the 72 hours from being spent before it starts — the same reasoning behind India's DPDP breach workflows.

The Clause That Is Not an Instruction

Both DPAs read here carry a variant of "unless required to do so by law or binding order of a governmental body." EDPB Opinion 22/2024 addresses it twice, and quoting one half misrepresents the regulator. On permissibility, the Board "takes the view that including wording similar to … is a prerogative of the contractual freedom of the parties and does not infringe Article 28(3)(a) GDPR per se." The clause is allowed to be there.

On effect, the Board is equally clear that the same wording "cannot be construed as a documented instruction by the controller," and that "the controller remains responsible where it has not ensured that the (sub-)processor processes personal data only on its documented instructions" — with a carve-out where processing is required by EU or Member State law, or by third-country law that "ensures an essentially equivalent level of protection." Permitted in the contract; not a substitute for your instructions.

This lands on regional pinning. The AWS DPA commits that once a customer has chosen its Regions, "AWS will not transfer Customer Data from Customer's selected Region(s) except as necessary to provide the Services initiated by Customer, or as necessary to comply with the law or valid and binding order of a governmental body." An honestly stated exception, and the one Schrems II turns on. Treat a Region setting as a configuration fact you assert and monitor, not a guarantee inherited by signing.

Exit Ramps: When the DPA Is Not Negotiable

These DPAs are offered, not negotiated. The useful question is not whether a redline is accepted, but which control surface the contract leaves you holding — and whether you can hold it.

1. List the missing surfaces per processing activity, not per vendor. A pre-spent audit right is tolerable for a marketing tool and not for the system of record on special-category data.
2. Try the clauses that move. A stated number for processor breach notification; subprocessor notice measured from a defined event, with an objection remedy other than termination; a deletion attestation on request. The reply itself is a due-diligence signal.
3. Price the exit before you need it. The objection remedy in both DPAs read here is a form of leaving, so that right is worth exactly your exit cost. An objection you cannot afford to exercise is not a right.
4. Where the gap is structural, move the processing. Run that leg yourself and the subprocessor clause, the objection window and the pre-spent audit right all disappear, because the counterparty does.

That option is not free. Self-hosting removes the contract, not the obligation: every artefact in the first diagram's right-hand column is still required, and the security, availability and evidence work the processor was doing becomes yours. What changes is the failure mode — you stop discovering, thirty days late, that a decision about your data was taken in a document you do not control.

The Contract Expires; the Control Surface Does Not

Every vendor quotation here was read from the published document on 3 September 2026. Both vendors amend these terms unilaterally and section numbers move. That is the point, not a caveat — a DPA changes without your signature, so re-read it on a schedule and diff it.

Put three recurring events in the calendar: re-read each material DPA at renewal and on any amendment notice; re-run the sampling audit campaign; regenerate the Annex II manifest from live state and confirm the evidence queries still return zero. Ten years of that produces what a signature never will — a controller who can say, from artefacts rather than assurances, who processes what, under which authorisation, with what recourse.