ISO 27701:2025 PIMS Evidence for GDPR Audits

It is 08:40 on a Thursday, and Ava, the Compliance Manager at FinScale, has just opened the email every fast-growing B2B SaaS company eventually receives.

A major German enterprise customer has sent a GDPR due diligence questionnaire with a 48-hour deadline. It is not asking for a privacy policy. It is not satisfied with a certificate. It asks for evidence.

Provide your Record of Processing Activities for our data. Show evidence of subprocessor onboarding due diligence. Explain how you evidence your GDPR Article 28 obligations. Identify whether your platform acts as a PII controller, processor, joint controller, or subprocessor for each workflow. Prove that lawful basis was validated for your AI-assisted support feature. Show deletion obligations, audit rights, incident support, and contract controls.

Ava knows FinScale has the ingredients. Legal has the Data Processing Agreement. Security has the ISO/IEC 27001:2022 Statement of Applicability. Product has launch checklists. Procurement has vendor contracts. Compliance has a processing register, although some entries are stale. The issue is not that evidence does not exist. The issue is that the evidence is scattered, role ambiguity is unresolved, and nobody can quickly trace a processing activity from purpose to lawful basis, risk decision, supplier control, security control, audit record, and management review.

That is the real accountability gap.

ISO 27701:2025 becomes powerful when it closes that gap. A Privacy Information Management System, or PIMS, is not just a policy binder for privacy certification. It is an operating model for producing reliable evidence. For CISOs, compliance managers, privacy leads, auditors, and business owners, the goal is simple: build a PIMS that proves GDPR accountability for PII controllers and processors, while also supporting ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, and COBIT 2019 expectations.

GDPR Accountability Is an Evidence Problem

GDPR accountability is often misunderstood as a documentation requirement. It is more demanding than that.

GDPR Article 5 defines the core principles of personal data processing, including lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, and confidentiality. Article 5(2) makes the controller responsible for being able to demonstrate compliance. Article 4 defines the vocabulary of personal data, processing, controller, processor, pseudonymisation, and personal data breach. Article 6 requires a lawful basis for each controller processing activity. Article 9 adds stricter conditions for special categories of personal data. Article 28 governs processor obligations and contract terms.

Those obligations are not satisfied by a public privacy notice alone. They require evidence at the level of the processing activity.

A practical ISO 27701:2025 PIMS evidence model must answer:

• What PII is processed?
• Why is it processed?
• Is the organization acting as controller, processor, joint controller, or subprocessor?
• What lawful basis applies when the organization is the controller?
• What documented instruction applies when the organization is the processor?
• Which systems, vendors, subprocessors, and locations are involved?
• What privacy risk screening or DPIA decision was made?
• Which security controls protect the PII?
• What evidence proves the control operated?
• Who approved residual risk, exceptions, and corrective actions?

Clarysec’s approach turns these questions into policy obligations, registers, and traceable evidence objects. The result is a PIMS that can withstand customer due diligence, supervisory authority review, internal audit, ISO audit, DORA assessment, and board scrutiny.

Start With Role Clarity: Controller, Processor, or Both

The fastest way to fail a PIMS audit is to treat every processing activity the same way.

Under GDPR, a controller determines the purposes and means of processing. A processor processes personal data on behalf of a controller. Many SaaS and technology companies do both. FinScale is a processor when hosting customer end-user data under customer instructions. It is a controller for employee records, marketing leads, billing contacts, recruitment data, and some product analytics.

This distinction drives evidence requirements.

Clarysec’s Privacy Information Management System Policy makes role classification an operational requirement:

[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.

This one obligation changes the privacy operating model. Legal review is no longer an afterthought at launch. Every process owner must classify the PIMS role before processing starts. That classification determines the downstream evidence chain.

For controller activities, Clarysec’s PII Processing Inventory and Lawful Basis Policy requires lawful basis validation:

[Controller] The Privacy Lead / PIMS Manager MUST validate the lawful basis recorded in REG02 before controller processing begins and before any purpose change takes effect.

From section “Controller purpose and lawful basis records”, policy clause 4.2.2.

For processor activities, the evidence focus shifts to documented instructions, contract controls, subprocessor governance, security measures, assistance obligations, incident support, and return or deletion at termination. That is where REG08 becomes critical.

Clarysec’s Processor, Subprocessor and Third-Party Privacy Management Policy requires:

[Controller] The Privacy Lead / PIMS Manager MUST verify that processor contract-control fields in REG08 address processing scope, duration, purpose, PII categories, PII principal categories, confidentiality, security, subprocessor authorization, assistance, audit or assurance, return, deletion, and termination before approval.

From section “Contract and documented instruction controls”, policy clause 4.3.2.

REG02 establishes the processing activity and role. REG04 screens privacy risk. REG08 validates processor, subprocessor, and supplier controls. REG12 indexes the evidence. Together, they create the PIMS evidence chain.

The PIMS Evidence Chain Auditors Expect

A strong PIMS does not ask teams to maintain disconnected spreadsheets. It defines evidence objects, owners, timing, review cycles, and audit trails.

Clarysec’s PIMS Documented Information and Evidence Management Policy states:

[All] The Privacy Lead / PIMS Manager MUST maintain a PIMS documented information index in REG12 before initial PIMS publication and quarterly thereafter.

REG12 prevents the privacy program from becoming a folder of stale PDFs. It tells the auditor what evidence exists, where it is stored, who owns it, when it was last reviewed, and which processing activities, risks, obligations, or controls it supports.

This evidence chain aligns naturally with ISO/IEC 27001:2022 requirements for context, interested parties, risk planning, operational control, documented information, performance evaluation, internal audit, management review, and continual improvement. It also connects to ISO/IEC 27002:2022 controls such as 5.2 Information security roles and responsibilities, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.34 Privacy and protection of PII, and 8.10 Information deletion.

Controller and Processor Evidence Are Not the Same

Ava’s German customer is not only asking whether FinScale has privacy policies. The customer wants proof that FinScale understands which hat it is wearing for each data flow.

When acting as a controller, FinScale must justify why it processes data. For example, employee payroll processing may rely on contract necessity and legal obligation. Marketing may rely on consent or legitimate interests depending on context and jurisdiction. Recruitment may require retention limits, transparency, and access controls. The evidence is not just the selected lawful basis. It is the validated record, the notice, the retention rule, the rights procedure, and the risk decision.

When acting as a processor, FinScale must prove that it acts under documented customer instructions. The evidence includes the DPA, product configuration, system logs, security controls, subprocessor authorizations, assistance procedures, breach support process, audit rights, and deletion or return evidence.

Clarysec’s P17 Data Protection and Privacy Policy reinforces that privacy must be integrated into the ISMS:

The organization shall maintain a formal Privacy Governance Framework integrated into the Information Security Management System (ISMS) to enforce this policy.

From section “Governance Requirements”, policy clause 5.1.

The SME version, Data Protection and Privacy Policy-sme, keeps the same evidence discipline:

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

It also requires:

The lawful basis (e.g., consent, contract, legal obligation) must be documented in the processing register

For enterprise programs, the P17 Data Protection and Privacy Policy adds ownership:

The Legal Department shall maintain and update the Lawful Basis Register.

A Practical Walkthrough: Launching Product Analytics

Consider a product analytics feature that tracks user navigation, feature adoption, session metadata, organization ID, user role, and device information. Product wants usage insights. Sales wants adoption metrics. Customer success wants churn signals. Legal asks whether FinScale is a controller or processor. Security asks whether logs contain personal data. Procurement notes that the analytics vendor uses subprocessors.

A strong PIMS turns this into a repeatable workflow.

1. Create or update REG02 before processing begins

The business owner records the activity in REG02. The record should include purpose, PII categories, PII principal categories, systems, retention period, transfers, security measures, role classification, and lawful basis or documented instruction.

If analytics are used for FinScale’s own product improvement purposes, FinScale may be a controller for that activity. If analytics are performed only under customer-configured settings on behalf of the customer, FinScale may be a processor. In many SaaS environments, both roles can exist in one feature, depending on data flow and purpose.

2. Validate lawful basis or documented instruction

If FinScale is the controller, the Privacy Lead or Legal validates the lawful basis in REG02 before processing begins. If special category data is involved, the team must also identify the relevant GDPR Article 9 condition and additional safeguards.

If FinScale is the processor, the evidence must point to the customer’s documented instruction. The question becomes: where is the instruction, what processing is permitted, and how does FinScale prove it followed the instruction?

3. Trigger REG04 privacy risk screening

Clarysec’s Privacy Risk Assessment and DPIA Policy requires:

[Both] The Process Owner / Business Owner MUST initiate privacy risk screening in REG04 before new or materially changed PII processing recorded in REG02 begins.

From section “Privacy risk screening”, policy clause 4.1.1.

The screening should evaluate sensitivity, scale, monitoring implications, data subject expectations, profiling, automated decisions, cross-border transfers, vendor access, retention, and control effectiveness. If risk is elevated, the PIMS should trigger a DPIA and record the decision.

4. Update REG08 for vendors and subprocessors

If a third-party analytics provider receives PII, Procurement, Legal, and Privacy update REG08. Contract fields should address scope, duration, purpose, PII categories, confidentiality, security, subprocessor authorization, assistance, audit or assurance, return, deletion, and termination.

The Third-Party and Supplier Security Policy-sme supports this operating discipline by requiring:

Verification of data handling practices or data privacy compliance where personally identifiable information (PII) is involved

The P17 Data Protection and Privacy Policy also requires:

Procurement and Legal and Compliance teams shall verify compliance with Article 28 of the GDPR and require annual reassessment of all high-risk vendors.

5. Index evidence in REG12

Finally, the PIMS Manager updates REG12 with links to REG02, lawful basis validation, documented instruction, REG04 screening, DPIA if required, REG08 vendor record, DPA, security review, retention decision, product approval, and monitoring evidence.

That is what turns privacy by design into audit-ready proof.

Using the Zenith Blueprint to Build Traceability

Knowing what evidence to collect is only half the challenge. The harder part is building a system that reliably produces it.

The Zenith Blueprint: An Auditor’s 30-Step Roadmap frames this in the ISMS Foundation & Leadership phase, Step 2: Stakeholder Needs and ISMS Scope. The guide shows how stakeholder expectations become planned controls:

Customers
(B2B SaaS)
Data confidentiality, uptime per
SLA, breach notification within
24h
Implement access controls, encryption;
Incident response plan includes
notification procedures.

It also includes:

Action Item 4.2: Compile a list of all significant interested parties and note their requirements related to information security.

For ISO 27701:2025, extend that action item to privacy. Interested parties include customers, data subjects, regulators, processors, subprocessors, employees, product teams, internal audit, management, financial-sector clients, and sector regulators where NIS2 or DORA applies.

In the Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability, the Zenith Blueprint recommends traceability:

Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.

This creates the golden thread auditors want: requirement, risk, control, owner, evidence, test result, and improvement action.

Where Zenith Controls Fits in the PIMS Model

Clarysec’s Zenith Controls: The Cross-Compliance Guide helps teams avoid duplicate compliance programs by mapping ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control themes to other standards, audit expectations, and evidence patterns.

For ISO 27701:2025 PIMS evidence, four ISO/IEC 27002:2022 controls are especially important:

• 5.2 Information security roles and responsibilities
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.34 Privacy and protection of PII

Control 5.2 supports role clarity. A PIMS needs defined accountability for the PIMS Manager, Privacy Lead, Process Owner, Business Owner, Legal, Procurement, Security, Internal Audit, and top management.

Control 5.34 supports the core privacy obligation. The Zenith Blueprint, Controls in Action phase, Step 23, explains the audit expectation:

From an audit perspective, this control is increasingly in focus. Auditors, regulators, and customers alike want to see:

✓ Where PII resides,
✓ What lawful basis governs its processing,
✓ How access is restricted,
✓ How incidents are reported,
✓ And how the organization honors rights and maintains transparency.

The Zenith Blueprint continues:

Control 5.34 isn’t just a checkbox. It’s a statement of ethical stewardship.

Controls 5.20 and 5.21 connect PIMS evidence to supplier and ICT supply chain governance. The Zenith Blueprint, Controls in Action phase, Step 23, lists supplier agreement topics:

Key areas typically addressed in supplier agreements include:

✓ Confidentiality obligations , including scope, duration, and third-party disclosure restrictions;
✓ Access control responsibilities , such as who can access your data, how credentials are managed, and what monitoring is in place;
✓ Technical and organizational measures for data protection, encryption, secure transmission, backup, and availability commitments;
✓ Incident reporting timelines and protocols , often with defined timeframes (e.g., “notify within 24 hours”);
✓ Right to audit , including frequency, scope, and access to relevant evidence (e.g., pen test reports, SoA, certifications);
✓ Subcontractor controls , requiring your supplier to pass on equivalent security obligations to their downstream partners;
✓ End-of-contract provisions , such as data return or destruction, asset recovery, and account deactivation.

This is the bridge between GDPR accountability and ISMS evidence.

Mapping PIMS Evidence Across GDPR, NIS2, DORA, NIST, and COBIT 2019

Privacy evidence rarely serves only one framework. A well-designed PIMS evidence object can satisfy several audit questions.

GDPR anchors privacy accountability through lawful basis, role clarity, processor contracts, rights, breach handling, and demonstrable compliance.

NIS2 matters for essential and important entities, including certain cloud providers, managed service providers, managed security service providers, data centre providers, and digital infrastructure organizations. NIS2 Article 20 places cybersecurity governance responsibility on management bodies. Article 21 requires appropriate technical, operational, and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, training, cryptography, HR security, access control, asset management, and MFA or continuous authentication where appropriate. Article 23 introduces significant incident reporting expectations, including early warning within 24 hours and incident notification within 72 hours.

DORA matters for financial entities and ICT third-party service providers in financial ecosystems. DORA Articles 5 and 6 require ICT risk governance, policies, strategy, testing, and continuous improvement. Articles 17 to 19 cover ICT incident detection, classification, escalation, reporting, root-cause analysis, and lessons learned. Articles 28 to 30 require ICT third-party risk strategy, registers, due diligence, contractual provisions, audit rights, incident assistance, data protection, exit planning, and concentration risk review.

NIST CSF 2.0 provides a governance and risk language through GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. COBIT 2019 adds governance objectives, management practices, ownership, metrics, assurance, and process capability.

The compliance advantage is clear. One controlled PIMS evidence chain can support GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, COBIT 2019, and customer due diligence.

How Auditors Will Test Your PIMS

A PIMS audit is not a document review. It is an evidence traceability exercise.

Clarysec’s P33 Audit and Compliance Monitoring Policy supports the audit model:

The organization shall maintain an Audit Register containing:

The SME equivalent, Audit and Compliance Monitoring Policy-sme, adds an important evidence quality requirement:

Metadata (e.g., who collected it, when, and from which system) must be documented.

That metadata requirement is small but powerful. Screenshots without source, date, collector, and system context are weak evidence. Controlled audit evidence proves authenticity, currency, and traceability.

What Good PIMS Evidence Looks Like

Suppose an auditor selects one activity: customer support ticket analysis.

A weak answer is: “We have a privacy policy and our DPA covers it.”

A strong PIMS answer is:

1. REG02 identifies the activity, systems, PII categories, PII principals, purpose, role classification, retention, transfers, security controls, and owner.
2. Role classification shows whether the organization is controller, processor, or both for specific parts of the workflow.
3. If controller, lawful basis is validated and recorded in the Lawful Basis Register.
4. If processor, the customer instruction and DPA clause are linked.
5. REG04 shows privacy risk screening before launch or material change.
6. REG08 identifies the ticketing platform, AI summarization vendor, subprocessors, contract controls, audit rights, security assurances, deletion terms, and incident assistance.
7. Access control evidence shows support personnel access is role-based and reviewed.
8. Logging and monitoring evidence shows access to support tickets is monitored.
9. Retention and deletion evidence shows tickets are deleted or anonymized according to the approved retention period.
10. REG12 indexes all supporting evidence with owner and review date.
11. The Audit Register shows whether the activity was tested, what findings were raised, and whether corrective actions were closed.

This is how ISO 27701:2025 becomes operational. It creates a repeatable chain of accountability.

Common PIMS Evidence Failures

Across SaaS, fintech, managed service, and B2B technology environments, the same gaps appear repeatedly.

First, organizations maintain a RoPA or processing register, but do not classify controller and processor roles per activity. That creates confusion over lawful basis, documented instructions, and subprocessor obligations.

Second, lawful basis is recorded once and not revalidated when the purpose changes. GDPR Article 6 requires purpose and lawful basis discipline. Further processing may require compatibility assessment and safeguards.

Third, vendor inventories list suppliers but do not show contract-control fields. A supplier list is not the same as processor governance.

Fourth, DPIA decisions are informal. Teams say “not high risk” but cannot show screening criteria, approver, date, or evidence.

Fifth, audit evidence exists but is uncontrolled. Screenshots lack metadata. Policies are current, but registers are stale. Contracts exist, but renewal reassessments are missed.

Sixth, incident processes focus on cybersecurity events but do not clearly classify personal data breaches. GDPR personal data breach analysis, NIS2 significant incident reporting, and DORA ICT incident reporting must be coordinated, not duplicated.

Clarysec addresses these failures by treating PIMS evidence as a controlled management system, not a last-minute audit scramble.

ISO 27701:2025 PIMS Evidence Readiness Checklist

Use this checklist for your next internal readiness review.

• Define PIMS scope and interested parties, including customers, regulators, data subjects, vendors, internal audit, and management.
• Assign PIMS roles and responsibilities, including PIMS Manager, Privacy Lead, Process Owner, Legal, Procurement, Security, and Internal Audit.
• Create REG02 entries for every PII processing activity.
• Classify controller, processor, joint controller, or subprocessor role for each activity.
• Validate lawful basis for controller processing before processing begins and before purpose change.
• Record documented instructions for processor activities.
• Trigger REG04 privacy risk screening before new or materially changed processing.
• Complete a DPIA where risk screening indicates elevated privacy risk.
• Maintain REG08 for processors, subprocessors, ICT suppliers, and privacy-relevant vendors.
• Verify contract fields for scope, duration, purpose, PII categories, confidentiality, security, assistance, audit rights, return, deletion, and termination.
• Maintain REG12 as the PIMS documented information index.
• Map PIMS evidence to ISO/IEC 27001:2022 risk treatment and SoA notes.
• Cross-reference GDPR, NIS2, DORA, NIST CSF 2.0, and COBIT 2019 obligations where relevant.
• Conduct annual internal privacy compliance audits and update the Audit Register.
• Review open findings, corrective actions, risk decisions, and management reporting quarterly.

The P17 Data Protection and Privacy Policy reinforces the audit cycle:

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

The message is simple. Privacy compliance is monitored, not assumed.

Build Your PIMS Evidence Model With Clarysec

ISO 27701:2025 is most valuable when it is integrated with ISO/IEC 27001:2022 and designed to produce evidence by default. That is how privacy becomes a defensible operating model rather than a certification project.

When a customer asks for privacy assurance, you can show evidence. When a regulator asks why you processed data, you can show role, purpose, lawful basis, safeguards, and approvals. When an auditor asks how you govern subprocessors, you can show REG08, contract controls, reassessments, and audit rights. When the board asks whether privacy risk is under control, you can show metrics, open actions, audit results, and management review.

If your PIMS is still policy-heavy and evidence-light, start with the chain auditors will follow:

REG02 processing inventory, REG04 privacy risk screening, REG08 processor and subprocessor governance, REG12 evidence index, Lawful Basis Register, Audit Register, and SoA mapping.

Clarysec can help you operationalize that chain through:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap, especially Step 2 for stakeholder requirements, Step 13 for risk treatment and SoA traceability, and Step 23 for privacy, supplier, and organizational controls.
• Zenith Controls: The Cross-Compliance Guide, using ISO/IEC 27002:2022 controls 5.2, 5.20, 5.21, and 5.34 as practical privacy accountability anchors.
• Clarysec’s ISO 27701 PIMS policy set, including Privacy Information Management System Policy, PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Processor, Subprocessor and Third-Party Privacy Management Policy, and PIMS Documented Information and Evidence Management Policy.
• Enterprise and SME support through P17 Data Protection and Privacy Policy, Data Protection and Privacy Policy-sme, Third-Party and Supplier Security Policy-sme, P33 Audit and Compliance Monitoring Policy, and Audit and Compliance Monitoring Policy-sme.

Your next action is simple: choose one high-risk PII processing activity and walk the evidence chain from REG02 to REG12. If the chain breaks, that is your first improvement project. If it holds, expand the model across your processing inventory.

That is how ISO 27701:2025 becomes more than a certificate. It becomes proof of GDPR accountability.