Testing ISO 27701 Privacy Controls for GDPR

The Friday privacy audit that exposed the real problem

It is 15:40 on a Friday when Maria, the CISO of a fast-growing SaaS company, joins a video call with the lead procurement officer of a major enterprise prospect.

Her team has worked for months on its Privacy Information Management System. Policies are approved. The processing register exists. The company has an ISO 27701 readiness plan. The DPO has data subject request workflows. Legal has updated data processing agreements. Engineering says production access is restricted.

The procurement officer opens politely, but directly.

“Thanks for the documentation, Maria. The certificate and policy pack are a good starting point. Our due diligence team will be onsite next month. They will want to see your DSAR process in action, verify data minimization controls on our test accounts, review access logs for production, and inspect evidence that privacy controls are tested, not just documented.”

Within minutes, Maria receives two more messages.

The DPO asks whether the new analytics feature is covered by the processing register, lawful basis assessment, retention schedule, and processor flow-down obligations.

The compliance manager asks whether the ISO 27701:2025 readiness review can prove the PIMS controls are operating effectively.

This is the moment many privacy programs wobble. The organization has privacy documents, but not privacy proof. It has workflows, but not sample-based evidence. It has contracts, but weak monitoring records. It has internal confidence, but no defensible audit trail.

That gap is the difference between paper compliance and demonstrable accountability.

GDPR makes the problem explicit. The controller is responsible for, and must be able to demonstrate, compliance with the data protection principles. Personal data must be processed lawfully, fairly, transparently, for specified purposes, limited to what is necessary, accurate, retained only as long as needed, and secured through appropriate technical and organizational measures.

ISO 27701:2025 gives organizations the privacy management structure. ISO/IEC 27001:2022 gives the ISMS backbone for scope, risk treatment, operational control, internal audit, management review, and continual improvement. GDPR supplies the legal accountability burden. NIS2, DORA, NIST CSF 2.0, COBIT 2019-style assurance, and customer security reviews increase the pressure to prove that controls work.

Clarysec’s view is simple: privacy control testing should not be an annual scramble for screenshots. It should be a PIMS evidence system that links processing activities, applicable controls, risks, samples, technical checks, findings, CAPA, and management review into one traceable model.

That is where Clarysec’s PIMS policy set, Zenith Blueprint: An Auditor’s 30-Step Roadmap, and Zenith Controls: The Cross-Compliance Guide become operational tools, not bookshelf material.

Privacy control testing is the bridge between policy and accountability

A privacy control test answers three practical questions:

1. Is the control designed to meet the privacy obligation or reduce the privacy risk?
2. Is the control implemented in the relevant process, system, team, supplier, or product workflow?
3. Is the control operating effectively over time, with evidence that would satisfy an auditor, customer, regulator, or board committee?

A SaaS company may say it supports deletion requests. A design test checks whether the deletion policy, identity verification process, ownership model, processor coordination, retention exceptions, and backup handling are defined. An operating effectiveness test samples completed deletion requests, compares timestamps, checks approvals, reviews system logs, verifies downstream processor notifications, and confirms closure evidence.

The PIMS Monitoring, Audit and Improvement Policy turns this into an auditable requirement:

[Both] The Internal Audit / Compliance Reviewer MUST test applicable PIMS control implementation status against REG03 during each PIMS audit.

From section ‘PIMS internal audit programme’, policy clause 4.2.5.

That phrase, “against REG03,” is central. Testing is not a free-form interview. REG03 acts as the applicability and implementation reference for PIMS controls. It shows what applies, why it applies, and what should be evidenced.

The same policy adds:

[Both] The Internal Audit / Compliance Reviewer MUST record the selected PII processing evidence sample in REG12 during each PIMS audit.

From section ‘PIMS internal audit programme’, policy clause 4.2.6.

This is the heart of ISO 27701:2025 privacy control testing. A PIMS audit without a sample is a conversation. A PIMS audit with selected evidence, control mapping, exceptions, corrective action, and management review traceability is accountability.

Start with scope, role, and processing reality

Most weak privacy audits fail before testing starts. They select generic controls without confirming what personal data is processed, where it lives, which systems and suppliers touch it, and whether the organization acts as controller, processor, joint controller, or subprocessor.

GDPR obligations depend heavily on role. A controller deciding why and how personal data is processed has different obligations than a processor acting on documented customer instructions. The sensitivity of the data also matters. Employee data, customer account data, telemetry, financial data, biometric verification, health-related data, sanctions screening, and criminal-offence data do not carry the same risk.

A strong ISO 27701:2025 testing program starts with scoping discipline.

ISO/IEC 27001:2022 supports this integrated approach through its requirements for organizational context, interested-party requirements, legal and contractual obligations, management system scope, operational planning, and risk treatment. For privacy, this means PII processing cannot sit in a disconnected spreadsheet. It must be part of the ISMS and PIMS operating model.

The Privacy Information Management System Policy connects privacy testing directly to governance:

[All] Top Management MUST review PIMS performance, privacy objectives, open risks, nonconformities, corrective actions, and improvement decisions in REG12 annually.

From section ‘PIMS governance’, policy clause 6.1.1.

If testing identifies a privacy gap, it is not just an audit note. It is a management system input that should affect risk treatment, priorities, resources, and leadership decisions.

Design effectiveness versus operating effectiveness

When a customer asks whether privacy controls are tested, they usually mean operating effectiveness. Auditors, however, will also examine design effectiveness.

A design-effective control is capable of meeting the requirement if performed as intended. An operating-effective control is actually performed consistently and supported by evidence.

The Audit and Compliance Monitoring Policy states the purpose directly:

Validate the effectiveness of security and privacy controls

From section ‘Purpose’, policy clause 1.1.1.

The SME version keeps the same assurance principle in operational language. The Audit and Compliance Monitoring Policy - SME says:

This policy establishes the organization’s approach to conducting internal audits, security control reviews, and compliance monitoring. It ensures that all controls, policies, systems, and service providers are subject to regular and structured review.

From section ‘Purpose’, policy clause 1.1.

ISO 27701 readiness is not about company size. A 30-person SaaS processor may not need the same audit tooling as a global bank, but it still needs to prove that access, deletion, incident escalation, subprocessor governance, and evidence retention are controlled.

The Clarysec evidence chain: REG03, REG12, CAPA, and review

Clarysec structures privacy control testing around a simple evidence chain.

REG03 defines applicable PIMS controls and implementation status. REG12 records samples, evidence, findings, traceability gaps, corrective action verification, and management review inputs. CAPA records convert findings into root-cause-based improvements. Top management reviews PIMS performance, risks, nonconformities, corrective actions, and improvement decisions.

The PIMS Documented Information and Evidence Management Policy requires evidence quality issues to be captured:

[All] The Internal Audit / Compliance Reviewer MUST record evidence completeness, accuracy, or traceability gaps in REG12 during each scheduled audit or compliance review.

From section ‘Evidence creation, naming, and quality’, policy clause 4.3.4.

This matters because not every finding is a total control failure. Sometimes the control worked, but evidence is incomplete. Sometimes a deletion ticket is closed, but no system log proves the deletion. Sometimes the processing register names the CRM, but misses the data warehouse export. Sometimes a supplier contract exists, but ongoing monitoring is absent.

The Audit and Compliance Monitoring Policy also requires structured internal audits:

Internal audits shall follow a documented procedure including:

From section ‘Policy Implementation Requirements’, policy clause 6.1.1.

And when findings occur:

All findings shall result in a documented CAPA that includes:

From section ‘Policy Implementation Requirements’, policy clause 6.2.1.

The Risk Management Policy - SME reinforces closure discipline:

Completion and effectiveness of treatment actions must be verified.

From section ‘Policy Implementation Requirements’, policy clause 6.3.2.

The PIMS Monitoring, Audit and Improvement Policy closes the loop:

[All] The Internal Audit / Compliance Reviewer MUST verify corrective action effectiveness in REG12 within 30 days of reported corrective action closure.

From section ‘Nonconformity and corrective action’, policy clause 4.4.7.

This is the difference between fixing a ticket and improving a management system.

Practical test 1: deletion requests and GDPR accountability

Deletion requests are one of the clearest ways to test whether privacy accountability works in practice.

Assume a mid-market SaaS company acts as both controller and processor. It controls employee, marketing, and billing data. It processes customer end-user data on behalf of enterprise customers. The organization wants to test whether deletion controls are ready for ISO 27701:2025 audit and GDPR customer assurance.

Step 1: Select the processing activity from REG03

Choose a processing activity with real privacy risk, such as “customer end-user profile data processed in SaaS platform.” Confirm whether the organization acts as controller, processor, or both. Identify linked controls for rights handling, processor instruction validation, retention, deletion, access control, logging, backup handling, and supplier coordination.

Step 2: Define a precise test objective

A useful test objective is specific and evidence-driven:

“Verify that deletion requests for customer end-user profile data are received, authenticated or instruction-validated, actioned within the defined workflow, logged, technically completed in production systems, cascaded to relevant subprocessors where required, and closed with evidence.”

Step 3: Pull a representative sample

Select five deletion requests from the last quarter. Include one routine request, one request involving a customer admin, one processor-instruction request, one request with a retention exception, and one request that touches backup handling.

The Zenith Blueprint, in the Audit, Review & Improvement phase, Step 26: Audit Execution, emphasizes sampling and evidence collection:

✓ Interview relevant personnel: Ask people responsible for processes to explain how they meet the requirements. For example, ask the risk owner about the last risk assessment, or ask HR how new hires are trained in security (to cover control 6.3 on awareness).
✓ Review documentation: Check that documents and records exist and are current.
✓ Observe practices: If possible, do a direct observation.
✓ Sample and spot-check: You can’t check everything, so use sampling.

From the Audit, Review & Improvement phase, Step 26: Audit Execution (Conducting an Internal Audit).

Step 4: Inspect evidence for each sample

For each sampled request, collect the intake ticket, role classification, identity verification or customer authorization, system deletion log, retention exception decision, backup handling explanation, subprocessor notification, closure communication, timestamps, and reviewer sign-off.

Step 5: Record results in REG12

Record the sample, evidence source, control result, exception, and traceability gap in REG12. If the deletion happened but no production log exists, the control may have operated but the evidence is weak. If the request was delayed because supplier responsibility was unclear, the finding may involve third-party governance and contractual flow-down.

Step 6: Create CAPA and verify effectiveness

If the root cause is unclear ownership between support, legal, and engineering, the CAPA might include a revised workflow, updated RACI, mandatory evidence fields, and monthly deletion sample checks.

The Zenith Blueprint, in the Audit, Review & Improvement phase, Step 29, explains the closure expectation:

Plan how you will verify the effectiveness of each corrective action. This might mean scheduling a follow-up audit or check. For example, if your corrective action was to train IT staff on access control, you might plan to review new accounts in one month to see if all have proper approvals (verification).

From the Audit, Review & Improvement phase, Step 29: Continual Improvement (Corrective Actions & Lessons Learned).

For deletion, verification could mean sampling the next five deletion requests after the revised workflow goes live. Only then should the CAPA be closed.

Practical test 2: purpose limitation and data minimization

A second high-value test is purpose limitation. This is especially useful before customer due diligence, analytics launches, AI enrichment, data warehouse expansion, or marketing automation changes.

Maria’s SaaS platform collects customer user data for service delivery. The control objective is to ensure PII is used only for specified and legitimate purposes, and not reused for marketing analytics unless the user has given explicit, separate consent where required.

A strong operating test does not stop at the policy. It samples users who opted into marketing and users who did not. It traces whether consent status is correctly reflected across core application databases, data warehouse tables, campaign tools, dashboards, and exports. If non-consenting users appear in a marketing audience, the organization has a concrete nonconformity.

The SME Audit and Compliance Monitoring Policy gives the right mindset through a technical testing example:

Technical control verification (e.g., backup status, access control configuration, patch records)

From section ‘Policy Implementation Requirements’, policy clause 6.1.1.2.

For privacy, technical control verification includes consent synchronization checks, access control exports, deletion logs, encryption settings, data masking tests, DLP alerts, backup constraints, monitoring events, and supplier evidence.

Mapping privacy testing to ISO/IEC 27001:2022 and Clarysec cross-compliance

Privacy controls do not operate in isolation. PII protection depends on asset inventory, classification, access control, cloud governance, data masking, information transfer, logging, monitoring, deletion, records protection, supplier oversight, and independent review.

In Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27001:2022 Annex A control 5.34, Privacy and protection of PII, is mapped as a preventive control aligned to confidentiality, integrity, and availability, with Identify and Protect cybersecurity concepts, and operational capabilities in Information Protection plus Legal and Compliance.

Its relationship to inventory is direct:

An inventory of information assets (5.9) should include PII data holdings (customer databases, HR files). This underpins 5.34 by ensuring the organization knows what PII it has and where, which is the first step to protecting it.

From Zenith Controls, Privacy and Protection of PII, control 5.34.

For audit testing, this means the privacy auditor should not begin with the privacy notice alone. They should begin with the PII inventory, processing register, data flows, asset inventory, and supplier inventory. If the inventory is incomplete, downstream privacy controls cannot be fully reliable.

The guide also maps ISO/IEC 27001:2022 Annex A control 5.34 to related controls such as 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.14 Information transfer, 5.15 Access control, 5.16 Identity management, 5.23 Information security for use of cloud services, 5.33 Protection of records, 8.11 Data masking, 8.12 Data leakage prevention, and 8.10 Information deletion.

Two additional ISO/IEC 27001:2022 Annex A controls are especially relevant:

The Data Protection and Privacy Policy requires:

An internal privacy compliance audit shall be conducted annually or upon major organizational or regulatory changes. Audit scope shall include:

From section ‘Governance Requirements’, policy clause 5.4.

It further includes:

Effectiveness of technical and organizational measures

From section ‘Governance Requirements’, policy clause 5.4.1.

The Data Protection and Privacy Policy - SME keeps the same expectation practical:

Regular privacy audits or control checks must be performed and logged

From section ‘Governance Requirements’, policy clause 5.3.3.

Why GDPR accountability is now a cyber governance issue

Privacy evidence is no longer requested only by privacy auditors. The same proof may be requested by an ISO 27701:2025 auditor, an ISO/IEC 27001:2022 auditor, a GDPR reviewer, a NIS2 competent authority, a DORA-regulated customer, a NIST CSF assessor, or a board risk committee.

NIS2 Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational, and organizational measures for cybersecurity risk management. Article 21(2)(f) explicitly includes policies and procedures to assess the effectiveness of cybersecurity risk-management measures. NIS2 also makes management bodies responsible for approving and overseeing cybersecurity risk-management measures.

DORA applies from 17 January 2025 for financial entities and sets a detailed digital operational resilience rulebook. It requires ICT risk management, management body oversight, internal audit, remediation of critical findings, incident classification and reporting, resilience testing, third-party ICT risk management, contractual controls, registers of ICT service arrangements, and exit strategies. ICT providers that serve financial entities should expect DORA-driven evidence requests through customer assurance.

NIST CSF 2.0 provides a helpful translation layer. Its GOVERN function expects organizations to understand stakeholder expectations, dependencies, and legal, regulatory, contractual, privacy, and civil liberties obligations. Its Profiles approach helps compare current outcomes against target outcomes, identify gaps, and prioritize action plans.

The Zenith Blueprint reinforces traceability in Step 24:

Your SoA should be consistent with your Risk Register and Risk Treatment Plan. Double-check that every control you chose as a risk treatment is marked “Applicable” in the SoA. Conversely, if a control is marked “Applicable” in the SoA, you should have a rationale for it – usually a mapped risk, a legal/regulatory requirement, or a business need.

From the Audit, Review & Improvement phase, Step 24: Audit, Review & Improvement.

For privacy control testing, the same principle applies to PIMS applicability. Every applicable privacy control should trace to a processing risk, legal obligation, customer requirement, or business need. Every test should trace back to that control.

How different auditors will judge the same control

A strong privacy testing program anticipates the auditor’s lens. The same deletion control, access control, or processor onboarding control will be interpreted differently depending on the review context.

This is why REG12 is so valuable. It converts privacy compliance into auditable governance evidence.

Common findings in PIMS control testing

Clarysec repeatedly sees the same privacy audit findings in organizations preparing for ISO 27701:2025 certification, GDPR customer assurance, or enterprise due diligence.

Processing register does not match system reality

The processing register lists CRM and support platforms, but engineers have added analytics exports, observability logs, AI tooling, and data warehouse tables.

Test response: sample systems from the asset inventory and cloud inventory, then reconcile them to the processing register. Use the relationship between ISO/IEC 27001:2022 Annex A controls 5.9 and 5.34 as the audit rationale.

PII access is approved, but not periodically reviewed

Initial approvals exist, but privileged access reviews do not include support impersonation tools, production databases, BI dashboards, or emergency accounts.

Test response: sample active users with PII access and compare role, business need, approval, MFA status, last login, and review evidence.

Processor contracts exist, but monitoring is weak

The DPA is signed, but the vendor questionnaire is old. No one has reviewed subprocessor changes, data locations, security posture, or incident notification obligations.

Test response: sample critical processors and inspect due diligence, contractual clauses, subprocessor changes, transfer safeguards, and monitoring records. This supports GDPR, NIS2 supply-chain expectations, and DORA third-party risk expectations.

Incident response exists, but privacy classification is inconsistent

Security incidents are logged, but privacy impact is not always assessed. GDPR breach criteria are not consistently documented. Customer notification duties are handled informally.

Test response: sample incidents involving data exposure and inspect classification, privacy escalation, legal review, notification decisions, evidence preservation, root cause, and lessons learned.

CAPA is closed without effectiveness verification

A procedure is updated and the finding is closed. No one tests whether the next sample improved.

Test response: verify corrective action effectiveness in REG12 within 30 days of reported closure, as required by the PIMS Monitoring, Audit and Improvement Policy.

A 90-day privacy control testing sprint

For organizations moving toward ISO 27701:2025 readiness, customer due diligence, or GDPR accountability review, Clarysec recommends a focused 90-day sprint.

By the end of the sprint, the organization should be able to answer the questions auditors actually ask:

• What PII do you process?
• In which role?
• Which controls apply?
• Why are they applicable?
• What evidence proves they are implemented?
• What sample proves they operate?
• What gaps were found?
• What corrective actions were taken?
• Who verified effectiveness?
• What did top management review and decide?

From paper privacy to provable accountability

An ISO 27701 certificate is valuable, but it is not the final destination. Customers, regulators, boards, and auditors increasingly expect proof that privacy controls are designed, implemented, monitored, corrected, and governed.

Privacy compliance fails when it is treated as a documentation project. It survives scrutiny when it becomes a tested evidence system.

Clarysec helps organizations move from asserted compliance to demonstrable accountability by connecting PIMS policies, REG03 applicability, REG12 evidence samples, CAPA verification, management review, and cross-framework mapping through Zenith Blueprint: An Auditor’s 30-Step Roadmap and Zenith Controls: The Cross-Compliance Guide.

If your organization is preparing for ISO 27701:2025 certification, GDPR accountability review, customer privacy assurance, NIS2 governance evidence, or DORA-driven supplier due diligence, start with a focused privacy control testing workshop.

Clarysec can help you map REG03 applicability, build REG12 audit samples, test priority PIMS controls, align findings to CAPA, and prepare management review outputs that withstand scrutiny.

Your next privacy audit should not be a scramble for screenshots. It should be a confident demonstration that privacy is operating, evidenced, reviewed, and continuously improved.