RoPA Data Flow Mapping for GDPR, NIS2 and DORA

It is 09:10 on a Tuesday and the CISO, DPO, procurement lead and operations director are staring at the same video call, but not the same evidence.

The DPO has a Record of Processing Activities, or RoPA, that lists customer onboarding, employee payroll, support tickets and marketing analytics. The CISO has a cloud asset inventory. Procurement has supplier contracts. Operations has a business continuity spreadsheet. Finance has the DORA Register of Information. Nobody can answer the regulator’s most basic joined-up question:

If this payment onboarding service fails, which systems, suppliers, data categories, sub-processors, cross-border transfers and critical business functions are affected?

That question is the real 2026 compliance test.

GDPR still requires accountable Article 30 records. NIS2 has turned cybersecurity into a management-body accountability issue for essential and important entities. DORA requires financial entities to evidence ICT dependencies, critical or important functions, ICT third-party arrangements, incident classification and resilience testing. ISO/IEC 27001:2022 gives the management-system structure to hold it all together, but only if RoPA and data flow mapping are treated as live governance evidence rather than privacy team spreadsheets.

At Clarysec, we see the same pattern in fast-growing SaaS, fintech, cloud, MSP and B2B technology companies. They have enough documentation to answer a questionnaire, but not enough connected evidence to survive a supervisory review, cyber incident, supplier failure or internal audit. The problem is rarely a lack of information. It is a lack of connection.

The solution is to make RoPA and data flow mapping the common evidence layer for privacy, cyber resilience, supplier management, cloud governance and business continuity.

Why RoPA and Data Flow Mapping Became a 2026 Governance Issue

RoPA used to be viewed as a privacy artifact. Data flow maps were often built during a DPIA, cloud migration or security architecture review, then left to age. That approach no longer works.

GDPR applies broadly to personal data processing in the context of an EU establishment, and also to many non-EU controllers or processors offering goods or services to individuals in the EU, or monitoring their behaviour. Personal data covers information relating to an identified or identifiable person. Processing includes collection, storage, use, disclosure, restriction, erasure and destruction. A controller determines purposes and means, while a processor acts on behalf of a controller.

A RoPA is therefore not just a list of databases. It is a record of business purposes, data categories, roles, recipients, retention periods, safeguards and international dependencies.

NIS2 adds a service-resilience lens. It brings many medium-sized and larger organizations in high-criticality and other critical sectors into scope, including digital infrastructure, cloud computing service providers, data centre service providers, content delivery networks, trust service providers, public electronic communications providers, managed service providers and managed security service providers. Annex I also includes banking and financial market infrastructures. Some entities may be covered regardless of size, including certain DNS, TLD, trust service and public communications providers, and entities whose disruption could significantly affect public safety, public health, systemic risk or critical societal and economic activities.

NIS2 Article 21 requires proportionate technical, operational and organisational measures for network and information systems used for operations or service provision. Its minimum areas include risk analysis, security policies, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management and authentication.

For a NIS2 entity, a RoPA without a service dependency view is incomplete. A significant incident must be understood in terms of service impact, operational disruption, affected recipients, suppliers and cross-border implications.

DORA sharpens the same point for financial entities. It applies from 17 January 2025 and establishes uniform requirements for ICT risk management, major ICT-related incident reporting, digital operational resilience testing, cyber threat and vulnerability information sharing, ICT third-party risk and contractual arrangements with ICT third-party service providers. DORA defines ICT services broadly as digital and data services provided through ICT systems on an ongoing basis. It defines a critical or important function as one whose disruption would materially impair financial performance, service continuity or compliance obligations.

For financial entities also identified under NIS2 national transposition, DORA is treated as the sector-specific Union legal act for equivalent ICT risk, incident reporting, testing, information-sharing and third-party risk requirements. In practice, a fintech cannot build one evidence set for privacy, another for DORA and another for NIS2. It needs a single dependency-aware data governance layer.

That layer is RoPA plus data flow mapping.

ISO/IEC 27001:2022 Is the Backbone

ISO/IEC 27001:2022 is built for this kind of integration. It establishes a scalable information security management system, or ISMS, designed to preserve confidentiality, integrity and availability through risk management. The standard is intended to be integrated into organizational processes and scaled to the organization’s needs, size and structure.

The starting point is not the diagramming tool. It is scope.

ISO/IEC 27001:2022 clauses 4.1 to 4.4 require the organization to define context, interested parties, ISMS scope and interacting processes. The scope must consider legal, regulatory and contractual obligations, plus interfaces and dependencies between internal activities and activities performed by other organizations. For RoPA and data flow mapping, this means your ISMS scope should explicitly capture outsourced cloud platforms, payment processors, identity providers, support tools, managed security providers and business-critical SaaS integrations.

Clauses 5.1 to 5.3 make leadership accountable for policy, resources, role assignment and reporting. This mirrors the direction of NIS2 Article 20, which requires management bodies to approve cybersecurity risk-management measures, oversee implementation and follow training. It also aligns with DORA Article 5, which gives the management body ultimate responsibility for ICT risk and oversight of policies, resilience strategy, continuity plans, audit plans, ICT third-party services and major incident reporting channels.

Clauses 6.1.1 to 6.1.3 provide the planning engine: identify risks to confidentiality, integrity and availability, assign risk owners, analyse consequences and likelihood, select treatment options, compare controls with Annex A, produce the Statement of Applicability and obtain risk-owner approval.

This is where RoPA becomes operational. Each processing activity and data flow should connect to risks, controls, suppliers, assets and critical services. If it does not, it will remain a privacy inventory that cannot support incident response, resilience testing or supplier risk decisions.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap makes this practical in the Risk Management phase, Step 9, Identifying Assets, Threats, and Vulnerabilities:

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).”

The same Step 9 adds the key compliance insight: personal data assets should be flagged for GDPR relevance, and critical service assets should be noted for potential NIS2 applicability if the organization is in a regulated sector. That is the bridge between RoPA, asset inventory and critical service dependency mapping.

What an Audit-Ready RoPA Must Contain

A strong RoPA does not need to be complicated, but it must be connected.

GDPR Article 5 requires personal data to be processed lawfully, fairly and transparently, collected for specified and legitimate purposes, limited to what is necessary, kept accurate, retained only as long as needed and secured through appropriate technical and organisational measures. Article 5(2) requires the controller to be responsible for, and able to demonstrate, compliance.

Article 6 requires a lawful basis, such as consent, contract necessity, legal obligation, vital interests, public task or legitimate interests. If processing is for a new purpose, compatibility must be assessed by considering the original and new purposes, collection context, sensitivity, consequences for individuals and safeguards such as encryption or pseudonymisation. Article 9 adds stricter rules for special categories of personal data, including health data, biometric data used for unique identification and other sensitive categories.

Clarysec’s SME policy set turns this into an operational requirement. The 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

That is from the Governance Requirements section, clause 5.2.1. For larger organizations, Clarysec’s Data Protection and Privacy Policy assigns the responsibility directly:

Maintains the Record of Processing Activities (RoPA) in accordance with GDPR Article 30.

That wording comes from Roles and Responsibilities, clause 4.2.2. The practical message is simple: RoPA ownership must be assigned. It cannot be an orphaned compliance spreadsheet.

A 2026-ready RoPA should include the following fields.

The final rows are what move RoPA from privacy documentation into cyber-resilience evidence. Without systems, suppliers, locations, criticality and controls, a RoPA may satisfy a narrow Article 30 checklist but fail as soon as an incident, outage or supervisory review demands impact analysis.

Data Flow Mapping Connects Privacy, Cloud and Critical Services

If RoPA answers “what processing exists and why,” a data flow map answers “where the data moves, who touches it, what protects it and what breaks if it stops.”

Clarysec’s Data Masking and Pseudonymization Policy - SME makes the requirement unambiguous:

A data flow map must be created.

This comes from Governance Requirements, clause 5.1.1.1. The enterprise version, Data Masking and Pseudonymization Policy, expands the expectation in clause 5.2.1:

Maintain an up-to-date inventory of systems and data flows involving sensitive data.

Clause 5.2.2 adds:

Map where and how data is transformed, shared, or accessed across environments.

Auditors and regulators are not looking for artistic diagrams. They want to understand transformations, access paths, sharing, environments and safeguards.

In the Zenith Blueprint, Controls in Action phase, Step 22, Organizational controls 5.1 to 5.18, the information transfer guidance explains that organizations must define permitted transfer methods, align them with classification and ensure parties understand their roles and obligations. It gives examples such as encrypted email, secure portals, SFTP, APIs and physical delivery with encryption. It also notes that personal data transferred across borders must comply with privacy and legal obligations, not just internal preferences.

The same step connects information transfer to classification and labelling, data leakage prevention, supplier relationships and cryptography. That creates a practical model for data flow mapping:

1. Identify the source system, such as CRM, payment platform, HRIS or support desk.
2. Identify the data category, including personal data, financial data, employee data, special category data or credentials.
3. Identify the transfer method, such as API, SFTP, email, secure portal, manual export or backup replication.
4. Identify the destination, including internal system, cloud service, supplier, sub-processor, data warehouse or archive.
5. Identify the protection, such as encryption, pseudonymisation, access control, logging, DLP or contractual restriction.
6. Identify the dependency, including whether the flow supports a critical business function, critical or important function, essential service or incident reporting obligation.

Three ISO/IEC 27001:2022 Annex A controls are especially important here. ISO/IEC 27002:2022 provides the implementation guidance for these controls:

Clarysec’s Zenith Controls: The Cross-Compliance Guide identifies 5.9, 5.14 and 5.34 as topic-related controls for this governance layer. Treat them as anchor controls, then connect them to supplier, cloud, incident, continuity, logging, access and cryptography controls through your Statement of Applicability.

Why NIS2 and DORA Need More Than a Privacy Register

A common mistake is to build a RoPA that is technically correct under GDPR but useless for NIS2 or DORA. The difference is service criticality.

NIS2 Article 23 requires essential and important entities to notify significant incidents without undue delay. Its reporting model includes an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Significant incidents are assessed by severe operational disruption, financial loss, or material or non-material damage to other natural or legal persons. That assessment depends on knowing which services, recipients, countries, systems and suppliers are affected.

DORA Article 17 requires financial entities to define and implement an ICT-related incident management process that detects, manages and notifies incidents, records incidents and significant cyber threats, identifies root causes, sets early warning indicators, classifies incidents by severity and criticality of affected services, assigns roles and creates communication and escalation procedures. Article 18 requires classification using affected clients or counterparts and transactions, duration and downtime, geographic spread, data loss affecting availability, authenticity, integrity or confidentiality, criticality of affected services and economic impact.

You cannot classify an incident quickly if you do not know the data flow and dependency chain.

Clarysec’s Business Continuity Policy and Disaster Recovery Policy - SME points to the evidence field organizations need:

prioritized services and systems (critical business functions)

This comes from Governance Requirements, clause 5.2.1.2. The enterprise Business Continuity Policy and Disaster Recovery Policy adds the dependency dimension in clause 5.2.4:

Critical dependencies (systems, suppliers, personnel)

For DORA-regulated organizations, this must align with critical or important functions, ICT services, contractual arrangements and exit strategies. DORA Article 28 requires ICT third-party risk to be managed as part of the ICT risk framework. It mandates a register of ICT service contractual arrangements, requires pre-contract due diligence and assessment of criticality, concentration risk, suitability and conflicts of interest, and requires exit strategies for ICT services supporting critical or important functions.

DORA Article 30 specifies minimum ICT contract terms, including service descriptions, subcontracting conditions, data processing and storage locations, data protection, access, recovery and return of data, service levels, incident assistance, cooperation with authorities, termination rights, audit rights and transition or exit arrangements.

A RoPA that does not identify suppliers, locations, transfer methods, criticality and exit dependencies will not support DORA evidence.

Supplier, Cloud and Sub-Processor Mapping Is Where Evidence Often Breaks

In real audits, RoPA failures often appear as supplier failures. The processing activity says “customer support.” The data flow map says “support platform.” But nobody can identify the hosting region, AI transcription add-on, analytics sub-processor, ticket attachment retention, admin access model or exit procedure.

Clarysec’s SME supplier policy creates the minimum operating evidence. The Third-Party and Supplier Security Policy - SME states:

A Supplier Register must be maintained and updated by the administrative or procurement contact. It must include:

This comes from Governance Requirements, clause 5.4. The cloud policy adds a separate inventory requirement. The Cloud Usage Policy - SME states:

A Cloud Service Register must be maintained by the IT provider or GM. It must record:

This comes from Governance Requirements, clause 5.3. For enterprise dependency risk, Clarysec’s Supplier Dependency Risk Management Policy is more explicit:

Supplier Dependency Register: The VMO shall maintain an up-to-date register of all critical suppliers, including details such as services/products provided; whether the supplier is sole-source; available alternate suppliers or substitutability; current contract terms; and an assessment of the impact if the supplier were to fail or be compromised. The register shall clearly identify high-dependency suppliers (e.g., those for which no rapid alternative exists).

That requirement, from Implementation Requirements clause 6.1, is exactly what connects RoPA to NIS2 supply chain security and DORA ICT third-party risk.

The Zenith Blueprint, Controls in Action phase, Step 23, Organizational controls 5.19 to 5.37, recommends compiling a full supplier list, classifying suppliers based on access to systems, data or operational control, embedding security expectations in contracts, reviewing subcontractors, establishing supplier change triggers and building a cloud service evaluation process covering data location, access model, logging and encryption.

That is what allows a CISO to answer, during an incident: “Which critical service uses this supplier, which data was exposed, which customers must be notified, which regulator may need a report and what alternate supplier or exit path exists?”

A Practical Example: Customer Onboarding in a Fintech

Consider a fintech that provides digital wallet onboarding. Customers upload identity documents, biometric liveness checks are performed by a vendor, results are stored in a cloud database, and customer support can view verification status in a ticketing tool.

The onboarding service may be a critical or important function under DORA because disruption materially affects service continuity and regulatory obligations. If the company is in a NIS2 sector or provides relevant ICT services, it may also be part of critical service evidence.

A useful map starts with one joined record.

Now add ISO/IEC 27001:2022 risk treatment traceability.

In the Zenith Blueprint, Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability, Clarysec describes the SoA as a bridging document linking risk assessment and treatment to actual controls. It recommends mapping controls to risks and cross-referencing regulations such as GDPR, NIS2 or DORA in the Risk Register or SoA notes where relevant.

For the onboarding example, the risk scenario might be: “Identity verification provider outage or compromise disrupts onboarding and exposes biometric identity data.” The treatment controls could include supplier due diligence, contractual incident notification, encryption, access control, logging, backup and recovery, data minimisation, pseudonymisation, monitoring, exit planning and incident response playbooks.

The SoA note can state that the control set supports GDPR accountability, NIS2 Article 21 supply chain and incident readiness, and DORA ICT third-party risk and critical function resilience.

That is what auditors want: traceability.

Cross-Compliance Mapping: One Evidence Layer, Multiple Questions

RoPA and data flow mapping are not separate compliance silos. They support a common set of questions across GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 and COBIT 2019.

NIST CSF 2.0 is useful as an organizing layer. Its CSF Profiles support current-state and target-state analysis using inputs such as policies, risk priorities, business impact registers, requirements, standards, practices, tools and work roles. Its GOVERN function includes legal, regulatory, contractual, privacy and civil liberties obligations, risk objectives, leadership accountability, roles, policy, oversight and performance review. Its supply chain outcomes require suppliers to be known and prioritized by criticality, contractual cybersecurity requirements to be integrated, due diligence to occur before relationships, supplier risks to be recorded and monitored, and suppliers to be included in incident response and recovery planning.

That maps neatly to a Clarysec RoPA operating model. The RoPA gives privacy context. The asset inventory gives technical context. The supplier and cloud registers give third-party context. The BIA gives criticality context. The SoA gives control context.

A single ISO/IEC 27001:2022 Annex A control can also support several frameworks. Control 5.14, Information transfer, is a good example.

This is the value of Zenith Controls as a cross-compliance compass. It helps organizations explain why one control practice supports multiple regulatory and audit expectations.

How Different Auditors Will Test the Same Map

A mature RoPA and data flow map can satisfy multiple auditors, but each will approach it differently.

An ISO/IEC 27001:2022 auditor will start with scope, interested parties, risks, documented information and control selection. They will ask whether legal and contractual requirements were identified, whether personal data and critical services are inside the ISMS scope, whether assets have owners and classifications, whether the risk assessment considered confidentiality, integrity and availability, and whether the SoA justifies applicable controls.

A GDPR auditor or privacy regulator will start with accountability. They will test whether the RoPA reflects real processing, whether purposes and lawful bases are documented, whether special category data is identified, whether retention periods are applied, whether recipients and processors are accurate, and whether appropriate safeguards exist for transfers and security.

A NIS2-focused auditor will look at service impact. They will ask how the organization determines critical or important services, how management approved and oversees the risk measures, how supplier vulnerabilities and service-provider risks are considered, how continuity and incident handling are connected, and whether the organization can support 24-hour, 72-hour and final reporting timelines with reliable evidence.

A DORA auditor will look at ICT risk governance and critical or important functions. They will test whether the management body has approved the ICT risk framework and resilience strategy, whether ICT third-party arrangements are registered, whether criticality and concentration risk are assessed, whether contracts include required terms, whether testing covers systems supporting critical or important functions, and whether incidents are classified using affected clients, transactions, downtime, geography, data loss, service criticality and economic impact.

A NIST CSF 2.0 assessor will often use profiles. They will compare current and target outcomes across GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER. RoPA and data flow maps become inputs into legal obligation management, asset inventories, supplier risk, data protection, monitoring, incident communications and recovery planning.

A COBIT 2019 or ISACA-style auditor will focus on governance, ownership and process capability. They will test whether information flows are owned, whether decision rights are clear, whether risk appetite is applied, whether controls are monitored, whether exceptions are escalated, and whether evidence is reliable enough for management assurance.

Common Failure Patterns

The most frequent RoPA and data flow mapping failures are predictable.

First, the RoPA lists processing activities but not systems. That makes it impossible to connect GDPR accountability with vulnerability management, access review, backup, logging or incident response.

Second, data flow maps stop at the first supplier. They do not show sub-processors, cloud regions, support access, analytics tools, monitoring platforms or backup locations.

Third, business continuity plans identify systems but not personal data. During an outage, the organization understands recovery priority but not privacy impact.

Fourth, supplier registers capture contract owners but not criticality, substitutability, data categories, incident notification obligations or exit options.

Fifth, the SoA is written as a certification document rather than a control bridge. It says controls are applicable, but it does not explain which GDPR, NIS2 or DORA evidence problem the control helps solve.

Finally, ownership is fragmented. The DPO owns RoPA, IT owns assets, procurement owns suppliers, operations owns BIA, finance owns DORA registers and nobody owns the integrated dependency map.

Clarysec’s approach fixes this by assigning evidence objects to policy owners, then using the Zenith Blueprint steps to connect assets, risks, controls and SoA traceability.

A 30-Day Implementation Plan

You do not need to boil the ocean. Start with the services that matter most.

Week 1: Select three critical or high-risk processing activities. Good candidates are customer onboarding, payment processing, employee HR administration, support ticketing or security monitoring. For each, validate the RoPA entry against actual systems, data categories, purposes, lawful bases and retention rules.

Week 2: Build data flow maps for those activities. Identify source, destination, transfer method, environment, supplier, sub-processor, data location, access path, transformation and retention point. Use the Clarysec Data Masking and Pseudonymization Policy requirement to maintain inventories of systems and data flows involving sensitive data.

Week 3: Link each flow to assets, suppliers, cloud services and critical business functions. Use Zenith Blueprint Step 9 for asset ownership and classification. Use the supplier and cloud register policy requirements to capture third-party evidence. Use the business continuity policy to identify prioritized services and critical dependencies.

Week 4: Add risk and control traceability. For each flow, create or update risk scenarios. Map controls in the SoA using Zenith Blueprint Step 13. Add notes for GDPR Article 30 accountability, NIS2 Article 21 risk measures and DORA ICT dependency evidence where applicable.

Then run one tabletop exercise: “Supplier outage plus data exposure in a critical service.” Test whether your evidence supports incident classification, notification decisions, customer communication, regulator communication and recovery prioritisation.

By the end of 30 days, you will have a repeatable model for the rest of the organization.

The Clarysec Way: Turn RoPA Into Living Resilience Evidence

RoPA and data flow mapping are no longer just privacy administration. They are the connective tissue between GDPR accountability, NIS2 critical service governance and DORA ICT dependency evidence.

The organizations that will perform best in 2026 will not be the ones with the most documents. They will be the ones that can trace a business service to its processing activities, data flows, systems, suppliers, cloud regions, contracts, controls, risks, incident thresholds and recovery plans.

Clarysec helps teams build that traceability without unnecessary bureaucracy. Our policy suite assigns ownership and evidence requirements. The Zenith Blueprint provides the implementation roadmap, including asset identification, supplier and cloud control implementation, and SoA traceability. Zenith Controls provides the cross-compliance compass for mapping ISO/IEC 27001:2022 Annex A controls to privacy, resilience, supplier, cloud and audit expectations.

Your next step is simple: pick one critical service, one RoPA entry and one supplier-supported data flow. Map it end to end. If you cannot explain the data, dependency, control and incident impact in one page, your evidence layer is not ready for 2026.

Clarysec can help you get it ready. Explore the Zenith Blueprint, strengthen your governance with the Data Protection and Privacy Policy and Supplier Dependency Risk Management Policy, and use Zenith Controls to turn fragmented compliance evidence into one audit-ready operating model.