PII Access Governance for ISO 27701:2025 and GDPR

The external auditor’s question hung in the air, deceptively simple.

“Can you show me the access review log for your support team’s access to production PII over the last quarter?”

For Anya, CISO at Medtelligence, a fast-growing health-tech SaaS provider, this was the moment of truth. Medtelligence acts as a PII processor for hospitals and handles sensitive patient data in a cloud platform. The company had strong authentication, defined roles, and a mature engineering team. But the auditor was not asking whether a login page existed. He was asking for proof that access to personal data was governed over time.

He wanted to see who could access production PII, why they had access, when the access was approved, whether it was still needed, whether support activity was logged, and whether unnecessary permissions had been removed.

Anya opened the IAM console. There were support engineers, database administrators, an integration service account, a managed service provider, two emergency break-glass roles, and a former contractor still present in a group because the offboarding ticket had been closed before the entitlement was removed. HR showed the person had left six weeks earlier. The access review spreadsheet said “pending.” The SIEM had logs, but nobody had mapped which events proved access to PII.

This is where privacy governance becomes real.

Under GDPR, personal data must be processed with integrity and confidentiality, protected against unauthorized or unlawful processing, accidental loss, destruction, or damage through appropriate technical and organisational measures. GDPR also makes accountability explicit: the controller must be able to demonstrate compliance. ISO/IEC 27701:2025 turns that accountability into a privacy information management system, or PIMS, where access to PII is no longer a technical afterthought. It becomes a governed lifecycle across roles, processors, cloud platforms, employees, privileged administrators, logs, reviews, contracts, and evidence.

The gap for many organizations is not that they lack access control. The gap is that they cannot prove PII access governance consistently across ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0, and COBIT 2019.

PII access governance is not just IAM

A traditional IAM program asks, “Can the right users access the right systems?”

A mature ISO/IEC 27701:2025 PIMS asks harder questions:

• Which systems process PII?
• Which roles require access to which categories of PII?
• Is the organization acting as a PII controller, processor, joint controller, or subprocessor?
• Is access limited by purpose, documented business need, and least privilege?
• Are privileged actions logged and reviewed?
• Can the organization prove that processor and subprocessor access is contractually controlled?
• Are cloud support paths, tenant isolation, exports, and administrative actions included in evidence?
• Are access decisions reviewed after onboarding, role change, incident, offboarding, and material system change?

This is why PII security and access control governance is a natural bridge between ISO/IEC 27701:2025 and GDPR. GDPR gives the legal accountability frame. ISO/IEC 27701:2025 operationalizes privacy management for controllers and processors. ISO/IEC 27001:2022 provides the ISMS risk management engine. ISO/IEC 27002:2022 provides the control architecture, including privacy and protection of PII, access control, access rights, logging, cloud services, supplier relationships, classification, deletion, masking, and cryptography.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap places this in the Controls in Action phase. In Step 23, covering organizational controls 5.19 to 5.37, it describes ISO/IEC 27002:2022 control 5.34, Privacy and Protection of PII, as a trust issue, not merely a data issue:

personally identifiable information isn’t just another data type, it’s a deeply sensitive representation of trust. Names, addresses, IDs, health records, financial details, this data tells a story about real people.

The same passage gives the practical foundation: privacy protection starts with data awareness. An organization must know what PII it collects, where it resides, why it is processed, and who can access it.

The compliance pressure behind PII access control

PII access governance is no longer a single-framework issue. Organizations like Medtelligence operate at the intersection of privacy regulation, cybersecurity law, operational resilience, customer assurance, and security certification.

GDPR Article 5 requires personal data to be processed according to lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. Article 5(2) introduces accountability: the controller is responsible for, and must be able to demonstrate, compliance. Article 32 then requires appropriate technical and organisational measures for security of processing.

NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organisational cybersecurity risk-management measures. Its minimum domains include risk analysis, security policies, incident handling, business continuity, supply-chain security, secure acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, HR security, access control, asset management, and, where appropriate, multi-factor or continuous authentication and secure communications. Article 20 also places responsibility on management bodies to approve and oversee cybersecurity risk-management measures.

DORA applies from 17 January 2025 to a broad range of financial entities and creates a sector-specific operational resilience regime. It covers ICT risk management, major ICT-related incident reporting, digital operational resilience testing, information sharing, ICT third-party risk, and contractual arrangements with ICT third-party service providers. For financial entities and ICT service providers supporting them, access control is not only a privacy issue. It is part of operational resilience.

ISO/IEC 27001:2022 ties these obligations into a risk-based management system. Clauses 6.1.1 to 6.1.3 require organizations to address risks and opportunities, define an information security risk assessment process, identify risks to confidentiality, integrity, and availability, evaluate risks, select treatment options, determine controls, compare selected controls with Annex A, document the Statement of Applicability, obtain risk owner approval, and accept residual risks. Clauses 8.2 and 8.3 require risk assessments at planned intervals or after significant change, and implementation of the risk treatment plan with documented results.

For PII governance, this means access control is not an isolated IAM setting. It is a risk treatment decision. A role that can export payroll records, patient data, payment details, identity documents, location data, or customer support transcripts must be justified in the risk register, reflected in the Statement of Applicability, enforced in IAM, logged in production, reviewed periodically, and removed when no longer required.

The Clarysec control model: from privacy promise to evidence

Clarysec treats PII access governance as a chain of evidence. The chain starts with data inventory and role definition, moves through access approval and enforcement, and ends with monitoring, review, revocation, and audit-ready records.

In Zenith Controls: The Cross-Compliance Guide, the topic sits primarily around three ISO/IEC 27002:2022 controls:

Auditors rarely accept “we use IAM” as evidence. They expect to see how IAM decisions tie back to privacy obligations, system ownership, data classification, business need, risk treatment, access review frequency, logging scope, and supplier contracts.

Clarysec’s PII Security and Access Control Policy sets the baseline in PIMS language:

[Both] The System Owner / Application Owner MUST restrict access to PII to approved roles and authorized users recorded or traceable in REG02 or REG12 before access is enabled.

From section “4.2 Access control baseline”, policy clause 4.2.1.

The tag “[Both]” means the control applies whether the organization acts as a PII controller or PII processor. That distinction matters. Controllers often fail to define purpose-based access rules. Processors often fail to prove that access is limited to customer instructions, approved support paths, and contractually authorized personnel.

The same policy raises the bar for sensitive or high-impact PII:

[Both] The System Owner / Application Owner MUST review user access to systems processing high-impact or sensitive PII at least quarterly and record the review outcome in REG12.

From section “4.2 Access control baseline”, policy clause 4.2.3.

This is where a PIMS becomes auditable. The access review is not just a manager email. It is a record in REG12, tied to a system, data category, role, owner, review outcome, and remediation action.

Policy foundation: least privilege, business need, and default denial

Effective governance begins with enforceable rules. Before Anya could show the auditor an access review log, she needed to show that the requirement for access reviews was formally established.

Clarysec’s SME Access Control Policy - SME sets the principle:

This policy enforces the principle of least privilege and requires that access be limited to the minimum necessary to perform job functions.

From section “Purpose”, policy clause 1.3.

The SME Data Protection and Privacy Policy - SME ties access to business need:

User access to personal data must be limited to roles with a documented business need

From section “Governance Requirements”, policy clause 5.3.2.

For larger organizations, the enterprise Data Protection and Privacy Policy expresses the control expectation as a system requirement:

All systems shall enforce least privilege access by default.

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

The distinction is important. A smaller company may need a lightweight but explicit business-need record. An enterprise needs system-level enforcement, periodic review, segregation of duties, privileged access governance, and evidence preserved for internal audit, customer assurance, regulator inquiries, and breach investigation.

The PII access lifecycle: approval, use, review, revocation

The most common PII access failure is not initial approval. It is access persistence.

The Zenith Blueprint, in the Controls in Action phase, Step 22, explains ISO/IEC 27002:2022 control 5.18, Access Rights, this way:

Control 5.18 ensures that access rights are not only granted appropriately, but also reviewed, adjusted, and revoked in a controlled and traceable manner.

It then describes familiar scenarios: a new hire receives access, changes roles, and keeps old permissions; a former admin leaves but a token remains active; a contractor account expires on paper but not in IAM. These are precisely the weaknesses that become GDPR security incidents when PII is involved.

Clarysec’s SME User Account and Privilege Management Policy - SME sets a baseline cadence:

A review of all user accounts and privileges must be performed every six months.

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

For enterprise environments, the User Account and Privilege Management Policy tightens the operating rhythm:

Quarterly reviews of all user accounts and associated privileges must be conducted by IT Security in collaboration with department managers.

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

A practical PII access lifecycle should include:

1. Classify the system and PII categories.
2. Define approved roles and documented business need.
3. Map roles to processing purposes.
4. Approve access before enablement.
5. Enforce least privilege, segregation of duties, and strong authentication.
6. Log authentication, access, export, configuration, and privileged actions.
7. Review access on a risk-based cadence.
8. Remove access on role change, termination, project closure, contract expiry, or customer instruction.
9. Preserve evidence in the PIMS register and audit trail.

This is not bureaucracy. It is how an organization proves that PII access is controlled by design, by default, and by evidence.

A practical example: the quarterly PII access review

Anya’s audit succeeded when she shifted the conversation from policy statements to evidence.

First, she cited the PII Security and Access Control Policy, clause 4.2.3, which required quarterly review of high-impact or sensitive PII access and recording of the review outcome in REG12.

Then she walked the auditor through the previous quarter:

• IT generated a list of all users, groups, privileged roles, service accounts, supplier accounts, break-glass roles, and support permissions for the production database containing patient data.
• The list was sent to the Application Owner, the Head of Customer Success, who owned the support team’s operational need.
• The Application Owner reviewed the list line by line against current role, customer support responsibility, and processing purpose.
• Two support agents who had moved teams were marked for revocation.
• A ticket was created in the IT service management system, linked to the access review, assigned an SLA, and closed after revocation.
• REG12 was updated with the review record, approver, exceptions, remediation ticket, closure evidence, and next review date.

The result was a closed-loop evidence chain. Anya did not just say Medtelligence used least privilege. She showed the policy requirement, responsible owner, access list, review decision, corrective action, and completed revocation.

That is the difference between access control and access governance.

Supplier and processor access: the blind spot in PIMS audits

Many unauthorized access risks enter through support, outsourcing, integration partners, managed service providers, and subprocessors. A processor may have remote access to customer production data. A cloud provider may provide support access pathways. A subprocessor may maintain a search index containing customer identifiers. A managed security service provider may access logs containing personal data.

Under GDPR, controllers must use processors that provide sufficient guarantees. Under ISO/IEC 27701:2025, processor and subprocessor governance must be operationalized through documented instructions, contract controls, assurance, and monitoring. ISO/IEC 27002:2022 supports this through supplier relationship controls, including 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, and 5.21 Managing information security in the ICT supply chain.

The Zenith Blueprint, Controls in Action phase, Step 23, summarizes supplier agreement evidence areas including:

✓ Access control responsibilities , such as who can access your data, how credentials are managed, and what monitoring is in place;

It also includes confidentiality obligations, technical and organizational measures, incident reporting timelines, right to audit, subcontractor controls, and end-of-contract account deactivation.

Clarysec’s Processor, Subprocessor and Third-Party Privacy Management Policy converts that into controller-side PIMS evidence:

[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 “4.3 Contract and documented instruction controls”, policy clause 4.3.2.

Supplier access is also controlled directly in Clarysec’s SME and enterprise supplier policies. The SME Third-Party and Supplier Security Policy - SME states:

Suppliers must be granted access only to the minimum systems and data required to perform their function.

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

The enterprise Third party and supplier security policy adds RBAC, review, and least privilege:

Supplier personnel must be subject to role-based access control (RBAC), periodic access reviews, and enforcement of least privilege.

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

If supplier access can reach PII, it belongs in the PIMS. It should appear in contract controls, access approvals, IAM groups, logging scope, review records, offboarding records, incident playbooks, and audit evidence.

Cloud PII access: shared responsibility is not shared accountability

Cloud PII access governance is where organizations often overestimate the provider and underestimate their own responsibilities. The cloud provider may secure the infrastructure, but the customer still governs identities, roles, tenant configuration, support access, logs, encryption settings, export permissions, and incident response readiness.

The Zenith Blueprint, Controls in Action phase, Step 23, states this bluntly in its cloud services guidance:

Cloud providers secure the infrastructure, but you are still accountable for your data, your configurations, your access policies, and your incident response readiness.

It also warns:

In the cloud, visibility is partial unless deliberately engineered. You need to configure logging, enforce encryption, define identity roles, and monitor activity through native tools or third-party integrations. That’s not an infrastructure task, it’s an ISMS requirement.

Clarysec’s Cloud Usage Policy turns this into an enterprise access requirement:

All cloud services must enforce identity-based access control aligned with the principle of least privilege.

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

For organizations acting as processors in cloud environments, Clarysec’s Cloud PII Processor Policy defines a more specific PIMS review obligation:

[Processor] The Information Security Lead MUST review privileged cloud access, support access, customer PII access and logging coverage in REG12 at least quarterly.

From section “4.2 Cloud Configuration, Tenant Isolation, Access and Logging”, policy clause 4.2.4.

That clause is especially relevant for SaaS companies, cloud-hosted platforms, managed data services, and B2B processors.

Cloud PII access governance is not complete unless cloud-native logs, IAM policies, service accounts, privileged roles, customer support tooling, API keys, and data export functions are reviewed together.

Logging and monitoring: the memory of PII governance

A PIMS access control program without logs is a promise without memory.

The PII Security and Access Control Policy requires logging scope before production use or material change:

[Both] The System Owner / Application Owner MUST define the PII logging scope for authentication events, access events, privileged actions, PII export activity and material configuration changes in REG12 before production use or material change.

From section “4.6 Logging and monitoring”, policy clause 4.6.1.

The SME Logging and Monitoring Policy - SME makes the content of access logs explicit:

Access logs: File access (especially for sensitive or personal data), permission changes, shared resource usage

From section “Governance Requirements”, policy clause 5.4.3.

The enterprise Logging and Monitoring Policy focuses on audit usability:

The ISMS Audit Trail Register must record log data availability for audits, investigations, and regulatory reviews.

From section “Governance Requirements”, policy clause 5.4.

This is critical because privacy evidence often has to answer event-based questions:

• Who accessed the PII?
• Was access authorized?
• Was access linked to a support ticket, legal request, operational task, or customer instruction?
• Was data exported, copied, altered, or deleted?
• Was privileged access used?
• Were permissions changed before or after access?
• Did the activity indicate a security incident or personal data breach?

Logs are not just for the SOC. They are PIMS evidence, customer assurance evidence, processor assurance evidence, and incident response evidence.

Cross-compliance mapping: one access model, many lenses

A weakness in PII access reviews is never just one finding. It can become a GDPR accountability problem, an ISO/IEC 27701:2025 PIMS weakness, an ISO/IEC 27001:2022 nonconformity, a NIS2 governance failure, a DORA resilience concern, a NIST CSF 2.0 governance gap, or a COBIT 2019 process maturity issue.

A more detailed control crosswalk shows how a single PII access governance process supports multiple requirements:

The value of Zenith Controls is that teams can map these lenses back to the same control evidence rather than maintaining separate compliance silos.

Run a 45-minute PII access evidence sprint

A useful way to test readiness is to choose one high-impact system, such as a customer support platform, HR system, payment portal, patient portal, data lake, or SaaS production database, and run a focused evidence sprint.

Step 1: Define the PII processing context

Record in REG12:

• System name and owner
• PII categories
• PII principal categories
• Controller or processor role
• Processing purpose
• High-impact or sensitive PII indicator
• Cloud, supplier, and subprocessor dependencies

If the system involves a processor, verify REG08 contract-control fields using the Processor, Subprocessor and Third-Party Privacy Management Policy. Approval should cover processing scope, duration, purpose, PII categories, PII principal categories, confidentiality, security, subprocessor authorization, assistance, audit or assurance, return, deletion, and termination.

Step 2: Pull the access list

Export all users, groups, privileged roles, service accounts, support roles, break-glass accounts, API keys, and supplier accounts. Compare each entitlement to approved roles.

Step 3: Confirm least privilege and purpose alignment

Use the PII Security and Access Control Policy baseline: access must be restricted to approved roles and authorized users recorded or traceable in REG02 or REG12 before enablement. If a user cannot be traced to role, purpose, and approval, the finding is not “documentation missing.” The finding is “PII access not demonstrably authorized.”

Step 4: Verify logging scope

Confirm that logs capture authentication, access events, privileged actions, PII export activity, and material configuration changes. Then confirm where logs are stored, how long they are retained, who can access them, and whether they are recorded in the ISMS Audit Trail Register for audits, investigations, and regulatory reviews.

Step 5: Close the loop

For each exception, record the risk owner, immediate containment action, permanent remediation, target date, evidence required, residual risk decision, and whether breach assessment is needed.

This one exercise usually reveals the real maturity of PII access governance. Strong organizations can answer quickly. Weak organizations discover that privacy policy, IAM configuration, processor contracts, cloud logging, and audit evidence are disconnected.

Common audit findings in PII access governance

Most findings are predictable. They arise when privacy, security, legal, IT, and suppliers each control part of the story, but nobody owns the complete PII access lifecycle.

Common findings include:

• PII systems are not fully listed in the PIMS inventory.
• Access roles are defined technically but not mapped to processing purposes.
• Sensitive PII is accessible through broad operational groups.
• Quarterly reviews cover employees but not service accounts, API keys, or supplier users.
• Cloud support access is possible but not reviewed as PII access.
• Logs exist but do not prove PII access, export, or privileged activity.
• Processor contracts include generic confidentiality clauses but not specific access control, audit, subprocessor, return, deletion, or termination controls.
• Former employees or contractors retain access through shared groups or unmanaged tokens.
• Data warehouse access is broader than source application access.
• Break-glass accounts exist without post-use review.
• Customer support impersonation is not logged with ticket context.
• The Statement of Applicability includes access controls, but evidence does not show PII-specific implementation.

Each of these findings can become a GDPR accountability problem, a customer assurance issue, a NIS2 or DORA governance weakness, or an ISO/IEC 27001:2022 nonconformity depending on scope.

What good looks like

A mature operating model does not rely on heroic quarterly cleanups. It embeds PII access governance into normal operations.

First, the organization has data awareness. It knows where PII exists, why it is processed, which PIMS role applies, and which systems, suppliers, cloud services, logs, backups, and exports are in scope.

Second, access is role-based and purpose-aligned. Permissions are defined by approved roles, documented business need, processing purpose, and least privilege.

Third, controls are technically enforced. IAM, RBAC, privileged access management, MFA, conditional access, tenant controls, encryption, and environment segregation enforce policy expectations.

Fourth, monitoring is deliberate. The organization can reconstruct authentication, access, export, privileged action, support access, and configuration changes affecting PII.

Fifth, reviews are risk-based and documented. High-impact PII receives at least quarterly review. Supplier and cloud support access are included. Exceptions are tracked to closure.

Sixth, evidence is reusable. The same records support GDPR accountability, ISO/IEC 27701:2025 PIMS operation, ISO/IEC 27001:2022 risk treatment, NIS2 risk-management measures, DORA ICT risk governance, NIST CSF 2.0 GOVERN outcomes, and COBIT 2019 management assurance.

This is the difference between access control as a setting and access governance as a system.

Turn PII access into audit-ready evidence

If your next audit, customer review, or regulator inquiry began tomorrow with “show me who can access PII,” would your team produce evidence in minutes, or would it start reconciling spreadsheets?

Clarysec can help you close that gap.

Start with the PII Security and Access Control Policy, align processor and cloud obligations through the Processor, Subprocessor and Third-Party Privacy Management Policy and Cloud PII Processor Policy, then use Zenith Blueprint: An Auditor’s 30-Step Roadmap to implement controls in the right sequence. Finally, use Zenith Controls: The Cross-Compliance Guide to map PII access evidence across ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0, and COBIT 2019.

The fastest practical next step is simple: select one high-impact PII system, populate REG12, export the access list, verify logging scope, and run a quarterly-style review. In one session, you will know whether your PII access governance is audit-ready, or only policy-ready.