Verified against ChatGPT · 2026-08-13
Check a vendor's data processing agreement against your actual requirements before it goes to legal
Compares a vendor-supplied DPA against your stated data-handling requirements clause by clause, flagging gaps and mismatches so legal's actual review starts from a pre-sorted list instead of a blank read-through, always framed as a pre-review draft.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Compare the vendor's data processing agreement below against our stated requirements, clause by clause, and flag every gap or mismatch — this is a pre-screen for legal's actual review, not a legal sign-off on the DPA. VENDOR'S DPA TEXT OR CLAUSE SUMMARY Vendor DPA: sub-processors listed in Schedule A, notice-only (no approval right); breach notification 'without undue delay'; no explicit data location clause. OUR STATED REQUIREMENTS Require prior approval (not just notice) for new sub-processors; breach notification within 72 hours; data must stay within named regions. DATA TYPES AND VOLUME INVOLVED Customer PII including payment card tokens for approximately 40,000 users. SUB-PROCESSOR SITUATION Vendor is known to use offshore support contractors; we specifically need visibility into who those are. STEP 1 — MAP REQUIREMENTS TO CLAUSES For each requirement I've stated, find the corresponding clause (if any) in the vendor's DPA and note whether it fully meets the requirement, partially meets it, or is silent on it entirely. If a requirement has no corresponding clause anywhere in what I gave you, mark it as a gap rather than assuming it's covered by a general clause that doesn't actually address it. STEP 2 — FLAG SUB-PROCESSOR AND CROSS-BORDER ISSUES Identify what the DPA says about sub-processor approval rights (do we get notified or must we approve new sub-processors) and what it says, if anything, about where data can be transferred or stored geographically. Flag if either topic is missing entirely, since silence on sub-processor rights or data location is itself often the biggest practical risk in a DPA, not just a technicality. STEP 3 — FLAG BREACH NOTIFICATION MISMATCH Compare the DPA's stated breach notification timeline against our requirement, if I've given you both, and flag any gap in days, since this is one of the most commonly negotiated and most consequential mismatches in DPA review. WHAT NOT TO DO Do not conclude whether this DPA is acceptable to sign — that is a risk decision for legal and the business owner, informed by factors beyond clause-matching, like the vendor relationship and available alternatives. Do not assert what any specific data protection law actually requires (retention limits, cross-border transfer mechanisms, notification deadlines) — if I haven't told you our specific regulatory requirement for a topic, mark it as "our requirement not specified" rather than filling it in from general knowledge of data protection law, since these requirements vary by jurisdiction and change over time. OUTPUT FORMAT A table: Our Requirement | Corresponding DPA Clause (or "none found") | Match Status (full / partial / gap / silent) | Note. A separate short section on sub-processor and cross-border flags. A separate line on breach notification timeline comparison. Close with a statement that this is a pre-review comparison draft only, not a legal assessment of the DPA's adequacy or enforceability, and that a qualified lawyer must review the full agreement and make the actual acceptance decision.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Structuring this as a clause-mapping exercise against explicitly stated requirements, rather than an open-ended 'review this DPA' request, matters because it forces a binary, checkable comparison for each requirement instead of a general narrative impression — a model asked to just review a DPA will produce a plausible-sounding summary of its overall tenor, while a model asked to map each stated requirement to its corresponding clause (or the explicit absence of one) produces something legal can act on directly, sorted by exactly where the gaps are. Treating silence on sub-processor approval rights or data location as a flag in its own right, rather than something to note only if it seems concerning, reflects a specific and common pattern in vendor DPAs: vendors frequently omit or soften exactly these two topics because they're the ones most likely to constrain the vendor's own operational flexibility, so a DPA that says nothing about data location isn't neutral, it's often a deliberate gap, and treating silence as equivalent to 'no issue found' would miss the most common way real risk hides in these documents. The explicit prohibition on asserting what data protection law actually requires — retention limits, transfer mechanisms, breach deadlines — protects against the most consequential failure mode in this domain: those requirements are jurisdiction-specific, frequently updated, and materially different across frameworks, so a model stating a specific number (like a breach notification deadline) from general pattern knowledge rather than the user's stated requirement risks the reviewer treating an outdated or wrong figure as an authoritative benchmark, when the only safe move is comparing against what the organization has actually confirmed as its own requirement.
What you get back
OUR REQUIREMENT: Prior approval required for new sub-processors. DPA CLAUSE: Schedule A lists current sub-processors, section 4.2 states notice-only for future additions. MATCH STATUS: Gap — DPA provides notice, not approval rights. FLAG: Sub-processor topic addressed but weaker than our stated requirement; recommend legal push for approval-rights language given known use of offshore contractors. This is a pre-review comparison draft only — a qualified lawyer must review the full agreement and make the actual acceptance decision.
Verified against
ChatGPT GPT-5.1 · 2026-08-13
Changelog
- 2026-08-13 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
