Audit-Ready PII Protection for GDPR, NIS2 and DORA
The alert landed in Sarah’s inbox at 10 PM on a Tuesday.
As CISO of a scaling FinTech SaaS company, late-night alerts were familiar. This one was different. A junior developer had exposed a staging database to a public endpoint while testing a new analytics feature. The database was supposed to contain test data, but a recent production-to-staging sync had filled it with real customer PII.
The incident was contained quickly. Then the second discovery arrived. A migration spreadsheet called customer_users_final_v7.xlsx had been copied from the same data set. It contained names, emails, role permissions, usage logs, country fields, support notes, and free-text comments that should never have entered a testing workflow. It had been copied to a shared drive, downloaded by a developer, attached to a ticket, and forgotten.
By midnight, Sarah was no longer managing a technical misconfiguration. She was managing an audit problem.
The company was already certified to ISO/IEC 27001:2022. The board was asking for GDPR assurance before an EU market launch. Financial-services customers were sending DORA due diligence questionnaires. Cloud and managed-service relationships were raising NIS2 supply-chain questions. Legal could explain the obligations. Engineering could point to encryption. Product had privacy-by-design intentions. The Statement of Applicability mentioned privacy and protection of PII.
But nobody could show, in one traceable chain, what PII existed, why it was processed, who could access it, where it was masked, which suppliers touched it, how long it was retained, and how an incident would be classified under GDPR, NIS2, or DORA.
That gap is exactly why ISO/IEC 27701:2025 and ISO/IEC 29151:2022 matter. They are not just privacy labels. They help organizations turn privacy promises into audit-ready PII protection controls. ISO/IEC 27701:2025 extends an ISO/IEC 27001:2022 information security management system into privacy information management. ISO/IEC 29151:2022 adds practical guidance for protecting personally identifiable information across its lifecycle.
Clarysec’s approach is to build one evidence-driven privacy and security operating model, not separate compliance silos. That model combines Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls, and Clarysec policies into a single traceable system for GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, NIST-style assurance, and COBIT 2019 governance expectations.
Why PII protection is now a board-level audit issue
PII protection used to be treated as a privacy-team responsibility. Today, it is a board-level trust, resilience, and regulatory issue.
GDPR remains the baseline for personal data protection in Europe and beyond. It defines personal data, processing, controller, processor, recipient, third party, consent, and personal data breach in ways that affect SaaS contracts, support operations, analytics, product telemetry, vendor management, and incident response. Its principles require lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality, and accountability. In audit terms, GDPR does not only ask whether data is encrypted. It asks whether the organization can demonstrate why data exists and how compliance is achieved.
NIS2 raises the cybersecurity governance bar for essential and important entities. Article 21 requires cybersecurity risk-management measures, including risk analysis, information system security policies, incident handling, business continuity, supply-chain security, secure development, vulnerability handling, control effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management, authentication, and secure communications. Article 23 adds staged incident reporting, including an early warning within 24 hours, notification within 72 hours, and a final report within one month after the notification.
DORA changes the conversation for financial entities and their ICT providers. It applies from 17 January 2025 and creates a harmonized digital operational resilience regime covering ICT risk management, major ICT-related incident reporting, resilience testing, ICT third-party risk, contractual requirements, and oversight of critical ICT third-party service providers. For many financial entities, DORA functions as the sector-specific Union legal act where NIS2-equivalent obligations overlap. For SaaS and ICT suppliers serving financial institutions, DORA pressure often arrives through contract clauses, customer audits, exit-planning requirements, incident-support obligations, and resilience testing.
ISO/IEC 27001:2022 provides the management-system backbone. It requires context, interested parties, scope, leadership accountability, policies, roles, risk assessment, risk treatment, Statement of Applicability, internal audit, management review, and continual improvement. Annex A includes controls directly relevant to PII protection, including 5.34 Privacy and protection of PII, 5.18 Access rights, 8.11 Data masking, 5.23 Information security for use of cloud services, 8.15 Logging, 8.33 Test information, 8.24 Use of cryptography, and 8.10 Information deletion.
The challenge is not that organizations have no controls. It is that controls are fragmented. Privacy records live with legal. Access reviews live with IT. Masking scripts live with engineering. Supplier contracts live with procurement. Evidence lives in tickets, screenshots, spreadsheets, and email.
ISO/IEC 27701:2025 and ISO/IEC 29151:2022 help unify that evidence around privacy information management and PII protection practices. Clarysec turns that structure into an operating model.
From ISMS to PIMS: the integrated privacy control chain
An ISO/IEC 27001:2022 ISMS answers a core question: is information security governed, risk-based, implemented, monitored, and improved?
A Privacy Information Management System, or PIMS, extends that question for personal data: are privacy responsibilities, PII processing activities, privacy risks, controller and processor obligations, data subject rights, and privacy control evidence managed inside the same system?
ISO/IEC 27701:2025 extends the ISMS into privacy governance. ISO/IEC 29151:2022 complements it with practical PII protection guidance, including limiting collection, managing disclosure, applying masking or pseudonymization, protecting transfers, restricting access, and aligning controls with privacy risk.
| Layer | Primary question | Typical audit evidence |
|---|---|---|
| ISO/IEC 27001:2022 | Is there a governed, risk-based ISMS with selected and operating controls? | Scope, interested parties, risk assessment, treatment plan, SoA, policies, internal audit, management review |
| ISO/IEC 27701:2025 | Are privacy responsibilities, privacy risks, and PII processing activities governed inside the management system? | Privacy roles, processing register, controller and processor procedures, privacy risk assessments, DPIAs, data subject request process |
| ISO/IEC 29151:2022 | Are practical PII protection measures implemented across the data lifecycle? | PII classification, access restrictions, masking, pseudonymization, retention controls, transfer safeguards, incident evidence |
| GDPR | Can the organization demonstrate lawful, fair, transparent, minimized, secure, and accountable processing? | Lawful basis records, privacy notices, DPIAs, breach process, processor agreements, rights handling |
| NIS2 and DORA | Can the organization govern cybersecurity and resilience risks, including incidents and suppliers? | Management oversight, ICT risk framework, incident classification, reporting playbooks, supplier registers, audit rights, continuity tests |
This layered model prevents the most common mistake in privacy compliance: treating PII as just another sensitive data type. PII carries legal, ethical, operational, contractual, and reputational obligations. It needs a control chain that starts with awareness and ends with evidence.
Start with data awareness, not encryption diagrams
The most common privacy failure Clarysec sees is missing context. A company cannot protect PII if it does not know what PII it has, where it resides, what purpose it serves, how long it is kept, or who can reach it.
The Zenith Blueprint starts this work early in the Risk Management phase. In Step 9, Identifying Assets, Threats, and Vulnerabilities, it instructs organizations to inventory information assets and explicitly flag personal data:
“For each asset, record key details: Name/Description, Owner, Location, and Classification (sensitivity). For example, an asset could be ‘Customer Database – owned by IT Dept – hosted on AWS – contains personal and financial data (High sensitivity).’”
It also adds: “Ensure personal data assets are flagged (for GDPR relevance) and critical service assets are noted (for potential NIS2 applicability if you’re in a regulated sector).”
This is the foundation for ISO/IEC 27701:2025 and ISO/IEC 29151:2022 adoption. The practical sequence is simple:
- Identify systems, datasets, repositories, logs, reports, backups, support tools, development environments, and suppliers that process PII.
- Assign an owner to each PII asset.
- Classify PII by sensitivity, business purpose, lawful basis, processing role, and retention requirement.
- Connect each PII asset to threats, vulnerabilities, risk scenarios, and regulatory obligations.
- Select controls, assign evidence, and monitor operation over time.
Clarysec policies make this executable. The SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME states:
“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.
For enterprise organizations, the Data Protection and Privacy Policy Data Protection and Privacy Policy establishes a strict minimization rule:
“Only data necessary for a specific, legitimate business purpose may be collected and processed.”
From section ‘Policy Implementation Requirements’, policy clause 6.2.1.
These clauses transform GDPR accountability into daily operations. They also support privacy information management and PII protection because they force the organization to define what data exists, why it exists, and whether it is necessary.
The three controls that make PII protection real
Three ISO/IEC 27001:2022 Annex A controls often determine whether PII protection is defensible under audit: 5.34 Privacy and protection of PII, 8.11 Data masking, and 5.18 Access rights.
5.34 Privacy and protection of PII
Control 5.34 is the governance hub. In Zenith Controls, 5.34 is treated as a preventive control supporting confidentiality, integrity, and availability, with Identify and Protect cybersecurity concepts and operational capabilities in information protection and legal compliance.
Zenith Controls makes the dependency clear:
“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.”
Control 5.34 depends on 5.9 Inventory of information and other associated assets because PII cannot be protected if it cannot be found. It also connects to 5.23 Information security for use of cloud services because most PII now lives in cloud platforms, SaaS tools, analytics environments, and managed services.
For high-risk processing, the enterprise Data Protection and Privacy Policy requires:
“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.
That clause is critical. It turns privacy into a design and risk-management activity, not a last-minute legal review.
8.11 Data masking
Control 8.11 is the direct answer to Sarah’s staging database exposure. Zenith Controls describes 8.11 as a preventive confidentiality control under information protection. It links 8.11 to 5.12 Classification of information because masking decisions depend on sensitivity, to 5.34 because masking supports privacy protection, and to 8.33 Test information because test environments should not expose real PII.
The Data Masking and Pseudonymization Policy Data Masking and Pseudonymization Policy makes the rule explicit:
“Real personal data must not be used in development, test, or staging environments. Masked or pseudonymized data must be used instead and must be generated from pre-approved transformation templates.”
From section ‘Policy Implementation Requirements’, policy clause 6.3.
For SMEs, Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME adds a key security and evidence requirement:
“Access to keys must be encrypted, access-controlled, and logged.”
From section ‘Policy Implementation Requirements’, policy clause 6.2.1.3.
This matters because pseudonymization only reduces risk when transformation logic, keys, and re-identification paths are controlled.
5.18 Access rights
Control 5.18 is the operational heart of least privilege. Zenith Controls treats it as preventive, linked to confidentiality, integrity, and availability, and placed under identity and access management. It ties 5.18 to 5.15 Access control, 5.16 Identity management, and 8.2 Privileged access rights.
The SME Data Classification and Labeling Policy-sme Data Classification and Labeling Policy - SME states:
“Access must be limited to specifically authorized users with a need-to-know.”
From section ‘Governance Requirements’, policy clause 5.2.1.
The enterprise Data Classification and Labeling Policy Data Classification and Labeling Policy adds the classification baseline:
“All information assets must have a clearly assigned classification at the time of creation or onboarding. In the absence of explicit classification, assets must default to ‘Confidential’ until formally reviewed.”
From section ‘Governance Requirements’, policy clause 5.4.
Together, these controls form the practical PII protection chain: know the PII, classify it, limit access, mask it where full identity is unnecessary, protect keys, log access, and retain evidence.
Build traceability through the Statement of Applicability
A privacy management system becomes audit-ready when it can prove traceability. The Zenith Blueprint, Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability, describes the Statement of Applicability as a bridging document:
“The SoA is effectively a bridging document: it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.”
That concept is central to ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2, and DORA readiness. Each PII control should be traceable from requirement to risk, from risk to control, from control to owner, from owner to evidence, and from evidence to review.
| Traceability item | Example for customer support PII | Evidence expected |
|---|---|---|
| PII asset | Support ticketing platform with customer names, emails, logs, and attachments | Asset register entry, owner, cloud location, classification |
| Processing purpose | Customer support and service diagnostics | Processing register, lawful basis, retention period |
| Risk scenario | Support agent or developer accesses excessive customer data | Risk register entry, likelihood, impact, owner |
| Control selection | 5.34 PII protection, 5.18 access rights, 8.11 masking, 8.15 logging, 5.23 cloud governance | SoA, access policy, masking standard, logging configuration |
| Operational evidence | Role-based access, masked exports, quarterly access review, alerting on bulk downloads | Access review records, DLP alerts, logs, ticket evidence |
| Regulatory mapping | GDPR accountability and security, NIS2 risk management, DORA ICT risk and supplier requirements | Compliance matrix, incident playbook, supplier contract register |
| Review evidence | Internal audit finding closed, management review action accepted | Audit report, corrective action, management review minutes |
ISO/IEC 27005:2022 supports this risk-based approach by emphasizing interested-party requirements, common risk criteria, accountable risk owners, repeatable risk assessment, risk treatment, control selection, Statement of Applicability alignment, residual-risk approval, monitoring, and continual improvement. PII protection should be a living risk cycle, not a one-time GDPR documentation exercise.
Fix the risky spreadsheet and staging database
Sarah’s incident can be turned into a repeatable control pack if the remediation is handled systematically.
| Step | Action | Clarysec evidence outcome |
|---|---|---|
| 1 | Register the staging database and spreadsheet as PII assets | Asset inventory entries with owner, location, classification, PII categories, purpose, and retention |
| 2 | Update the processing activity | Register entry showing data categories, lawful basis, purpose, and retention period |
| 3 | Classify the files and datasets | Confidential or higher classification applied by default until formally reviewed |
| 4 | Remove real PII from non-production | Masked or pseudonymized dataset generated from approved transformation templates |
| 5 | Restrict and review access | Need-to-know permissions, revoked excessive access, access review record |
| 6 | Protect transformation logic and keys | Encrypted, access-controlled, and logged key access |
| 7 | Capture evidence centrally | Asset record, risk entry, access review, deletion proof, masking approval, and ticket closure |
| 8 | Update the SoA and risk treatment plan | Risk scenario linked to 5.34, 5.18, 8.11, 8.15, 8.10, 5.23, and supplier controls |
| 9 | Decide whether a DPIA is required | DPIA or documented rationale for high-risk processing decisions |
| 10 | Record lessons learned | Updated training, secure development rules, export controls, DLP monitoring, and test data guidance |
The Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME states:
“All evidence must be stored in a centralized audit folder.”
From section ‘Policy Implementation Requirements’, policy clause 6.2.1.
The Information Security Policy Information Security Policy makes the broader audit expectation explicit:
“All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.”
From section ‘Policy Implementation Requirements’, policy clause 6.6.1.
Those two clauses are the difference between having a control and being able to prove it.
Cross-compliance mapping for one PII control set
PII protection becomes easier to defend when it is mapped across frameworks before the auditor asks.
| PII protection theme | GDPR relevance | ISO/IEC 27001:2022, ISO/IEC 27701:2025 and ISO/IEC 29151:2022 relevance | NIS2 relevance | DORA relevance | NIST and COBIT 2019 audit lens |
|---|---|---|---|---|---|
| PII inventory and processing register | Accountability, lawful basis, purpose limitation, storage limitation | ISMS context, 5.9 asset inventory, privacy information management, PII protection | Asset management and risk analysis | ICT asset and service dependency awareness | Identify function evidence and governance over information assets |
| Access rights and least privilege | Integrity and confidentiality, access limited by role | 5.15 access control, 5.16 identity management, 5.18 access rights, 8.2 privileged access rights | Access control, HR security, authentication | ICT risk controls and privileged access oversight | Access enforcement, ownership, responsibility, and monitoring |
| Masking and pseudonymization | Data minimization, data protection by design, security of processing | 5.12 classification, 5.34 PII protection, 8.11 data masking, 8.33 test information | Cyber hygiene and secure development | Secure testing, data loss reduction, operational resilience | Technical safeguard testing and reliable control operation |
| Incident classification and reporting | Personal data breach assessment and notification | Incident planning, event assessment, response, evidence collection | 24-hour early warning, 72-hour notification, final report | Major ICT-related incident classification and reporting | Escalation criteria, decision logs, root cause, remediation |
| Supplier and cloud processing | Processor obligations, transfers, contracts | 5.21 ICT supply chain, 5.23 cloud services, 5.31 legal and contractual requirements | Supply-chain security | ICT third-party risk, audit rights, exit and transition | Third-party governance, assurance, and management accountability |
This is where Zenith Controls is especially useful. For 5.34, it maps PII protection to asset inventory, data masking, and cloud governance. For 8.11, it maps masking to classification, privacy protection, and test information. For 5.18, it maps access rights to access control, identity management, and privileged access. These relationships allow a team to explain not just that a control exists, but why it exists and which adjacent controls must operate with it.
How different auditors test the same PII control
A single control, such as 8.11 Data masking, will be examined differently depending on the audit lens.
| Auditor type | Primary focus | Evidence they will expect |
|---|---|---|
| ISO/IEC 27001:2022 and ISO/IEC 27701:2025 auditor | ISMS and PIMS integration, risk treatment, SoA accuracy | Risk assessment, SoA entry, masking policy, change records, internal audit results |
| GDPR or data protection authority reviewer | Data protection by design, minimization, accountability | Processing register, lawful basis, DPIA, pseudonymization evidence, retention logic |
| NIS2 assessor | Secure development, incident prevention, governance | Secure development procedure, developer training, incident remediation evidence, control effectiveness review |
| DORA customer or auditor | ICT operational resilience and third-party risk | Critical application testing evidence, supplier contract clauses, incident support obligations, recovery and exit planning |
| NIST-style or COBIT 2019 reviewer | Control design, operation, ownership, monitoring | Control owner, metrics, evidence repository, management reporting, corrective actions |
An ISO/IEC 27001:2022 auditor starts with management-system logic. Is PII inside scope? Are interested-party requirements identified? Are privacy risks assessed using defined criteria? Are controls selected through risk treatment? Is the SoA accurate? Are internal audits and management reviews covering PII-related controls?
A privacy reviewer starts with accountability. What personal data is processed? What is the lawful basis? Are data subjects informed? Is processing limited to a specific purpose? Are high-risk activities assessed? Are processors governed?
A NIS2-focused assessor starts with governance and cybersecurity risk management. Does management approve and oversee measures? Are incident handling, continuity, supplier security, access control, asset management, secure development, and control effectiveness assessment integrated?
A DORA customer or auditor asks whether ICT risk management is documented, board-governed, proportionate, and supported by contracts. If PII is processed in services supporting financial entities, expect questions about incident assistance, data processing locations, recovery, audit rights, service levels, termination, and exit.
A COBIT 2019 or ISACA-style reviewer tests governance alignment. Who owns PII risk? Which governance body receives reporting? Are responsibilities assigned? Are suppliers monitored? Are deviations tracked? Are metrics used for decision-making? Is residual risk formally accepted?
One evidence model can satisfy all of these lenses, but only if the control system is designed for traceability from the start.
Common audit findings in PII protection programs
Organizations that approach ISO/IEC 27701:2025 or ISO/IEC 29151:2022 readiness without an integrated toolkit often see the same findings.
| Finding | Why it matters | Clarysec remediation |
|---|---|---|
| PII inventory excludes logs, backups, analytics exports, or support attachments | Hidden PII cannot be protected or deleted reliably | Expand Step 9 asset inventory and processing register to include all PII locations |
| Test environments use production data | Real PII is exposed where it is not necessary | Enforce masking policy and approved transformation templates |
| Access reviews are generic and do not focus on PII repositories | Excessive access remains undetected | Map 5.18 access rights to PII asset owners and periodic review evidence |
| Lawful basis is documented but not linked to systems or retention | GDPR accountability cannot be demonstrated | Add lawful basis and retention fields to the processing register and asset inventory |
| Supplier contracts lack data location, incident assistance, audit rights, or exit provisions | DORA, NIS2, and GDPR supplier assurance gaps remain | Align supplier due diligence and contracts with ICT third-party and cloud governance |
| Incident playbooks do not distinguish security incidents from personal data breaches | Reporting deadlines may be missed | Build classification trees for GDPR, NIS2, and DORA reporting triggers |
| Evidence is scattered across tickets, drives, screenshots, and email | Audit readiness fails even where controls operate | Use centralized audit folders and evidence naming standards |
These findings are not paperwork issues. They are operating-model issues. ISO/IEC 27701:2025 and ISO/IEC 29151:2022 will not fix them unless privacy governance, security controls, and evidence management are embedded into normal workflows.
What management should ask before the next audit
Before pursuing ISO/IEC 27701:2025 readiness, ISO/IEC 29151:2022 implementation, or a GDPR, NIS2, or DORA customer assessment, management should ask ten direct questions:
- Do we have a complete register of PII processing activities, including data categories, purpose, lawful basis, and retention?
- Are PII assets flagged in the asset inventory, including logs, backups, exports, analytics tools, and support attachments?
- Are data classifications assigned at creation or onboarding, with unreviewed assets defaulting to Confidential?
- Can we prove access to PII is limited to authorized users with a need-to-know?
- Do development, test, and staging environments use masked or pseudonymized data instead of real personal data?
- Are masking templates approved, keys protected, access-controlled, and logged?
- Does the SoA connect PII risks to controls and regulatory obligations?
- Are cloud and supplier contracts reviewed for data location, security, incident support, audit rights, recovery, and exit?
- Can our incident process classify GDPR personal data breaches, NIS2 significant incidents, and DORA major ICT-related incidents?
- Is evidence stored centrally and retained in a way an auditor can follow?
If the answer to any of these questions is unclear, the organization is not audit-ready yet.
Make PII protection demonstrable
Sarah’s late-night incident could have become a fragmented compliance scramble. Instead, it can become the starting point for a stronger operating model: an ISO/IEC 27001:2022 ISMS extended into privacy through ISO/IEC 27701:2025, reinforced by ISO/IEC 29151:2022 practices, and mapped to GDPR, NIS2, DORA, NIST-style assurance, and COBIT 2019 governance expectations.
That is the real value of audit-ready PII protection. It does not depend on finding the right spreadsheet before the auditor arrives. It depends on a system that already knows where PII is, why it exists, how it is protected, who is accountable, which suppliers are involved, and where evidence lives.
Start with Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to structure your implementation. Use Zenith Controls: The Cross-Compliance Guide Zenith Controls to map PII protection across ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST-style assurance, and COBIT 2019 governance expectations. Operationalize the work with Clarysec policies, including Data Protection and Privacy Policy Data Protection and Privacy Policy, Data Masking and Pseudonymization Policy Data Masking and Pseudonymization Policy, Data Classification and Labeling Policy Data Classification and Labeling Policy, Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME, and Information Security Policy Information Security Policy.
If your next customer audit, GDPR review, NIS2 readiness project, or DORA supplier assessment is approaching, do not wait for a breach to reveal the gaps. Download the Clarysec toolkits, request a demo, or schedule a PII protection assessment and build a privacy program that is not just compliant, but defensible.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
