vaayaa Inclusive Education
Technical risk assessment

Blockchain, Web3 and Emerging Digital Technologies Risk Assessment: Keys, Contracts, Privacy and Recovery Controls

A worked example of how a small team building blockchain and Web3 services finds, scores and controls risks to keys, smart contracts, personal data, third parties, uptime and incident response.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: High to Medium
See the Blockchain, Web3 and Emerging Digital Technologies course

Executive summary

This assessment shows how a small team building a blockchain and Web3 service can find, rate and control the risks that matter most to funds, data and availability. Eight risks were chosen because they are plausible in everyday engineering and operations. Key compromise and smart contract flaws carry the highest inherent scores, because a single failure can drain value quickly and may be hard to reverse. Privacy duties on immutable ledgers and phishing of privileged users follow closely. Each risk is scored before controls and again after existing and added controls. Most fall to Medium or Low once the additional controls are in place, but key compromise and contract flaws stay at Medium because the impact remains serious. The first actions are multisignature approval for large transfers, an independent contract review, phishing resistant sign in for administrators and a removal of personal data from the public ledger. The service is a teaching example, so every score illustrates method, not a real organization.

Focus area
Blockchain, Web3 and emerging digital technologies
Setting
Team building and operating a blockchain-based application, wallet service and supporting web platform
Method
Five by five likelihood and impact risk register with inherent and residual scoring

Scope

This assessment covers a small team that designs, deploys and operates a blockchain-based application with a Web3 front end, hosted nodes, signing keys, smart contracts and a support process. It looks at risks to funds, data, service availability, legal duties and public trust. It does not cover investment advice, token valuation or any real product. The chain type, jurisdiction, user base and hosting provider are assumptions made for teaching.

Context

The team has two developers, a security lead, an infrastructure engineer and a product manager. Smart contracts are written in a common language, tested on a test network and then deployed to a public network. Users connect with browser wallets, and the service runs its own nodes in a managed cloud environment. Customer records sit in a conventional database alongside on-chain references. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls that should be added.

Objectives, assets and stakeholders

The objective is to run a reliable blockchain service that protects user funds and personal data, keeps the application available, meets its legal duties and maintains public trust. The assets in scope are signing keys, treasury balances, smart contracts, node infrastructure, the customer database, source code and the reputation of the team. Stakeholders include users, the development and operations teams, the security lead, the data protection lead, hosting and node providers, the software library community and any regulator with an interest in the service. Clear ownership matters: every risk has one owner role, and the product manager reviews the register with the security lead each quarter.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 3, score 12, high: H03 H04 Likelihood 4, impact 4, score 16, high: H01
3 Possible Likelihood 3, impact 3, score 9, medium: H07 Likelihood 3, impact 4, score 12, high: H05 H08 Likelihood 3, impact 5, score 15, high: H02 H06
2 Unlikely
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible
2 Unlikely Likelihood 2, impact 2, score 4, low: H07 Likelihood 2, impact 3, score 6, medium: H03 H04 H05 H08 Likelihood 2, impact 4, score 8, medium: H01 H02 H06
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Compromise of signing keys and wallet credentials 16 High 8 Medium Security lead
H02 Smart contract logic flaws and unsafe upgrades 15 High 8 Medium Lead developer
H03 Misconfigured nodes and exposed cloud infrastructure 12 High 6 Medium Infrastructure engineer
H04 Phishing and misuse of privileged access by insiders 12 High 6 Medium Information security manager
H05 Third-party dependency and supply chain compromise 12 High 6 Medium Vendor manager
H06 Personal data exposure and privacy duties on immutable ledgers 15 High 8 Medium Data protection lead
H07 Service disruption and failed recovery 9 Medium 4 Low Site reliability lead
H08 Incomplete logging and slow incident response 12 High 6 Medium Incident response coordinator
H01

Compromise of signing keys and wallet credentials

Technology and data Before 16 After 8

Private keys or seed phrases are copied, phished or stored insecurely, allowing an attacker or insider to sign transfers and empty treasury or user-linked wallets.

Who or what is affected: Users, treasury holders and the operations team

Causes

Keys stored on laptops, shared seed phrases and no approval step for large transfers.

Consequences

Direct loss of funds, emergency migration costs and loss of user trust.

Existing controls

  • Treasury keys are held in a hardware wallet kept in a locked location.
  • Developers use a password manager and are told never to paste keys into chat tools.

Control gaps

No documented key ceremony exists, and backup phrase locations are known to too few people.

Additional controls

  • Prevent: Require multisignature approval for any transfer above an agreed value.
  • Detect: Alert on any transaction from managed addresses outside approved change windows.
Likelihood 4 x impact 4 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: A signing request for a managed address that does not match an approved change ticket.
H02

Smart contract logic flaws and unsafe upgrades

Technology and data Before 15 After 8

Contract code contains reentrancy, arithmetic or access control errors, or an upgrade changes behavior without review, so attackers or ordinary users can drain balances or lock assets.

Who or what is affected: Users with balances, developers and the business

Causes

Complex logic, time pressure before launch and limited test coverage of edge cases.

Consequences

Loss of user funds, emergency pause, compensation claims and reputational harm.

Existing controls

  • Code is reviewed by a second developer before merge.
  • An automated test suite runs on every change to the contracts.

Control gaps

Test coverage is not measured, and upgrade approval rests on one reviewer.

Additional controls

  • Prevent: Commission an independent security review before mainnet deployment and after each upgrade.
  • Respond: Keep a tested pause mechanism with a named operator and a written activation rule.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Lead developer Target: Within 60 days Early warning: Unreviewed contract changes or test coverage falling below the agreed level.
H03

Misconfigured nodes and exposed cloud infrastructure

Technology and data Before 12 After 6

Node, database or admin interfaces are left open to the internet, default settings remain in place, or old services are not removed, which exposes systems to scanning and intrusion.

Who or what is affected: Operations team, users and hosted data

Causes

Rushed deployments, manual changes and test systems left running in production accounts.

Consequences

Data leakage, malicious node takeover and outages.

Existing controls

  • Network rules limit inbound traffic to the public API ports.
  • Servers are built from a managed image with standard settings.

Control gaps

Configuration drift is checked only when a release is made, not between releases.

Additional controls

  • Prevent: Apply a hardened baseline and close all unused network ports and default accounts.
  • Detect: Scan external exposure weekly and report any drift from the approved configuration.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Infrastructure engineer Target: Within 30 days Early warning: An open administrative port or a service found by an external scan that is not on the approved list.
H04

Phishing and misuse of privileged access by insiders

People Before 12 After 6

Staff are tricked into approving fake wallet prompts or sharing login details, or a trusted person uses administrative access for personal gain or to copy customer data.

Who or what is affected: Staff, users and the company

Causes

Convincing fake prompts, shared admin accounts and weak separation of duties.

Consequences

Stolen credentials, unauthorized transfers, data exposure and disciplinary action.

Existing controls

  • Staff complete security awareness training when they join.
  • Administrative accounts are separate from everyday accounts.

Control gaps

Admin activity is reviewed only after an incident, and shared accounts still exist for some tools.

Additional controls

  • Prevent: Require phishing resistant multi-factor sign in for every administrator and signing role.
  • Detect: Review privileged access logs each month and compare them with approved duties.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Information security manager Target: Within 30 days Early warning: Repeated failed sign in attempts followed by a successful sign in on an administrator account.
H05

Third-party dependency and supply chain compromise

Supplier Before 12 After 6

A software library, node provider, oracle or hosting service is compromised, changes terms or fails, passing faulty code or data into the application.

Who or what is affected: Users, developers and service partners

Causes

Many open source dependencies, reliance on one node provider and oracle feeds that are not checked.

Consequences

Malicious code in the release, data errors, service loss and contract disputes.

Existing controls

  • A vendor list records each supplier and the service it provides.
  • Contracts include uptime commitments and notice periods for changes.

Control gaps

Dependencies are updated automatically, and the switch procedure has never been rehearsed.

Additional controls

  • Prevent: Pin dependency versions and verify package signatures before each release.
  • Respond: Maintain a tested alternative node or data provider and a written switch procedure.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Vendor manager Target: Within 60 days Early warning: A dependency update that changes its signing key or a supplier notice of service change.
H06

Personal data exposure and privacy duties on immutable ledgers

Legal and compliance Before 15 After 8

Personal details are written to a public ledger that cannot be edited, or retained longer than needed, so the service may breach privacy duties and cannot honor deletion requests.

Who or what is affected: Customers, support staff and the company

Causes

Design choices that treat the ledger as a storage system and unclear retention rules.

Consequences

Regulatory action, fines, forced redesign and loss of customer confidence.

Existing controls

  • A privacy notice describes what data is collected and why.
  • A data protection review is completed before each new feature goes live.

Control gaps

Retention periods are not written down, and on-chain fields have not been audited for personal data.

Additional controls

  • Prevent: Keep personal data off the public ledger and store only hashes or references with separate deletion controls.
  • Respond: Write a procedure for access and deletion requests, with specialist review of the legal position.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Data protection lead Target: Within 60 days Early warning: A new on-chain field that contains a name, contact detail or identifier without a documented reason.
H07

Service disruption and failed recovery

Operational Before 9 After 4

A node, network or hosting outage stops the application, and backups or failover steps do not work when needed, so users cannot transact or view balances.

Who or what is affected: Users, operators and business partners

Causes

Single points of failure, untested backups and reliance on manual steps.

Consequences

Lost sales, support costs, missed transactions and reputational damage.

Existing controls

  • Monitoring alerts on node health and API response times.
  • Node data is backed up every day to a separate location.

Control gaps

Restore tests have not been run since the last platform change.

Additional controls

  • Recover: Test restoring a node from backup each quarter and record the time taken.
  • Detect: Alert when block production or confirmation delays exceed the agreed threshold.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Site reliability lead Target: Within 90 days Early warning: Block or confirmation delay that exceeds the agreed threshold for two consecutive checks.
H08

Incomplete logging and slow incident response

Operational Before 12 After 6

Logs from contracts, nodes and admin consoles are missing or kept too briefly, and no rehearsed plan exists, so an incident is found late and its scope cannot be proven.

Who or what is affected: Incident team, users and regulators

Causes

Logs spread across tools, short retention and no agreed severity levels.

Consequences

Longer exposure, weak evidence, slower notices to affected people and higher cost.

Existing controls

  • System logs are kept for a fixed period on each server.
  • An on-call rota covers the main working hours.

Control gaps

No single timeline exists for an incident, and log retention has not been set against legal needs.

Additional controls

  • Detect: Centralize logs from keys, contracts and admin consoles with alerts on unusual events.
  • Respond: Run a tabletop incident exercise every six months and update the playbook afterward.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Incident response coordinator Target: Within 60 days Early warning: A critical log source that stops sending data for more than a set period.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Severe. Multiplying the two gives a score from 1 to 25, which falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. The score is a guide for ordering work, not a measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and added controls. Impact is judged on loss of funds, data exposure, service downtime, legal consequences and harm to trust, and a risk is never rated down only because it has not yet happened. Anything still High needs senior attention and a dated plan, anything Medium needs routine controls with a named owner, and anything Low is accepted and watched. Engineers who do the work should challenge the ratings, and each rating is reviewed whenever a warning indicator reaches its threshold or a major change is made to the system.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Transactions from managed addresses that do not match an approved change ticket.Escalate to the security lead at once, and pause the affected signing key until the transaction is confirmed.
Test coverage of smart contracts and the number of unreviewed contract changes.Escalate to the lead developer when coverage drops below the agreed level, and hold any deployment until review is complete.
Open administrative ports or services found by external scans.Escalate to the infrastructure engineer within one working day, and to the security lead if still open after three days.
Personal data fields added to on-chain records without a documented reason.Escalate to the data protection lead before the next release, and stop the release if the data is not justified.
Block or confirmation delays that exceed the agreed threshold for two consecutive checks.Escalate to the site reliability lead at once, and to the incident response coordinator if service is not restored within the agreed time.

Contingency arrangements

If a serious event occurs, such as a key compromise, a confirmed contract exploit or a data exposure, the security lead pauses affected functions using the tested mechanism and secures remaining keys. The infrastructure engineer isolates affected systems and restores services from the latest verified backup. The data protection lead assesses duties on personal data and arranges specialist legal advice before any notice is sent. Users are told what happened, what is known and what they should do, early and in plain language.

Prioritized action plan

  1. Introduce multisignature approval and a documented key ceremony for all treasury and admin keys, owner security lead, within 30 days.
  2. Require phishing resistant multi-factor sign in for every administrator and signing role, owner information security manager, within 30 days.
  3. Remove personal data from on-chain fields and document retention periods, owner data protection lead, within 60 days.
  4. Commission an independent contract review and confirm the pause procedure, owner lead developer, within 60 days.
  5. Run a restore test and a tabletop incident exercise, owner site reliability lead, within 90 days.

Conclusion

Reliable blockchain services depend on steady habits: controlled key handling, independent review of contracts, privacy by design for any ledger data, tested backups and rehearsed responses. The highest scores sit with key compromise and contract flaws, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle, and seek qualified security, legal and financial advice for any real deployment.

Assumptions and limitations

Assumptions

  • The application runs on a public ledger that anyone can read, and the chain type and jurisdiction are not specified.
  • The team uses managed cloud hosting and third-party node and library providers under written contracts.
  • Staff are software engineers and operators with basic security training, and users sign in with browser wallets.

Limitations

  • The scores are examples for learning and do not describe any real product, network or organization.
  • Smart contract security, privacy and financial rules change quickly and differ by country, so specialist review is needed.
  • This is educational content and is not legal, financial, security or professional advice, and it does not replace a formal site-specific assessment.

Related frameworks to study

  • Hierarchy of controls
  • Three lines model of risk ownership
  • Threat modeling using a structured method such as STRIDE
  • Information security management principles of confidentiality, integrity and availability

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

Blockchain, Web3 and Emerging Digital Technologies course Read the best practices for this course

More Technical risk assessments

Hourly Active: 40,745 Learners