ChecklistDistributed Ledger Technology

Do I need a blockchain? A question-by-question suitability checklist

You probably need a blockchain only when several organizations must write to the same record, none of them is acceptable as the sole operator, and each needs to verify the history independently. If one trusted party could run the system, a conventional database or signed log is cheaper and simpler. Work through the questions below, note the evidence for each answer, and use the scoring section to decide whether to continue, reshape or stop.

Reviewed 10 October 2026 7 min read

On this page

The coordination problem a ledger is supposed to solve
Part one: participants, writers and trust
Part two: independent verification, disclosure and privacy
Part three: what goes on the ledger and what stays off it
Part four: governance, operation and key management
Simpler designs that often meet the same need
Reading your answers: continue, reshape or stop
A hypothetical shipment-event record tested against the checklist
Questions and answers
Sources

The coordination problem a ledger is supposed to solve

Most proposals arrive phrased as a technology choice: put supplier certificates on a blockchain, move the audit trail on-chain. Before answering, restate the proposal as a problem between parties. Who currently keeps the record? Who disagrees with it, or has to reconcile against it? What does that reconciliation cost, and what would happen if one party altered its copy?

NIST's overview of the technology lists features that make a blockchain suitable, among them many and distributed participants, a want or need for no trusted third party, and a need to reduce manual reconciliation and dispute resolution¹. The same section reproduces a decision flowchart from the US Department of Homeland Security Science and Technology Directorate¹. The checklist below turns that thinking into questions you can answer with evidence from your own situation.

Part one: participants, writers and trust

0 of 5 checked

More than one organization needs to write records, not just read themIf only one party writes and others read, a published database or signed feed usually suffices.
The writers do not fully trust one another's copies of the recordLook for real evidence: disputes, audits of each other, duplicate reconciliation teams.
No single party is acceptable as the operator of a shared systemAsk directly whether an industry body, regulator or neutral provider could hold the record. If yes, test that option seriously.
Participants are known and can be identified, or the design deliberately needs open participationThis answer steers you toward a permissioned or a public network later.
Participants will keep joining and leaving over the system's lifeA stable pair of parties can often rely on bilateral signed records instead.

Part two: independent verification, disclosure and privacy

0 of 5 checked

Each party, or an outside auditor, must verify the history without asking the othersIndependent verification is what a ledger provides that a shared spreadsheet does not.
The order and timing of events matters to the outcomeFirst to register, first to claim, or a sequence of custody handovers are typical examples.
You know which fields each participant may seeWrite a visibility matrix by data element and participant before choosing a network.
The records do not need to be deleted or rewritten laterLedgers append; corrections are new entries. Records that must be erased belong off-chain.
Disclosure rules, such as competition law and confidentiality agreements, have been checkedShared records between competitors may need legal review even when only hashes are shared.

Part three: what goes on the ledger and what stays off it

0 of 5 checked

The minimum on-ledger content is definedOften an identifier, a hash of a document, a status and a signature, with the document held elsewhere.
Personal data is kept off the ledger or reduced to non-identifying proofsData protection rights are hard to honor on a record that cannot forget.
There is a way to check that source data was true when recordedSensors, inspectors, signed attestations or audits: the ledger cannot supply this on its own.
Off-ledger storage has its own availability and integrity controlsA hash on a ledger is useless if the document it points to is lost.
Existing systems can produce and consume ledger recordsIdentify which ERP, document or operational systems will write events and act on receipts.

Part four: governance, operation and key management

0 of 5 checked

There is a draft rulebook for joining, leaving, disputes and upgradesWho admits a new participant, who approves a change to the record format, and what happens when parties disagree.
Each participant has a plan for signing keysCustody, rotation, recovery and revocation when an employee leaves or a key is compromised.
Someone is accountable for running each componentNodes or network access, integration services, monitoring and incident response.
Transaction fees or infrastructure costs have an owner and a budgetWho pays for writes, and whether costs scale with volume in a predictable way.
There is an exit planHow records would be exported and verified if the network or a key participant went away.

Simpler designs that often meet the same need

If your answers in parts one and two were mostly no, one of these is likely to fit better.

Alternative	What it provides	Fits when	Falls short when
Shared database run by a trusted operator	One authoritative record with access control	An industry body, regulator or neutral provider is acceptable to everyone	Participants need to verify history without relying on the operator
Digitally signed records exchanged bilaterally	Proof of who said what, held by both parties	Two or a few stable parties exchange documents	Many parties need one consistent ordering of events
Hash-chained or append-only log with published checkpoints	Tamper evidence for one organization's records	One party writes and others or auditors check integrity	Several parties must write as equals
Trusted timestamping or notarization	Evidence that a document existed at a point in time	The question is when, not who agreed	Ongoing multi-party state, such as ownership, has to be tracked
Distributed ledger	A shared, ordered history that each participant verifies	Several writers, no acceptable single operator, independent verification needed	Data must be erased, or one party will control it in practice anyway

For audit trails specifically, the comparison of HCS, timestamping authorities and ledger databases goes deeper.

Reading your answers: continue, reshape or stop

If
Most items in parts one and two are yes, and parts three and four have credible owners.
Then
Continue to network selection and a bounded pilot with real participants.
The core conditions for a ledger are present and the operating gaps are known.
If
Parts one and two are mostly yes, but parts three or four are largely unanswered.
Then
Pause build work and resolve data placement, governance and key custody first.
These gaps are where multi-party ledger projects tend to stall after a technical pilot.
If
Only one organization writes, or a neutral operator would be accepted.
Then
Use a conventional database, signed records or a tamper-evident log.
You get the integrity you need without network governance or fees.
If
The real problem is whether source data is accurate.
Then
Invest in verification at the source, such as inspection, sensors or attestations, before any ledger.
Recording an unverified claim permanently does not make it more reliable.

A hypothetical shipment-event record tested against the checklist

Questions and answers

Do we need a blockchain for a tamper-proof audit trail?

Not usually, if one organization owns the records. A hash-chained log, trusted timestamps or a managed ledger database can give tamper evidence with far less overhead. A public or shared ledger becomes worthwhile when several organizations write to the trail, or when outside parties must verify it without trusting the record keeper.

What does it cost to choose a blockchain when we did not need one?

Mostly complexity that never pays back: network governance meetings, key management for every participant, transaction fees or node operations, slower change cycles and data-protection workarounds. The project also tends to stall when partners realize a central operator would have been acceptable. Running this checklist before procurement is far cheaper than discovering it after a pilot.

How do regulators view distributed ledger projects?

Regulators generally assess the activity rather than the technology. A ledger used for payments, securities, identity or personal data brings the rules for that activity with it, including data protection. Supervisors also expect clear accountability: who operates the system, who answers for errors and how records can be produced for inspection.

Can we start with a database and move to a ledger later?

Yes, and it is often sensible. Design records with stable identifiers, digital signatures from each party and an append-only history from the start. If participants later need independent verification, those records can be anchored to or migrated onto a shared ledger without redesigning the business process.

Sources

NIST IR 8202: Blockchain Technology Overview (Section 8, Application Considerations) — National Institute of Standards and Technology · checked 10 October 2026

Send us your completed checklist and the parties involved

Share your answers, the list of participants and the dispute or reconciliation problem you are trying to fix. We will tell you whether a ledger is justified and, if not, which simpler design fits.

Test our use case

The coordination problem a ledger is supposed to solve

Part one: participants, writers and trust

Part two: independent verification, disclosure and privacy

Part three: what goes on the ledger and what stays off it

Part four: governance, operation and key management

Simpler designs that often meet the same need

Reading your answers: continue, reshape or stop

A hypothetical shipment-event record tested against the checklist

Questions and answers

Sources

Related reading

More in Distributed Ledger Technology

Send us your completed checklist and the parties involved