# DPA and MSA review checklist for security teams

URL: https://wolfia.com/blog/dpa-msa-review-checklist-security-teams
Description: The clauses in a DPA and an MSA that a security team, not legal, has to answer, and how to keep those answers consistent with your questionnaire responses.
Last updated: 2026-09-03

## TL;DR

- A DPA and an MSA arrive together, but only some of their clauses are actually legal questions. The rest assert a security control and belong to your security team.
- The clauses security owns are the security measures exhibit, breach notification, subprocessors, audit rights, data location and transfer, and retention and deletion.
- Answer each one against a control you can evidence today, not against the control you plan to have.
- The most common failure is not a bad clause, it is a contradiction between the contract and the security questionnaire you sent the same buyer.
- Working from one corpus of approved facts across both documents is what keeps them aligned as controls change.

## Why the split matters

A master services agreement sets the commercial relationship. A data processing agreement governs personal data and usually hangs off the MSA, with a security measures exhibit hanging off the DPA in turn. Buyers send all three as one package and expect one response on one deadline.

The instinct is to route the whole package to legal. That is the right home for liability, indemnity, governing law, and the negotiation, and the wrong home for a surprising number of the clauses inside, because those clauses are not asking what risk you will accept. They are asking what your systems actually do. Nobody in legal can answer whether your logs are retained for the period the buyer wrote into the exhibit.

So the useful first move on any DPA and MSA package is a split. Mark the clauses that assert a control, hand those to security, and leave the rest with counsel. The checklist below is the security half.

## The security half of the checklist

### Security measures exhibit

This is the annex that lists encryption, access control, logging, vulnerability management, and personnel security. Read every line as a commitment you will be audited against, because that is what it is.

The trap is the aspirational yes. A control that is planned, partially rolled out, or true for the production environment but not the staging one is a control you should not be signing. Check each item against the same evidence you would produce for a customer audit, and note where the exhibit is more specific than your own policy, since that gap is where a future finding lives.

### Breach notification

Two things need checking, the trigger and the clock.

The trigger decides what counts as a reportable event. A clause worded around any unauthorised access to systems is broader than one worded around a personal data breach, and the broader wording can oblige you to report events that never touched customer data.

The clock decides how fast. GDPR Article 33 requires the controller to notify the supervisory authority within 72 hours where feasible, and requires the processor to notify the controller without undue delay. Buyers frequently convert that into a fixed number of hours for you. Before agreeing, confirm your on-call process can meet it over a weekend and a holiday, not just on a Tuesday.

### Subprocessors

Confirm three things. That the contract accepts a published subprocessor list rather than an appendix frozen at signature. That change notice is a notice period with a right to object, which is the structure GDPR Article 28 contemplates under a general written authorisation. And that your own flow-down obligations to those subprocessors match what you are promising the buyer here.

Prior written consent for every change reads harmless and hands one customer a veto over your infrastructure roadmap.

### Audit and evidence rights

Most audit clauses can be satisfied with a SOC 2 Type II report, a penetration test summary, and a completed questionnaire. Some ask for on-site access with little notice, or for the buyer's own auditors to test your production systems.

Check what the clause obliges you to provide, how often, at whose cost, and with how much notice. Then check it against what you already publish, because a clause that asks only for what already sits on your trust center costs you nothing to accept.

### Data location and transfer mechanism

Confirm where the data is stored, where it is processed, where support staff access it from, and which transfer mechanism applies to each of those. For transfers out of the EEA the standard route is the European Commission's standard contractual clauses adopted in 2021, with the UK addendum where UK data is in scope.

Support access is the one teams forget. Storage may be regional while a support engineer views the same data from somewhere else, and the DPA needs to describe what actually happens.

### Retention and deletion

Under GDPR Article 28 the processor must delete or return personal data at the end of the provision of services, at the controller's choice, subject to storage required by law. Contracts add specifics, usually a deletion deadline and sometimes a certificate.

Check the deadline against how deletion actually propagates through your systems, including backups, log stores, and analytics pipelines. Backups are where a confident answer most often turns out to be wrong.

## The contradiction problem

Almost every clause above has already been answered somewhere else. The buyer's security questionnaire asked about breach notification, retention, subprocessors, and encryption a few weeks earlier, and someone on your side answered it.

If the two answers differ, you have shipped a contradiction to the same buyer. That is not an abstract risk. It surfaces during diligence, during an audit, or worst of all during an incident, when the number in the contract turns out to be tighter than the number your team has been operating to.

The mechanism that prevents this is boring and effective. Review the contract against the same corpus of approved facts that answers the questionnaire, so both draw on one version of each control. Wolfia's [AI contract review](/products/contract-review-agent) reads the policies and approved facts already maintained for security reviews, including overrides, and marks each clause favorable, needs review, or not applicable with a link to the policy behind the flag. When the clause has no supporting evidence, it routes to a person instead of guessing. The mechanics of that pipeline, and the checks worth running on any tool that claims to do it, are covered in [AI contract redlining, how it works and what to check](/blog/ai-contract-redlining-how-it-works).

## A working sequence

Split the package first, so security is not waiting on legal to finish reading before starting. Answer the security clauses against evidence you can produce today. Compare each answer to what the questionnaire for the same buyer already says and reconcile any difference before it leaves your side. Send counsel a marked-up document with the security clauses resolved and the gaps named, rather than a blank one with questions attached.

The ownership and sequencing problem this creates across two teams is covered in more depth in [when a buyer sends a questionnaire and a security addendum](/blog/buyer-sends-questionnaire-and-security-addendum).

See a cited first pass on one of your own DPAs