Who Is Responsible for Data? And What Changes When We Put It on a Blockchain

Data can be copied, encrypted, delegated, replicated, and verified. Accountability cannot be hashed away.

Every digital product begins with a deceptively simple act: somebody records something about somebody or something else. A customer submits an address. A device reports a temperature. A messenger carries a conversation. A bank settles a payment. A public agency issues a credential.

Then the data starts moving. It passes through applications, vendors, databases, backups, analytics systems, and sometimes a blockchain. Each handoff can make responsibility feel more diffuse. Distributed systems intensify that feeling: if thousands of independent nodes hold the same record, who is actually in charge?

A blockchain can distribute custody. It cannot make accountability disappear.

That distinction matters. Blockchain is powerful precisely because it can reduce dependence on a single operator. But the absence of one central database administrator does not mean the absence of decisions, duties, or consequences. Someone still chooses what enters the system, why it is needed, how long it should remain meaningful, and what happens when it is wrong.

Data never becomes ownerless

People often compress several different questions into “Who owns the data?” Ownership is only one possible legal metaphor, and often not the most useful one. A more practical question is: who has which responsibility at each stage of the data lifecycle?

The person or organization described by the data has interests and rights. The party deciding why and how the data will be used sets the purpose and the rules. Service providers implement storage, transport, security, or analytics on that party’s behalf. Engineers translate policy into schemas, permissions, defaults, logs, and deletion paths. Infrastructure operators keep systems available. Auditors, regulators, and courts provide oversight and redress. Users also make choices about what they submit, but “the user clicked send” is not a universal waiver for poor system design.

European data-protection law makes one version of this structure explicit. Under the GDPR, the controller determines the purposes and means of processing, while a processor acts on the controller’s behalf. The controller must not only comply, but be able to demonstrate compliance. The principles include purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality, and accountability.

This is not merely a European concern. The vocabulary changes across jurisdictions and sectors, but the underlying questions travel well: Was collection necessary? Was the person informed? Is access limited? Can an error be corrected? Can harm be contained? Is there a real party able to answer a complaint?

What a blockchain changes — and what it does not

A conventional application usually gives one operator broad technical control. That operator can edit a row, revoke an account, restore a backup, or delete a record. The same control that enables remediation can also enable censorship, quiet tampering, or a single catastrophic failure.

A blockchain changes the control model. Multiple nodes reproduce an ordered history, validate proposed changes under shared rules, and make unilateral rewriting difficult. NIST describes blockchains more precisely as tamper-evident and tamper-resistant, not magically immutable. The strength comes from replication, cryptography, consensus, incentives, and the cost of rewriting accepted history.

This creates valuable guarantees, but it also creates a new trade-off:

The harder a record is to change without permission, the harder it is to correct when change is legitimate.

Responsibility therefore moves rather than vanishes. Application designers decide what they submit. Protocol developers define valid state transitions. Validators or delegates enforce those rules. Node operators replicate and serve the history. Governance processes decide how software evolves. In a permissionless network these roles may be geographically and institutionally dispersed, yet the initial act of publishing data remains a concrete decision.

France’s data-protection authority, CNIL, reached a similar practical conclusion: in many blockchain projects, the participant who decides to register data can be considered a controller because that participant determines the purpose and means of processing. The exact legal result is context-dependent, especially in decentralized networks, but “the protocol did it” is not a serious accountability model.

The strongest case for writing data on-chain

Blockchain is justified when several conditions converge: multiple parties need a shared state; they do not fully trust one another or one permanent operator; ordering and provenance matter; independent verification is valuable; and the record can legitimately remain durable.

That makes on-chain storage compelling for a narrow but important class of data:

• Consensus-critical state: balances, transfers, ownership changes, and protocol decisions that every validator must evaluate identically.
• Public commitments: a timestamped hash or cryptographic commitment proving that a document or dataset existed in a particular form, without publishing the document itself.
• Status and revocation: compact registries that let anyone verify whether a credential, key, or authorization remains valid.
• Shared audit events: records whose purpose is to be independently observable across organizational boundaries.
• Censorship-resistant communication state: minimal protocol data needed to deliver or order messages without depending on one company’s server.

In each case, permanence is not an accidental side effect. It is part of the product. The record must outlive a vendor, survive a local outage, or remain verifiable by parties who cannot simply ask one database owner for reassurance.

The strongest case against it

Most application data does not meet that test. Raw personal profiles, medical histories, biometric templates, private documents, mutable preferences, customer-support transcripts, location trails, secrets, and large media files are usually poor candidates for permanent replication.

The problem is larger than public visibility. Encrypting a record can protect its contents today, but ciphertext may remain available for decades. Keys can leak. Algorithms age. Metadata can reveal relationships even when content stays unreadable. “Deleting the key” — sometimes called crypto-shredding — can be a useful control, but it is not identical to removing every copy of the underlying data.

Hashes also require care. A hash is not automatically anonymous. If it can be linked back to a person, compared against a small set of possible inputs, or combined with other information, it may function as pseudonymous personal data rather than a harmless abstract fingerprint.

This tension is not theoretical. NIST’s work on privacy-enhancing distributed ledgers begins from the observation that conventional immutability can conflict with privacy and security rules that require revision or deletion. Its researchers have explored redactable ledger structures that retain integrity assurance while allowing controlled erasure. That is a useful reminder: “blockchain” is a design space, not one sacred data structure.

The practical default: prove on-chain, store off-chain

For many products, the strongest architecture is hybrid. Keep the sensitive or mutable record in an encrypted, access-controlled system. Put only the smallest proof, status, or shared protocol state on-chain.

This can take several forms:

• Store a document off-chain and anchor a hash or commitment on-chain.
• Issue a verifiable credential and let the holder disclose only the claims a verifier needs.
• Publish a revocation or status entry without publishing the credential’s private contents.
• Use versioning and supersession so the system can recognize a corrected state without pretending the earlier event never happened.
• Encrypt data with separate, rotatable keys and define a real retention policy for every off-chain copy.

W3C’s Verifiable Credentials model is particularly instructive. It separates the issuer, holder, subject, and verifier, and supports privacy-preserving approaches such as selective disclosure. A person can prove a relevant fact — for example, that a condition is satisfied — without exposing an entire identity record. The point is not to put more identity data on a ledger. It is to make trust portable while sharing less.

Sometimes you do not need a blockchain at all

A responsible analysis must compare blockchain with credible alternatives, not with an imaginary database that has no security or audit controls.

A well-governed database can provide encryption, access control, backups, version history, signed audit events, retention rules, and rapid correction. A transparency log built with Merkle trees can provide inclusion and consistency proofs without distributed consensus; Certificate Transparency, standardized in RFC 9162, is a mature example. A permissioned ledger may help organizations coordinate while preserving clearer governance. A redactable ledger may fit regulated workflows where both integrity and controlled deletion matter.

The decisive question is not “Can we use blockchain?” It is “Which failure are we trying to prevent?” If the primary threat is one operator silently rewriting shared history, decentralized consensus may be the right tool. If the primary need is access control, deletion, confidentiality, or cheap high-volume queries, a conventional system may be better.

A seven-question test before the first transaction

1. What exact claim must be shared or verified? Start with the purpose, not the technology.
2. Who must agree on the state? Name the parties and the trust assumptions between them.
3. Would one accountable operator be acceptable? If yes, a blockchain may add cost without adding meaningful trust.
4. Could the data become wrong, harmful, secret, or legally erasable? If yes, keep the raw record off-chain by default.
5. Can a proof replace the payload? Prefer a commitment, status bit, or selective disclosure over a complete record.
6. Who handles correction, incident response, and redress? “The community” is not a procedure.
7. What happens in ten or twenty years? Model key compromise, cryptographic aging, software forks, and the survival of replicas.

If a project cannot answer these questions in plain language, it is not ready to make data permanent.

ADAMANT: permanence for transport, privacy for content

ADAMANT offers a concrete example of a deliberate trade-off. The network uses a Delegated Proof of Stake blockchain as a decentralized trust layer for communication. Anyone can run a node, and clients do not need to trust one company’s message server to preserve or order the shared transaction history.

But the blockchain is not treated as an excuse to publish plaintext conversations. According to the ADAMANT documentation, message transaction assets are encrypted before they are packed into transactions, signed, and broadcast. Basic chat messages use authenticated public-key encryption based on NaCl box; key-value records can use NaCl secretbox. The client performs the sensitive cryptographic work locally.

The distinction is important. The encrypted message body can remain private while the network still needs some transaction metadata — such as sender, recipient, timestamp, fee, and signature — to validate and route activity. Encryption protects content; it does not make every relationship or event invisible. Honest privacy engineering begins by stating that boundary clearly.

ADAMANT’s architecture shows the legitimate blockchain case: communication should not disappear because one company closes an account, loses a database, or changes policy. At the same time, the system minimizes what public nodes need to understand about the private message itself. That is not “put everything on-chain.” It is use a decentralized ledger only for the trust property the product genuinely needs.

Responsibility is a feature

The next generation of trustworthy products will not win by collecting the most data or by declaring every database immutable. They will win by making responsibility legible.

Users should know what is recorded and what remains private. Developers should be able to explain why each field exists. Operators should know their security and retention duties. Governance should provide a path for correction and incident response. Protocols should make the minimum necessary facts independently verifiable.

Decentralization is strongest when it removes an unnecessary point of control without removing accountability. Privacy is strongest when it is expressed through restraint, not slogans. And blockchain is strongest when it carries the proof — not the whole story.

Primary sources and further reading

• EU General Data Protection Regulation
• CNIL: Blockchain and the GDPR
• NISTIR 8202: Blockchain Technology Overview
• NIST: Privacy-Enhancing Distributed Ledger Technology
• W3C Verifiable Credentials Data Model 2.0
• RFC 9162: Certificate Transparency Version 2.0
• ADAMANT: Encrypting and Decrypting Messages
• ADAMANT: Transaction Types

Who Is Responsible for Data? And What Changes When We Put It on a Blockchain was originally published in ADAMANT on Medium, where people are continuing the conversation by highlighting and responding to this story.