Permissioned Blockchain with Multiple Nodes: Distinguishing Controllers and Processors

In a permissioned blockchain, the technical label of a node operator does not decide its GDPR role. The decisive questions are who determines the purposes and essential means of the specific processing, who makes those decisions jointly with others, and who processes personal data only on documented instructions.

This article examines a consortium with several authorised nodes. It focuses on blockchain governance, the actual influence of consortium members, the possible processor role of a technical node operator, and the documents needed before production starts. Erasure, rectification, wallets and processing without a DLT connection are separate topics.

In a permissioned blockchain, an authority grants permission to participate. Depending on the design, only selected participants may read, write or create blocks. The authority may be one organisation or a group with a common interest. The rights of participants must therefore be derived from the actual governance rules.

Governance sets technical rules, protocols, access rights, validation procedures and organisational responsibilities. It is central to the role assessment because it shows who prepares, approves and changes decisions. Calling a group a consortium or a node operator does not answer that question.

The EDPB favours permissioned blockchains because they can provide a clearer allocation of responsibilities. This is a design recommendation for a traceable architecture. It does not create a specific GDPR role by itself.

Under Article 4(7) GDPR, a controller is the entity that alone or jointly with others determines the purposes and means of processing. In a consortium, this requires a factual assessment. The relevant point is the decision about the specific processing, not network membership or ownership of a node.

If several businesses jointly decide which personal data enter the blockchain for a common activity, who may use them and which essential rules apply, joint controllership may exist for that activity. Joint use of the infrastructure alone is insufficient. A business may also be a separate controller for a distinct purpose.

Article 26 GDPR requires a transparent arrangement where parties are joint controllers. It must reflect the actual decision structure, the handling of requests and cooperation on data subject rights. An arrangement cannot simply rename the parties without matching their actual influence.

A node is a technical component. For GDPR purposes, the relevant actor is the organisation or person operating or controlling it. An operator that checks and relays transactions under predefined rules and maintains the blockchain state does not become a controller automatically.

If the operator processes personal data on behalf of a controller and on documented instructions, it may be a processor under Article 4(8) GDPR. The actual service must support that instruction-based role. The contract must match the technical reality and must not silently give the operator its own purposes for using the data.

Limited decision-making power is an indication, not a safe harbour. Check whether the operator materially influences data fields, validation rules, access, protocol changes or its own analysis. The stronger its own decisions on purposes or essential means, the more likely a controller or joint controller role becomes.

For a technical service provider, first define the specific processing activity. This may include node operation, monitoring, support, backups, key management and interfaces. The controller must be able to identify which data the provider actually processes and which actions are authorised.

For processing on behalf of a controller, documented instructions, confidentiality, appropriate security measures, assistance with the controller obligations, subprocessors, return or erasure at the end of the service and audit evidence must be addressed under Article 28 GDPR.

If the provider uses data for its own analytics, product or training purposes or independently decides essential means, its processor qualification must be reassessed. The SaaS role assessment helps with the prior distinction. Blockchain governance and the node function still require their own assessment.

Before production, the consortium needs an up-to-date description of the processing. It should connect purposes, data fields, participants, node locations, validation tasks, access, interfaces and other storage locations. If nodes are outside the European Economic Area, transfer questions require a separate assessment. They are not the main topic here.

The role file assigns concrete decisions to each participant. Who approves participants? Who sets data formats and validation rules? Who can change the protocol? Who has administrative access? Who may use data for its own purposes? The answers indicate whether a sole controller, joint controllership or processing on behalf is appropriate.

Articles 5(2) and 24 GDPR require demonstrable responsibility. The EDPB guidance also recommends assessing the need for blockchain, suitable alternatives and technical and organisational measures before implementation. The article on privacy certification in IT contracts adds a perspective on certificates and contract evidence. A certificate does not replace the role file.

A role qualification applies to the specific processing assessed. If the authority changes, new participants are admitted, a node receives broader validation powers or a provider is commissioned for its own analysis, the distribution of influence may change.

Before such a change, compare purposes, data fields, essential means, access, instructions and audit rights again. This also applies to changes in consensus, protocol management and update approval. The technical implementation must then match the documented role allocation.

Depending on the result, an Article 26 arrangement, an Article 28 agreement, internal responsibilities or the technical architecture may need adjustment. Article 5(2) GDPR requires the organisation to demonstrate compliance. A change record with the decision, reasons and control provides a reliable basis.

Every node is treated as a controller automatically: Technical participation alone says nothing about purposes, essential means or own decision-making powers.

Permissioned means processing on behalf automatically: Restricted access can support governance, but it does not replace the assessment of instructions and own purposes.

The consortium is described only in the contract: The actual votes, powers and technical controls remain decisive.

A node operator may perform its own analytics: Own purposes can call the previous Article 28 qualification into question.

Articles 26 and 28 are mixed: Joint decisions on purposes and essential means require a different structure from processing on instructions.

Governance changes are not reassessed: New access, rules and operators can change both the role and the evidence required.

We review the blockchain architecture, governance rules, purposes and essential means, the functions of each node and the technical provider chain together. For an initial assessment, provide the architecture diagram, participant and node list, protocol and access rules, service description, instructions, contracts and change records. This makes it possible to decide whether an Article 26 arrangement, an Article 28 agreement or another responsibility structure matches the actual processing.