The Renewed DPA Was Accepted but Processing Used the Wrong Version: Hold and Correct

A DPA renewal can be accepted while an older version remains active in a vendor portal. It may also remain active in an internal system. Procurement records and provider instructions can retain it too. That creates a gap between the agreement on file and the terms under which people may still be processing personal data.

Hold the work tied to terms you cannot reconcile. Then trace the accepted version through every affected system and provider before restarting it. The ICO accountability guide says organizations must be able to demonstrate compliance. They must use written contracts with processors and maintain processing documentation. They must also review measures when necessary.

How do you detect that the wrong DPA version is applied?

Start with a version comparison, not a general compliance review. Put the accepted renewal beside the version named in the provider contract record. Then check the data-processing register, purchase record, onboarding ticket, and operational instructions.

A mismatch exists when the identifier or effective date differs. It also exists when the parties, processing instructions, approved provider list, and retention terms differ. It also exists when security obligations differ. The same applies to international-transfer terms and amendment references. Do not assume a later file name means the later terms were applied.

The EDPB's final controller and processor guidelines, dated July 7, 2021, address the controller and processor concepts under the GDPR. Use the agreement and the actual operating record to establish what your own parties agreed and applied.

• Capture the accepted agreement's exact file name and version. Also capture its effective date. Record the signatories and storage location.
• Capture the applied agreement reference from each affected provider and system.
• Record the first date you can confirm that the applied version was in use.
• Mark each difference as operationally relevant. Note separately whether it is pending legal review or no longer applicable.

Which processing should pause during a DPA version mismatch?

Pause processing that depends on a term where the accepted and applied versions differ and the correct instruction is not confirmed. That can include a provider onboarding step or a new data flow. It can also include a subprocessor change. A retention action or access change may also be included.

Do not expand the hold beyond what the mismatch requires. Separate processing that has a confirmed current agreement record from processing where the controlling terms are unclear. Escalate the boundary to the contract owner. Involve the privacy lead or legal adviser as needed where the documents do not settle it.

The ICO says accountability is ongoing and requires organizations to review and update their measures as necessary. Its guidance also says contracts with processors help establish each party's responsibilities and liabilities.

• Hold new processing instructions under the disputed version.
• Hold provider changes that rely on a term you cannot map to the accepted renewal.
• Keep a dated record of the hold. Name the decision owner and the condition for release.

What should a DPA implementation-reconciliation record contain?

Use one record for the mismatch. It should let a reviewer see the accepted agreement and the applied agreement. It should also show the affected processing and correction route. Include evidence that the correction reached every relevant place.

This is an operating record, not a substitute for legal advice or the agreement itself. Keep copies or stable references to the documents named in the record.

How do you propagate the correct DPA version across providers and systems?

Assign one owner to the accepted version and one owner to each correction. Give each provider or system a written instruction that identifies the exact version to apply and the affected processing. It should state the required correction and the evidence required for closure.

Update the agreement repository and processor register. Update operational runbooks, the procurement record, and provider-facing instructions where they refer to the old version. A closed ticket without proof that the provider or system now references the correct agreement is not verification.

The ICO accountability and governance guidance identifies contracts and documentation. It also identifies data protection by design and default, along with impact assessments among its accountability and governance resources. Use the record to connect the contract correction to the operational controls that rely on it.

• Send the corrected version reference to every affected provider and internal system owner.
• Request a written confirmation or system evidence that identifies the version now applied.
• Compare the returned evidence against the accepted agreement and the reconciliation record.
• Close each affected processing item only after the reviewer records the verification result.

How do you verify that the corrected version is actually live?

Verification should test the places where the wrong version was found. If an older identifier appeared in a provider portal, confirm that portal now identifies the accepted version. If the mismatch appeared in an instruction or register, confirm the corrected record and its effective date.

Keep the before-and-after evidence and reviewer name. Also keep the verification date and any remaining exceptions in the reconciliation record. The ICO says that organizations need to keep evidence of steps they take to comply, and that accountability measures should be reviewed and updated where necessary.

• Check the agreement reference in each affected provider or system.
• Check that operating instructions and processing documentation point to the accepted version.
• Confirm that any hold was released only for processing with a documented correction.
• Record exceptions that remain open, the owner for each. State the next evidence needed to close it.