ISO 27701 Control Applicability Under GDPR Roles

It is 08:40 on a Tuesday, and Maria, the CISO of a fast-growing health-tech SaaS company, is staring at four customer emails that look almost identical but mean very different things.

One enterprise customer asks for evidence that the company can act as a GDPR processor under Article 28. A second asks whether the platform is also a controller for telemetry and product analytics. A third asks for the current subprocessor list and proof that Data Processing Agreement clauses are flowed down. A fourth, a fintech customer preparing for DORA supplier reviews, asks whether the same privacy controls are mapped to operational resilience, incident reporting and ICT third-party risk.

Maria’s company is not careless. It has an ISO/IEC 27001:2022-aligned ISMS, privacy policies, a processing register, MFA, encryption, access reviews and privacy-by-design training. But the request exposes the harder question auditors and customers actually test:

Can the company prove that the right ISO 27701 PIMS controls apply to the right GDPR role, for the right processing activity, with the right owner, evidence and justification?

That is where many privacy programs fail. They treat ISO 27701 as a checklist, when certification bodies, customer auditors and Data Protection Officers expect a reasoned control applicability decision. The answer is not “we have privacy controls.” The answer is “for this processing activity, we are a controller, processor, joint controller or subprocessor, and here is why these controls apply or do not apply.”

Why ISO 27701 control applicability is the missing PIMS layer

GDPR roles are based on decision-making authority. A controller determines the purposes and means of processing. A processor acts on behalf of a controller. Joint controllers jointly determine purposes and means. A subprocessor is engaged by a processor to process personal data further downstream.

In real SaaS environments, those roles rarely stay clean at company level. Maria’s organization is a processor when hosting customer wellness data, a controller for employee payroll and marketing contacts, a possible controller for product telemetry depending on purpose and contract terms, and a joint controller in a co-branded campaign. If a larger managed service provider resells her platform, the company may also become a subprocessor in that chain.

ISO 27701 control applicability is the discipline that prevents those roles from collapsing into vague statements. It asks:

• Which processing activity is in scope?
• What GDPR role does the organization play for that activity?
• Which PIMS controls apply because of that role?
• Which controls are excluded, and why?
• Which evidence proves implementation?
• Which legal, contractual, risk or scope requirement drove the decision?

Clarysec’s Privacy Information Management System Policy makes role classification the starting point:

“[Both] The Process Owner / Business Owner MUST classify the organization’s PIMS role for each PII processing activity in REG02 before the processing activity begins.”

From section “PIMS role determination”, policy clause 4.2.1.

The same policy connects that role decision to control applicability:

“[Both] The Privacy Lead / PIMS Manager MUST maintain REG03 with included controls, excluded controls, implementation status, and justification annually and within 30 days of each privacy risk treatment change.”

From section “Privacy policy, objectives, and control applicability”, policy clause 4.3.3.

REG02 answers what processing exists and what role applies. REG03 answers which controls apply, what is excluded, what evidence exists and why the decision is defensible.

Build the PIMS on ISO/IEC 27001:2022 SoA logic

A role-based PIMS works best when it is built on a mature ISMS. ISO/IEC 27001:2022 already requires scope definition, interested party analysis, risk assessment, risk treatment, control selection and a Statement of Applicability. ISO 27701 extends that management-system logic into privacy.

Clarysec’s Information Security Policy states:

“The ISMS shall include defined scope boundaries, a risk assessment methodology, measurable objectives, and documented controls justified in the Statement of Applicability (SoA).”

From section “Policy Implementation Requirements”, policy clause 6.1.2.

The Risk Management Policy reinforces the same evidence discipline:

“A Statement of Applicability (SoA) shall reflect all treatment decisions and shall be updated whenever control coverage is modified.”

From section “Governance Requirements”, policy clause 5.4.

For privacy, REG03 becomes the PIMS control applicability register that mirrors SoA discipline. It does not replace the ISO/IEC 27001:2022 SoA. It enriches it by adding GDPR role-specific privacy decisions for controllers, processors, joint controllers and subprocessors.

The PII Processing Inventory and Lawful Basis Policy makes that linkage explicit:

“[Both] The Privacy Lead / PIMS Manager MUST link applicable REG02 processing activities to REG03 control applicability records before certification readiness review.”

From section “Operating the processing inventory”, policy clause 7.1.5.

An auditor should be able to pick one processing activity in REG02, identify the GDPR role, trace applicable controls in REG03, review the relevant ISO/IEC 27001:2022 controls in the SoA, and inspect evidence such as a DPA, lawful basis record, access review, subprocessor approval, incident procedure or deletion log.

The role-based control applicability model

The fastest way to make ISO 27701 usable is to decide applicability at processing activity level, not company level.

A SaaS provider should avoid saying, “we are a processor.” It should say, “for customer-uploaded user records in the production platform, we are a processor. For payroll, we are a controller. For product analytics, our role depends on whether analytics are used only to provide contracted services or for our independent purposes. For the ticketing vendor supporting customer data, the vendor is a subprocessor.”

This role-based view aligns with GDPR accountability. Controllers must demonstrate compliance with principles such as lawfulness, fairness, transparency, purpose limitation, minimization, accuracy, storage limitation, integrity, confidentiality and accountability. Processors must process only on documented instructions, implement appropriate security, assist controllers, manage subprocessors and support return or deletion.

The dangerous shortcut is assuming every privacy control applies everywhere. A processor usually does not determine lawful basis for customer end-user data, but it must prove it processes only under customer instructions. A controller may not need customer subprocessor approval for internal HR processing, but it must perform processor due diligence for the payroll provider.

Classify before contract approval or processing begins

The most common PIMS readiness finding is late role classification. The contract is signed, the platform is live, vendors are integrated, and no one has decided whether the organization is a controller, processor, joint controller or subprocessor for each data flow.

That delay creates downstream issues. The wrong DPA is used. Subprocessors are not disclosed. DPIAs are missed. Retention is unclear. Customer support does not know which breach notification timeline applies. Procurement treats a privacy-impacting supplier as “just a tool.”

The Processor, Subprocessor and Third-Party Privacy Management Policy addresses the timing directly:

“[Both] The Privacy Lead / PIMS Manager MUST classify each third-party privacy relationship as controller, joint controller, processor, subprocessor, or other third-party relationship in REG08 before contract approval or before PII processing begins, whichever occurs first.”

From section “Relationship identification and classification”, policy clause 4.1.3.

REG08 supplier and third-party relationship classification feeds REG03. If a vendor is a processor, the applicable controls include DPA terms, confidentiality, security measures, audit rights, assistance with rights requests, breach support, return or deletion and subprocessor controls. If a vendor is an independent controller, the focus shifts to legal basis, disclosure governance, transfers, transparency and accountability.

For smaller organizations, the Third-Party and Supplier Security Policy - SME requires teams to consider:

“Regulatory exposure (e.g., GDPR processor role, financial-sector obligations under DORA)”

From section “Governance Requirements”, policy clause 5.2.4.

It also sets a clear pre-sharing requirement:

“Data Processing Agreement (DPA) clauses or equivalent contractual terms must be agreed before any personal or sensitive data is shared.”

From section “Policy Implementation Requirements”, policy clause 6.3.2.

That is the difference between having vendor contracts and having auditable privacy role governance.

Map controls to role, risk, law and contract

The Zenith Blueprint, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability, explains the core applicability logic. Controls are applicable because of risk treatment decisions, legal or contractual requirements, scope relevance and organizational context. Exclusions need clear reasons, and applicable controls should trace back to a risk or requirement.

In Step 13, Zenith Blueprint states:

“Ensure alignment with your risk register: every mitigating control you wrote in the Risk Treatment Plan should correspond to an Annex A control marked ‘Applicable.’ Conversely, if a control is marked applicable, you should have either a risk or a requirement driving it.”

For ISO 27701, the same method applies to privacy controls. A control can be applicable because:

1. GDPR requires it for the organization’s role.
2. A customer contract, DPA or joint controller arrangement requires it.
3. A privacy risk treatment requires it.
4. The processing involves special categories, children’s data, large-scale monitoring, sensitive profiling or high-impact PII.
5. Supplier, cloud, subprocessor or cross-border transfer risk makes the control necessary.
6. The control supports certification scope, audit readiness or approved privacy objectives.

The Legal and Regulatory Compliance Policy reinforces this mapping discipline:

“Where a regulation applies across multiple areas (e.g., GDPR applies to retention, security and privacy), this must be clearly mapped in the Compliance Register and training materials.”

From section “Governance Requirements”, policy clause 5.2.2.

The same Legal and Regulatory Compliance Policy is explicit for enterprise ISMS integration:

“All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).”

From section “Policy Implementation Requirements”, policy clause 6.2.1.

REG03 should therefore never be a detached privacy spreadsheet. It should connect processing activities, legal obligations, risk treatments, contracts, ISO/IEC 27001:2022 controls and evidence owners.

Practical example: a SaaS support workflow

Consider a support workflow in Maria’s SaaS platform. Customers submit tickets that may contain names, emails, account IDs, screenshots and occasional sensitive business context. Support agents access limited records. A cloud ticketing provider hosts the data and uses its own subprocessors.

Step 1: Record the activity in REG02

The Privacy Lead records:

• Activity name: Customer support ticket handling
• PII categories: user identifiers, contact details, screenshots, account metadata
• Data subjects: customer administrators and end users
• Purpose: support and service troubleshooting
• Role: processor for customer-provided end-user PII, controller for direct business contact management if used for account communications
• Retention: defined support and audit retention period
• Recipients: internal support staff, ticketing vendor, approved subprocessors
• Security classification: confidential, PII

The Data Protection and Privacy Policy - SME supports this baseline:

“The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods”

From section “Governance Requirements”, policy clause 5.2.1.

Step 2: Classify the vendor in REG08

If Maria’s company is a processor for customer data, the ticketing provider is typically a subprocessor for that customer data. REG08 should capture relationship type, contract status, data categories, data locations, downstream subprocessors and assurance evidence.

Step 3: Record REG03 applicability

The enterprise Data Protection and Privacy Policy adds a high-risk trigger:

“Threat modeling and Data Protection Impact Assessments (DPIAs) are mandatory for high-risk processing systems.”

From section “Policy Implementation Requirements”, policy clause 6.3.4.

The Data Protection and Privacy Policy - SME embeds the design expectation:

“Privacy by design and by default must be enforced in all new systems and services”

From section “Governance Requirements”, policy clause 5.3.1.

Step 4: Align with ISO/IEC 27001:2022 controls

If the support platform is in ISMS scope, the SoA should include supporting ISO/IEC 27002:2022 controls such as supplier relationships, supplier agreements, ICT supply chain management, access control, identity management, information transfer, cloud services, incident management, logging and monitoring, change management, legal compliance and privacy protection.

Zenith Blueprint, Risk Management phase, Step 14: Risk Treatment Policies and Regulatory Cross-References, recommends cross-referencing GDPR, NIS2 and DORA against policies and controls, especially for personal data protection, incident response, access control, business continuity and third-party ICT risk.

The result is reusable evidence, not separate spreadsheets for GDPR, DORA, NIS2 and certification.

What Zenith Controls adds to PIMS applicability

Zenith Controls is Clarysec’s cross-compliance guide for understanding relationships between ISO/IEC 27001:2022 and ISO/IEC 27002:2022 controls, audit methods and other frameworks. It is not a separate set of controls. For this topic, the central ISO/IEC 27002:2022 controls are:

• 5.34 Privacy and protection of PII
• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.22 Monitoring, review and change management of supplier services

For 5.34, Zenith Controls classifies the control as preventive, mapped to confidentiality, integrity and availability, aligned with Identify and Protect, and associated with information protection, legal and compliance capabilities.

Its GDPR mapping states:

“Implementation of 5.34 is direct evidence of an organization’s ability to meet GDPR accountability requirements.”

From Zenith Controls, Privacy and Protection of PII, GDPR cross-mapping.

That sentence matters because it turns 5.34 from a generic privacy statement into audit evidence. It should be supported by PII inventories, classification, access control, masking, secure transfer, cloud governance, DPIAs, privacy notices, DSAR workflows and breach handling.

Zenith Controls also connects privacy and PII protection to related standards such as ISO/IEC 27018 for public cloud PII processing, ISO/IEC 29100 for privacy principles and ISO/IEC 29151 for PII protection practices. Supplier privacy governance is supported by the ISO/IEC 27036 family for supplier relationships and ICT supply chain security, and ISO/IEC 27017 for cloud security shared responsibilities.

Supplier and subprocessor evidence is where roles converge

Controller and processor obligations often meet at the supplier boundary.

If Maria’s company is a controller, GDPR expects it to use processors that provide sufficient guarantees. If it is a processor, customers expect it to manage subprocessors, flow down obligations and provide assurance. If it is a subprocessor, it inherits obligations through the chain.

This makes ISO/IEC 27002:2022 controls 5.19 and 5.20 central to ISO 27701 control applicability.

For 5.19, Zenith Controls emphasizes supplier relationship security across governance, ecosystem and protection domains. It ties directly to 5.20 supplier agreements, 5.21 ICT supply chain security, 5.14 information transfer, 5.36 Compliance with policies, rules and standards for information security, and 5.10 Acceptable use of information and other associated assets.

For 5.20, Zenith Controls emphasizes contractual formalization. Supplier agreements should define confidentiality, breach notification, audit rights, subcontractor approval, secure transfer, data return or destruction, compliance obligations and monitoring.

Zenith Blueprint, Controls in Action phase, Step 23: Organizational controls, gives a practical instruction for subprocessors:

“For every critical supplier, identify if they use subcontractors (sub-processors) who may access your data or systems. Document how your information security requirements are flowed down to these parties, either through your supplier’s contract terms or your own direct clauses.”

Auditors will not stop at “do you have a DPA?” They will ask whether vendors are processors, subprocessors, independent controllers or joint controllers, whether subprocessor approvals are documented, whether obligations are flowed down, whether breach timelines are clear, whether monitoring occurs and whether deletion or return evidence can be obtained.

Cross-compliance without duplicate control systems

ISO 27701 control applicability becomes more valuable when it supports GDPR, NIS2, DORA, NIST CSF 2.0 and COBIT 2019 assurance conversations from the same evidence base.

GDPR drives role-based privacy obligations: controller accountability, processor duties, lawful basis, data subject rights, security, breach governance and contracts.

NIS2 adds cybersecurity risk management, incident handling, business continuity, supply chain security, secure development, vulnerability handling, access control, cryptography, MFA and training for essential and important entities.

DORA applies from 17 January 2025 to in-scope financial entities and requires ICT risk management, incident reporting, resilience testing and ICT third-party risk management. SaaS and ICT providers serving financial entities are often asked to provide privacy, security, resilience, audit rights and exit evidence in one assurance package.

NIST CSF 2.0 provides a governance layer through the GOVERN Function, including legal, regulatory, contractual and privacy obligations, roles, risk appetite, policy oversight and supply chain governance.

COBIT 2019 adds governance and management practices. For privacy, Zenith Controls maps 5.34 to COBIT DSS06.02, DSS06.08 and APO13.01. For suppliers, 5.19 and 5.20 support supplier risk and supplier agreement practices.

The strategic point is simple. REG03 should be more than an ISO 27701 artifact. It should be a reusable control applicability map for customer audits, regulatory reviews and board-level assurance.

How auditors test ISO 27701 control applicability

Different auditors start from different angles, but they usually converge on the same evidence trail.

An ISO management-system auditor starts with scope, interested parties, obligations, risk assessment, SoA alignment, internal audit, management review and continual improvement. They will test whether REG02, REG03 and the ISO/IEC 27001:2022 SoA agree.

A GDPR-focused auditor or DPO reviewer tests role logic. They will sample activities, review lawful basis, privacy notices, DPAs, subprocessors, DPIAs, DSAR handling, retention and breach decisioning.

A NIST-oriented assessor looks for governance outcomes, risk categorization, data inventories, access controls, protection of data at rest and in transit, monitoring, incident response, supplier risk and improvement plans.

A COBIT 2019 or ISACA auditor looks at governance ownership, process capability, control design and operating effectiveness. They will test whether privacy controls are embedded into procurement, change management, incident management and supplier monitoring.

For 5.34, Zenith Controls describes auditors reviewing privacy policies, data inventories, DPIAs, training logs, technical safeguards, DSAR samples, PII incidents and privacy-by-design evidence. For 5.19 and 5.20, auditors request supplier inventories, risk classifications, due diligence records, contracts, breach terms, audit rights, subcontractor approval, exit evidence and proof that supplier reports are reviewed.

The distinction is critical. Audit readiness is not “we have a clause.” Audit readiness is “we used the clause, monitored it, reviewed evidence and acted when risk changed.”

Common mistakes in controller and processor applicability

Clarysec repeatedly sees five avoidable failures.

First, organizations classify the whole company as one GDPR role. That does not work for SaaS, fintech, HR tech, health tech, managed services or cloud providers with mixed data flows.

Second, they treat ISO 27701 controls as universally applicable without role justification. This creates bloated evidence requirements and weak exclusions.

Third, they exclude controls without documenting why. In ISO/IEC 27001:2022 SoA logic and PIMS applicability logic, exclusions must be conscious, reasoned and supported by scope, role, risk or legal analysis.

Fourth, they forget subprocessors. A processor’s assurance story is only as strong as its downstream chain. Subprocessor registers, approval mechanisms, flow-down clauses and deletion evidence are essential.

Fifth, they fail to connect privacy controls to security operations. Privacy by design is not just a DPIA template. It should influence access controls, logging, secure development, cloud configuration, supplier due diligence, retention automation and incident response.

Clarysec-ready checklist for REG03 control applicability

Use this checklist before ISO 27701 readiness reviews, GDPR customer assurance or DORA-driven supplier assessments:

• Create or update REG02 for every processing activity involving PII.
• Classify the PIMS role for each activity before processing begins.
• Classify each third-party relationship in REG08 before contract approval or PII processing.
• Identify obligations based on role: controller, processor, joint controller or subprocessor.
• Record applicable PIMS controls in REG03 with owner, implementation status and evidence.
• Record excluded controls with clear justification.
• Link REG03 decisions to risks, legal obligations, contracts or scope rationale.
• Align REG03 with the ISO/IEC 27001:2022 SoA where security controls support privacy.
• Map privacy controls to ISO/IEC 27002:2022 5.34 where PII protection is required.
• Map supplier and subprocessor requirements to 5.19, 5.20, 5.21 and 5.22.
• Add cross-compliance references for GDPR, NIS2, DORA, NIST CSF 2.0 and COBIT 2019 where relevant.
• Test the evidence trail with an internal audit sample before certification readiness review.
• Obtain top management approval when PIMS scope or control applicability changes.

The Privacy Information Management System Policy closes this governance loop:

“[Both] Top Management MUST approve changes to PIMS scope and control applicability in REG01 and REG03 before certification scope changes are submitted.”

From section “PIMS governance”, policy clause 6.1.3.

That is the type of governance evidence auditors trust.

Turn GDPR role decisions into defensible evidence

ISO 27701 control applicability is where GDPR role theory becomes operational reality. A controller needs evidence for lawful basis, transparency, retention, DPIAs, rights handling and processor oversight. A processor needs evidence for documented instructions, confidentiality, security, assistance, subprocessors, breach support and deletion. A joint controller needs a transparent responsibility arrangement. A subprocessor needs flow-down obligations and assurance support.

Clarysec helps organizations build that evidence layer through:

• REG02 processing inventory and lawful basis structure.
• REG03 PIMS control applicability records.
• REG08 third-party privacy relationship classification.
• ISO/IEC 27001:2022 SoA alignment.
• Policy clauses that assign owners, timing and approval requirements.
• Cross-compliance mapping through Zenith Controls.
• Implementation sequencing through Zenith Blueprint.

If your organization is preparing for ISO 27701 PIMS readiness, GDPR customer assurance, DORA supplier reviews or NIS2-aligned security governance, start with one high-risk processing activity. Classify the role. Map the applicable controls. Link the evidence. Then repeat until your privacy program is not just compliant on paper, but explainable under audit.

Download the Clarysec PIMS policy suite, explore Zenith Blueprint, or book a Clarysec readiness assessment to turn controller, processor, joint controller and subprocessor decisions into a certification-ready privacy evidence register.