ISO 27701 has two sets of privacy controls: one for organizations acting as a PII controller, one for organizations acting as a PII processor. Most teams know this. Fewer know which set applies to which part of their business, and fewer still know what each control looks like when an auditor samples it.
The result is a Statement of Applicability that either excludes half the controller set because "we are a processor", or includes everything with no clear idea how it will be evidenced.
This article covers how to assign roles, what the two sets ask for in practice, and the evidence each produces. For where these sets sit in the standard as a whole, start with our overview of ISO 27701 as an extension of ISO 27001.
Deciding which role you hold
Role is decided per processing activity, not per company. Write down each activity first, then ask one question of each: who decides the purpose and the essential means of this processing?
If you decide, you are the controller for that activity. If a customer decides and you act on their instructions, you are a processor. If you and another organization decide together, you are joint controllers.
For a typical SaaS company, the split looks like this:
Processor: customer data stored and processed in the product, support access to customer accounts, backups of customer environments.
Controller: employee and contractor records, recruiting data, sales and marketing contacts, website analytics, and product telemetry you use for your own purposes.
The telemetry line is where teams disagree. If you use customer usage data to improve your product or train models for your own benefit, you are likely deciding the purpose. That makes you a controller for that activity, whatever your contract calls you. Treat this as a legal question and confirm the position with counsel.
A processing inventory that records the role for each activity is the foundation for everything below. Our guide to building an Article 30 record of processing describes the fields, and the same record serves ISO 27701.
The four themes both sets share
Both control sets are organized around the same four themes. The questions differ because the responsibility differs.
| Theme | Controller asks | Processor asks |
|---|---|---|
| Conditions for collection and processing | Is the purpose defined and the lawful basis identified? | Is processing limited to the customer's documented instructions? |
| Obligations to PII principals | Can individuals exercise their rights, and do we respond? | Can we help the customer respond when it asks? |
| Privacy by design and by default | Do we collect, keep, and use only what the purpose needs? | Do we handle temporary files, return, and disposal as agreed? |
| Sharing, transfer, and disclosure | Do we know where PII goes, on what basis, and is it recorded? | Do we disclose subprocessors, handle disclosure requests, and record transfers? |
Reading the table across a row shows why both sets usually apply. The same team runs the same infrastructure, but it owes different things depending on whose data it is.
Controller controls in practice
The controller set asks you to make and record decisions. Here is what each theme produces as evidence.
Conditions for collection and processing
You identify and document the purpose of each activity and its lawful basis. Where you rely on consent, you determine when and how it is obtained and keep records of it. You assess privacy impact where processing warrants it. You put contracts in place with your own processors, define responsibilities with any joint controller, and keep records of processing.
Evidence: the processing inventory, consent records with timestamps and the wording shown, completed impact assessments, executed processor agreements, and joint controller arrangements where they exist.
Obligations to PII principals
You determine what you owe individuals, tell them in a privacy notice, give them a way to withdraw consent or object, and handle requests for access, correction, and erasure. Where you have shared data with third parties, you tell those parties about corrections or erasures. Where you make automated decisions about individuals, you address that too.
Evidence: published notices with version history, a request log showing receipt date, identity verification, action taken, and response date, and the procedure staff follow.
Privacy by design and by default
You limit collection and processing to what the purpose requires, keep data accurate, set minimization objectives, de-identify or delete data at the end of processing, manage temporary files, and set and apply retention periods.
Evidence: a retention schedule, deletion job logs or tickets, design review records that show a privacy question was asked before launch, and documentation of the fields you deliberately chose not to collect.
Sharing, transfer, and disclosure
You identify the basis for transfers between jurisdictions, know which countries and organizations receive PII, and keep records of transfers and of disclosures to third parties.
Evidence: a transfer register, the transfer mechanism for each, and a disclosure log.
Processor controls in practice
The processor set asks you to do what you agreed and be able to prove it.
Customer agreement. Your contract states your role and the assistance you provide. Evidence is the template and a sample of signed agreements.
Purposes. You process customer PII only for the customer's documented purposes, and you do not use it for marketing or advertising without appropriate permission. Evidence includes internal policy and any controls that stop customer data reaching marketing systems.
Infringing instructions. You tell the customer if you believe an instruction infringes applicable law. Evidence is the procedure and who owns it.
Customer obligations. You give the customer what it needs to meet its own obligations, including help with individual requests and impact assessments. Evidence is a support process and tickets.
Return, transfer, or disposal. At the end of the contract, you return or delete PII as agreed, including temporary files. Evidence is the offboarding runbook and deletion records for departed customers.
Disclosure requests. You tell the customer about legally binding requests for its PII, unless the law prohibits it, and record disclosures.
Subcontractors. You disclose subprocessors, engage them only under agreement, and tell customers about changes. Evidence is the published subprocessor list, change notices, and subprocessor contracts.
Processor controls are often easier to evidence than controller controls, because most of them leave a contract or a ticket behind. The weak point is usually deletion. Teams can show the runbook and cannot show it was followed for the customers who left last year.
Excluding controls in the Statement of Applicability
Exclusions are allowed, and the justification is what an auditor reads.
A sound exclusion names the reason in terms of your processing. "We do not make decisions about individuals based solely on automated processing" is specific and checkable. "Not applicable" is neither.
Three patterns cause trouble:
Excluding the whole controller set. Almost no organization is purely a processor. Your own employees are PII principals.
Including controls you cannot evidence. Including consent controls when no activity relies on consent creates work with no output to sample.
Leaving roles out of the scope statement. If the scope does not say which activities you hold which role for, the auditor will establish it during fieldwork, and your inclusions may not match.
The ISO 27001 framework page covers how the Statement of Applicability works in the base standard, and the ISO 27701 framework page summarizes how privacy controls extend it.
What people get wrong
The most common failure is treating the two sets as documentation deliverables. Controls that exist only as policy statements produce nothing an auditor can sample.
The second is copying controller answers into processor controls. A processor does not decide the lawful basis for customer data. Writing that it does suggests you have not understood your role, and invites questions.
The third is failing to revisit roles when the product changes. A new analytics feature, an AI feature that learns from customer content, or a new data-sharing partnership can each move an activity from one role to another. Review the processing inventory whenever product scope changes, not only at the annual review.
How TrustLynce helps
TrustLynce keeps your processing inventory, impact assessments, and data subject requests in its data privacy workflows, and the Statement of Applicability tool records the inclusion or exclusion and justification for each controller and processor control. Supporting evidence is collected on a schedule, so the deletion records and contracts an auditor samples are already attached.