Contracts with PII processors

To meet the ISO/IEC 27701 “contracts with PII processors” requirement, you must have a written contract with every third party that processes PII for you, and that contract must require the processor to implement the privacy and security controls you determine. Operationally, this means standardizing a data processing agreement (DPA) and forcing it into procurement so no PII processing starts without signed terms. ¹

Key takeaways:

• Your obligation is contractual: every PII processor needs signed terms that bind them to your required controls. ¹
• Scope is broader than “vendors”; include affiliates, contractors, consultants, SaaS, and any service provider touching PII. ¹
• Auditors look for proof the contract is in place before processing, and that the clauses map to how PII actually flows. ¹

“Contracts with PII processors” is a deceptively narrow requirement that usually fails in execution for one reason: the business onboards third parties faster than legal and privacy can paper them. ISO/IEC 27701 Clause 7.2.6 is clear that you, as a PII controller, must put enforceable obligations on processors through written contracts, and the contract must require “appropriate controls” as determined by you. ¹

For a CCO, Privacy Officer, or GRC lead, the fastest path is to treat this as a procurement gate with standardized contracting artifacts. Your job is to (1) identify which third parties are processors in your environment, (2) standardize a DPA and security schedule, (3) ensure the contract covers the minimum operational clauses you rely on (purpose limits, security requirements, sub-processing, incident notice), and (4) retain evidence that the contract exists and is tied to actual processing activities. ¹

This page breaks the requirement down into implementable steps, the artifacts auditors ask for, and the common failure modes that create privacy and breach-response exposure.

Regulatory text

Requirement (ISO/IEC 27701 Clause 7.2.6 / Annex A.7.2.6): “The organization shall have a written contract with any PII processor that it uses, requiring the processor to implement appropriate controls for PII processing as determined by the controller.” ¹

Operator meaning: If a third party processes PII on your behalf, you must (a) have a signed written agreement, and (b) use that agreement to impose the privacy and security controls you require. “Appropriate controls” is not generic boilerplate; it must reflect the controls you expect for the specific processing and data involved. ¹

Plain-English interpretation (what the requirement really demands)

You cannot “accept” a processor’s security posture by reference or handshake. You must contractually bind them to the rules of the road for your PII, including:

• What they are allowed to do (processing purpose and instructions)
• How they must protect it (security and privacy controls you specify)
• Whether they can pass it on (sub-processing restrictions)
• How fast and how they must tell you about incidents affecting PII (breach/incident notification obligations)

Those items are explicitly called out in the provided summary of the requirement. ¹

Who it applies to (entity + operational context)

Entity scope

• PII controllers that engage PII processors. ¹

Operational scope (what counts as a “PII processor” in practice)

Treat any third party as a processor if they handle PII on your behalf, even if “processing” is incidental to the service:

• SaaS platforms that store customer or employee records
• Payroll, benefits, recruiting, background-check providers
• Managed IT, help desk, data analytics, customer support outsourcing
• Cloud hosting, backup, email delivery, marketing automation
• Consultants/contractors with access to production systems containing PII

If a third party only receives anonymized or truly de-identified data with no re-identification path, you may decide they are out of scope. Document that decision because auditors will ask why the DPA was not required. ¹

What you actually need to do (step-by-step)

1) Build and maintain your “processor inventory”

Create a list of third parties that process PII, tied to:

• System/service name and owner
• PII categories involved (customer, employee, patient, etc.)
• Processing purpose (support, hosting, payments, marketing, analytics)
• Whether sub-processors are used

A clean inventory is how you prove completeness: “any PII processor that it uses” requires you to know who they are. ¹

2) Standardize contract language (DPA + security schedule)

Create approved templates that procurement and legal can issue consistently:

• DPA / privacy schedule (controller instructions, purpose limits, retention/return, assistance obligations)
• Security schedule (baseline controls you require, audit/assurance artifacts you accept, incident handling requirements)
• Sub-processor clause (approval model and flow-down obligations)
• Incident/breach notification clause (timing, content, cooperation expectations)

The goal is not “longer contracts.” It is enforceability and operational clarity for the processor. The standard’s plain-language summary explicitly expects processing purposes, security requirements, sub-processing restrictions, and breach notification obligations to be specified. ¹

3) Implement a contracting gate in your onboarding process

Make contract execution a hard dependency for going live with PII:

• Procurement intake asks: “Will this third party process, store, or access PII?”
• If yes, the workflow triggers the DPA + security schedule
• No production access, data transfer, or account provisioning until signed

Most nonconformities come from “shadow onboarding,” where a team signs an order form but skips the privacy addendum. Your control is the gate. ¹

4) Tailor “appropriate controls” based on risk

ISO/IEC 27701 requires controls “as determined by the controller,” which implies you set the bar. ¹

Use a simple decision matrix your team can run quickly:

Scenario	Contract tightening you should consider
Processor hosts large volumes of customer PII	Stronger security schedule, clearer incident cooperation, clear return/secure deletion
Processor uses sub-processors	Explicit approval model + flow-down + sub-processor transparency
Processor performs support with privileged access	Access control expectations, logging, and restrictions on copying/export
Cross-functional confusion about “purpose”	Concrete written processing instructions and prohibited uses

Keep the matrix internal. The contract should remain readable.

5) Confirm the contract maps to reality

Before signature (or during renewal), reconcile:

• The described services vs. what is actually enabled in the product
• Data flows vs. the stated processing purpose
• Sub-processors disclosed vs. those actually used
• Incident contact paths vs. your escalation procedure

A DPA that says “processor will notify controller” is weak if no one knows the mailbox or if the processor’s security team routes notices through a generic support queue.

6) Centralize execution evidence and renewals

Store executed agreements in a system of record, tagged to the processor inventory entry and service owner. Tie renewal triggers to:

• Contract expiration
• Material service changes (new product modules, new data sets, new sub-processors)
• Security posture changes that affect “appropriate controls”

If you use Daydream for third-party risk management, set the DPA/security schedule as required artifacts for any third party flagged as a PII processor, and enforce “no contract, no PII” with workflow gating and exception tracking.

Required evidence and artifacts to retain

Auditors typically want to see traceability from processor → contract → obligations. Retain:

• Executed written contract (MSA + DPA/privacy schedule + security schedule) ¹
• Proof of applicability decision (why the third party is a processor, or why it is not) ¹
• Version control of templates and fallback clauses used in negotiations
• Sub-processor list (if applicable) and approval/notification records ¹
• Incident notification procedure mapping (processor contacts, escalation, who receives notices) ¹
• Exceptions register (who approved deviations from standard clauses and compensating controls)

Common exam/audit questions and hangups

Expect questions like:

1. “Show me your list of PII processors.” They will sample it against AP/vendor master data and SaaS spend.
2. “Pick three processors. Show the executed DPA and where it requires appropriate controls.” Your contract needs explicit security/privacy obligations, not only a generic confidentiality clause. ¹
3. “How do you ensure sub-processors are controlled?” They will look for restrictions and flow-down obligations. ¹
4. “What happens if there is a breach at the processor?” They will look for contractual notification duties and your internal runbook alignment. ¹
5. “Do you allow processing to start before signature?” Any “yes, sometimes” answer needs a documented exception path and proof it is controlled.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Counting only “vendors” and missing contractors or affiliates. Fix: define “third party PII processor” in your procedure and map it to intake questions.
• Mistake: Using an MSA only, no DPA/security schedule. Fix: treat the DPA as mandatory for any PII processing. ¹
• Mistake: Boilerplate with no tie to controller-determined controls. Fix: publish a baseline control set and reference it in the security schedule as your requirement. ¹
• Mistake: Sub-processor clause allows unlimited subcontracting. Fix: require transparency and restrictions aligned to your risk tolerance. ¹
• Mistake: Signed contract is filed, but nobody can find it. Fix: central repository plus tagging to the processor inventory entry.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific regulatory actions.

Operationally, weak processor contracts create two concrete failure modes:

• You cannot compel rapid incident notice or cooperation, which slows containment and regulatory notification decisions.
• You cannot enforce sub-processing limits or security expectations, which increases the chance that PII is handled outside your approved risk posture.

ISO/IEC 27701 frames the contract as the mechanism for the controller to impose controls on processors. That is why auditors treat this requirement as foundational rather than paperwork. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Identify all likely PII processors from AP, procurement, IAM/app catalogs, and key business owner interviews.
• Freeze “net-new PII processing” unless a written contract (with DPA/security schedule) is in place, or route through a documented exception.
• Publish a standard DPA + security schedule package aligned to “processing purposes, security requirements, sub-processing restrictions, and breach notification obligations.” ¹

Next 60 days (Backlog burn-down)

• Triage your processor inventory by sensitivity and business criticality.
• Remediate top-risk processors first: execute DPAs, close missing security schedule items, and document sub-processor controls.
• Build a repeatable review checklist so every new or renewing processor contract hits the same minimum bar.

By 90 days (Make it durable)

• Embed the PII-processor question set into procurement intake so the DPA triggers automatically.
• Centralize executed contract storage and link it to each processor record.
• Operationalize change control: when scope of processing changes, the contract review is re-opened.
• If you run third-party risk in Daydream, configure required artifacts (executed DPA, security schedule, sub-processor disclosure) and approvals so exceptions are visible and time-bounded.

Frequently Asked Questions

Does an order form or NDA count as a “written contract” for ISO/IEC 27701 Clause 7.2.6?

A written contract exists, but it usually will not contain the required processor obligations. You typically need a DPA/privacy schedule and security requirements that bind the processor to controls you determine. ¹

What if the processor refuses to sign our DPA and only offers their standard terms?

Treat it as a risk decision. Record the deviation, confirm the offered terms still cover processing purpose, security requirements, sub-processing restrictions, and incident notification obligations, and document compensating controls if gaps remain. ¹

We have a master services agreement already. Do we still need a separate DPA?

If the MSA already imposes the required PII processing controls, it can satisfy the requirement. In practice, most MSAs do not specify the privacy/security items called out in the ISO/IEC 27701 summary, so a DPA/security schedule is the cleanest approach. ¹

How do we handle sub-processors if the provider has a large subcontractor ecosystem?

Your contract should restrict sub-processing and require flow-down of your requirements to sub-processors. At minimum, you need transparency and a defined approval/notification approach that matches your risk tolerance. ¹

What evidence do auditors usually want for this requirement?

They want an inventory of PII processors and executed written contracts for sampled processors that explicitly require appropriate controls. They also look for sub-processor restrictions and incident notification obligations in the written terms. ¹

What if a business unit starts sending PII to a tool before the contract is signed?

That is a control failure against the requirement. Put a procurement/IT gate in place, document the exception, stop or limit processing until terms are executed, and record corrective actions so it does not recur. ¹

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management