ISO/IEC 27018 DPA Clause Workflow

Start with a processing schedule, not boilerplate. Name the contracting entities, services, subject matter, duration, PII categories, affected people, processing operations, customer purposes, possible countries, and the responsibilities retained by each party.

Separate customer-instructed processing from any purpose the provider determines independently. List where instructions live, who can issue or change them, how identity and authority are checked, whether configuration changes, API calls, or support tickets count as instructions, how the provider flags an instruction it cannot follow, and what happens while the issue is resolved.

Record the governing law, mandatory processor clauses, transfer mechanism if needed, ISO/IEC 27018 edition used as a review criterion, and any assurance scope. ISO guidance supplements these sources; it does not replace them.

State that contracted PII is processed only for the customer's documented purposes and instructions. Under the 2019 guidance, marketing or advertising use requires express consent, and that consent should not be a condition of receiving the service.

Specify minimum technical and organizational measures in a schedule detailed enough to test. The 2019 guidance says those measures should not be reduced unilaterally. Define the change process, notice, customer remedies, and evidence available when controls change.

State whether customer consent is specific or general, when a subprocessor may begin processing, what advance notice is required, which channel counts as notice, and how an objection or termination is handled. The 2019 guidance calls for disclosure before use and timely notice of intended changes.

Require the provider to disclose relevant subprocessor names, possible processing countries, and how contracts require them to meet or exceed the provider's obligations. If public disclosure creates unacceptable security risk, the 2019 guidance allows controlled disclosure under confidentiality terms or on request, but the customer should know the information is available.

For law-enforcement demands, define authentication and legal review, rejection of non-binding requests, customer consultation where legally permissible, notice timing, approval, minimization, secure transfer, and the disclosure record.

Specify the information and technical measures the provider supplies when the customer depends on it to answer access, correction, or erasure requests. Define intake, identity and authorization checks, search scope, response format, deadlines, and responsibility for customer-managed components.

For a PII breach, define the event that triggers notice, the maximum delay, recipients and channel, available facts, update cadence, preservation of evidence, and support for customer notifications. The 2019 guidance excludes a breach caused by the customer or PII principal, or occurring within system components for which they are responsible, from its stated provider-notification control, but applicable law or contract may allocate duties differently.

At exit, state whether PII is returned, transferred, securely deleted, anonymized, or archived; cover live systems, temporary files, backups, business-continuity copies, and subprocessors. Record the retention period after termination, disposal method, exceptions, and evidence the customer receives.

Resolve each deviation as accepted, revised, or rejected. The decision record should name the clause, competing requirement, affected service and customers, risk, compensating measure, approver, effective date, expiry, and reopening trigger.

Before signature, test the agreement against real workflows: add a subprocessor, receive a disclosure request, investigate a PII breach, answer an erasure request, restore a backup, and terminate the service. A promise that has no owner, system path, or retained evidence is not ready for approval.