Customer agreement

To meet the ISO/IEC 27701 customer agreement requirement, your customer contract must clearly define PII-processing roles and responsibilities and include the customer’s documented processing instructions. Operationalize this by standardizing data-processing terms, mapping instructions to internal controls, and retaining executed agreements plus a traceable record of any instruction changes. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Key takeaways:

• Your contract must state who decides the “why/how” of processing and who follows instructions, then capture those instructions in a durable, auditable form.
• Treat “processing instructions” as a controlled artifact: versioned, approved, communicated to operations, and tied to sub-processors and security controls.
• Auditors look for alignment between the signed agreement, actual processing, and evidence that you only process PII as instructed.

“Customer agreement” in ISO/IEC 27701 is not a generic legal review item. It is a control that anchors your entire privacy operating model as a PII processor: you must prove that you process personal data based on your customer’s documented instructions, with roles and responsibilities unambiguous in the contract. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

For a CCO or GRC lead, the practical challenge is translation. Sales wants fast turnaround. Legal wants negotiated language. Security wants consistent commitments. Operations needs executable instructions, not contract prose. If your agreement is missing clear instructions (or your teams cannot produce them quickly), you will struggle in certification audits and create real delivery risk: teams “fill gaps” with assumptions, which leads to processing outside scope, sub-processor misalignment, and broken customer trust.

This page gives requirement-level implementation guidance: who the requirement applies to, what to put in the agreement, how to operationalize instruction management across the processing lifecycle, what evidence to retain, and where audits commonly stall. It’s written so you can move from requirement to execution without waiting for a full privacy program redesign.

Regulatory text

Requirement (excerpt): “The contract shall address the roles and responsibilities regarding PII processing, including documented processing instructions.” (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Plain-English interpretation

If you process PII for a customer, your customer agreement must do two things:

1. Define roles and responsibilities for PII processing. The agreement must make it clear what you do as the processor and what the customer does (and decides) in relation to the processing.

2. Include documented processing instructions. You must be able to show what the customer instructed you to do with PII, in a form that is recorded and retrievable. “Documented” means you can produce it for an audit and show the current, approved version.

This requirement is about enforceable clarity and operational control. A privacy notice, marketing statement, or informal email chain is not a substitute for processing instructions that are contractually recognized and operationally implemented. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Who it applies to

Entity scope

• PII processors providing services to customers where the service involves processing PII on the customer’s behalf. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Operational contexts where this shows up

• SaaS / hosted services that ingest or store customer PII
• Managed services (support, data ops, analytics) that access customer datasets
• Outsourced business processes (HR, payroll, call centers) where customer data is handled
• Professional services performing data migrations, enrichment, or integration work

If you are both a controller for some activities and a processor for others, implement this requirement for the processor portion and avoid blending roles in a way that makes instructions ambiguous.

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

Step 1: Create a contract “PII processing” baseline

Build a standard set of customer agreement clauses (or a data processing addendum) that always covers:

• Role statement: you act as processor for defined services; the customer provides instructions.
• Scope statement: categories of PII, processing activities, systems involved, and service boundaries.
• Instruction mechanism: where instructions live (agreement body, exhibit, order form, statement of work, or an incorporated policy) and how updates work.
• Responsibility split: what the customer is responsible for (accuracy, lawful collection, deciding purposes) vs what you are responsible for (processing per instructions, agreed security controls, controlled sub-processing).

Keep this baseline tightly coupled to how your service really runs. If the contract promises bespoke instruction handling but operations only supports a standard configuration, you create an audit and delivery gap.

Step 2: Define “documented processing instructions” as a controlled artifact

Treat processing instructions like a compliance-controlled document, not a negotiation concept. Your operating rule should be: no processing outside the instruction set.

Common acceptable instruction containers (choose one and standardize):

• An exhibit listing processing purposes/activities and permitted operations
• A statement of work that includes explicit processing tasks
• An order form that binds service configuration choices to allowed processing
• A customer-controlled configuration within the product, if the contract states that configuration constitutes instructions and you can evidence the settings

Minimum fields your instruction artifact should capture:

• Customer identity and contract reference
• Service(s) covered
• Authorized processing activities (what you do)
• Authorized data types (what you process)
• Any explicit prohibitions or constraints (what you do not do)
• Effective date and version
• Approval/acceptance evidence (signature or equivalent acceptance method)

Step 3: Map contract instructions to real controls and workflows

Create a short internal “instruction-to-operations mapping” for each service line:

• Where data enters, who can access it, and under what ticket/change process
• Which system configurations implement the instruction set
• Where sub-processors are involved and how they stay within scope
• How support teams handle ad-hoc customer requests (are they new instructions? do they require contract change?)

This mapping is what makes the contract executable. Audits often fail because teams can recite the clause but cannot show how it is enforced.

Step 4: Put instruction changes under change control

Instructions change: new features, new integrations, new data categories, expanded use cases. Decide up front how changes become “documented”:

• Customer request intake path (ticket, SOW, change order)
• Review/approval gates (privacy, security, legal, service owner)
• Update method (contract amendment, new exhibit version, updated SOW)
• Communication to operations (implementation tasks, runbook updates)
• Evidence capture (who approved, when, what changed)

Avoid “side-letter sprawl.” If instructions are scattered across emails and calls, you cannot prove what you were authorized to do at any given time.

Step 5: Ensure subcontracting aligns to the same instructions

If you use sub-processors, your customer agreement should not create a split-brain situation where you promise one scope but your downstream contracts allow broader processing. Operationally:

• Link each customer’s instruction set to the sub-processors actually used for that service
• Confirm your downstream agreements support the same scope constraints
• Maintain a simple trace: customer instruction → your service boundary → sub-processor role in that boundary

Step 6: Operationalize via templates, playbooks, and deal desk controls

To scale this, embed the requirement in contracting workflow:

• Deal desk checklist: “Does the agreement include documented processing instructions?”
• Clause library and fallback positions for negotiation
• Redline guidance for common customer pushes (e.g., vague instructions, unlimited audit rights tied to instructions, conflicting role language)
• Escalation triggers: new processing purpose, new data category, new cross-border transfer requirement, new sub-processor

Tools can help here. If you manage third-party and customer compliance artifacts in Daydream, treat each customer instruction set like a controlled record: tie it to the executed agreement, renewal cycle, service line, and any instruction-change tickets so audit retrieval is push-button.

Required evidence and artifacts to retain

Keep evidence in a way that you can produce it by customer and by service.

Contract artifacts

• Executed master agreement and all amendments
• Data processing addendum (if separate)
• Exhibits/SOWs/order forms that define processing instructions
• Documented acceptance records (signature, click-through acceptance logs, or equivalent)

Operational traceability

• Instruction version history and change log
• Internal mapping from instruction set to systems/processes (runbooks, control mappings, service descriptions)
• Records of approvals for instruction changes (privacy/security/legal)
• Sub-processor alignment records (which sub-processors support which services under which instruction scope)

Exception handling

• Records of any deviations, customer-authorized exceptions, and remediation actions
• Support tickets that represent new instructions, plus the mechanism used to formalize them

Common exam/audit questions and hangups

Expect auditors to test “contract-to-reality” alignment.

1. “Show me the processing instructions for Customer X.”
   Hangup: you produce a DPA with generic language but no customer-specific instruction exhibit.

2. “How do you ensure operations follows customer instructions?”
   Hangup: no control mapping, no runbooks, no training evidence for support/engineering.

3. “How do instructions change, and how do you prevent unauthorized expansion?”
   Hangup: changes happen through informal emails; no approvals; no version control.

4. “Who is responsible for what?”
   Hangup: contract language blurs controller vs processor responsibilities or contradicts your service model.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating the DPA as boilerplate

Fix: require an instruction artifact with minimum fields, even if you keep it high-level for standardized services.

Mistake 2: Instructions exist, but no one can find the current version

Fix: maintain a single system of record and enforce versioning; archive superseded exhibits.

Mistake 3: Product configuration acts as instructions, but you can’t evidence it

Fix: log and retain key configuration states, tie them to the contract, and define in the agreement that configurations are instructions.

Mistake 4: Sales promises bespoke processing that your platform cannot restrict

Fix: publish “supported instruction patterns” by service; force deviations through a formal exception path with risk acceptance.

Mistake 5: Sub-processors operate outside the customer’s instructed scope

Fix: build a service-to-sub-processor matrix and check it during onboarding and at renewal.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, failure here increases:

• Scope creep risk: teams process PII beyond what the customer authorized.
• Dispute risk: contract ambiguity turns operational issues into legal conflicts.
• Audit failure risk: you cannot demonstrate controlled processing instructions, which is central to ISO/IEC 27701 Clause 8.2.1. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Practical 30/60/90-day execution plan

First 30 days (stabilize and standardize)

• Inventory current customer agreements that involve PII processing and identify where instructions live today.
• Publish a standard “processing instructions” exhibit template with minimum required fields.
• Add a deal desk gate: no signature without an instruction artifact or an explicitly approved standard-instructions reference.

Days 31–60 (operationalize and connect to delivery)

• Build instruction-to-operations mappings for your top services.
• Implement change control for instruction updates (intake, review, approval, publishing).
• Train sales, legal, and service delivery on: what counts as instructions, where they live, and when a change is required.

Days 61–90 (scale and audit-proof)

• Retrofit priority customers: amend agreements or attach exhibits where instructions are missing.
• Create a sub-processor alignment view that ties each service and customer instruction set to downstream processing.
• Run an internal “mock audit”: pick sample customers and prove you can produce instructions, show current version, and demonstrate operational enforcement.

Frequently Asked Questions

Do we need a separate Data Processing Addendum (DPA) to meet the customer agreement requirement?

No specific document type is mandated by the requirement. You need a contract structure that clearly defines roles/responsibilities and includes documented processing instructions, whether that is in a DPA, the master agreement, or an incorporated exhibit. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

What counts as “documented processing instructions” in practice?

Instructions must be recorded and retrievable, tied to the customer agreement, and specific enough that operations can follow them. An exhibit, SOW, order form, or contract-recognized configuration record can work if you can show the current approved version. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Can product configuration choices be treated as customer instructions?

Yes, if your agreement states that the customer’s configuration constitutes instructions and you retain evidence of the settings over time. Without retention and versioning, you will struggle to prove what instructions were in effect for a given period.

Our contracts are standardized; do we still need customer-specific instructions?

You still need “documented processing instructions,” but they can reference a standard service description if it is incorporated into the contract and clearly describes permitted processing. The key is that the instructions are documented and traceable to what you actually do. (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

How should we handle one-off customer support requests that involve handling PII?

Treat them as potential new processing instructions. Route them through an intake and approval flow, then formalize the change through the contract mechanism you defined (amendment, SOW update, or new exhibit version) before performing out-of-scope processing.

What is the quickest way to get audit-ready evidence for this requirement?

Build a customer-by-customer retrieval package: executed agreement, instruction exhibit (current and prior versions), change approvals, and a short mapping that shows how the instructions are enforced in systems and workflows. Centralizing these records in a tool such as Daydream reduces scramble during audits by keeping contracts and instruction changes tied together.