vaayaa Inclusive Education
Technical risk assessment

Electronics, Semiconductor and Embedded Hardware Design Risk Assessment: Briefs, Testing, Production and Data Controls

A worked example of how an electronics and embedded hardware team finds, scores and controls the risks that threaten a design, from unclear briefs and weak testing to production defects, data exposure and schedule pressure.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Electronics, Semiconductor and Embedded Hardware Design course

Executive summary

This assessment shows how a hardware and embedded design team can find, rate and control the risks that matter most to a working product. Eight risks were chosen because they are plausible in everyday design, verification, production and supply work. Unclear briefs, weak testing and a safety-relevant firmware fault carry the highest inherent scores, while intellectual property and confidential data carry serious consequences even when less likely. Each risk is scored before controls and again after existing and added controls. Most fall to Medium or Low once added controls are in place, but the safety risk stays Medium because its impact remains serious. The first actions are a frozen requirements baseline, a fault injection test plan, a rule that locks approved parts and access control on design files. The product is a teaching example, so every score illustrates method, not a real organization.

Focus area
Electronics, semiconductor and embedded hardware design
Setting
Product development team designing printed circuit boards, custom interface logic and embedded firmware for a small to mid-sized electronics product
Method
Five by five likelihood and impact risk register

Scope

This assessment covers a design team developing an embedded electronic product, from requirements and schematic capture through layout, prototyping, verification, production release and supplier handover. It looks at risks to design correctness, safety, intellectual property, confidential data, schedule and customer trust. It does not assess any real product, fabrication process or regulated certification. Jurisdiction, product class, volumes and tooling are assumptions made for teaching.

Context

The team has hardware engineers, firmware engineers, a verification engineer, a product manager and a quality engineer. A contract manufacturer builds boards from a bill of materials supplied by the design team, and components come from several distributors. Design files, firmware and test records are kept in a shared version-controlled repository, and prototypes are tested on bench rigs. Each risk is scored before controls to show its natural level, then again after the existing controls and the controls that should be added.

Objectives, assets and stakeholders

The objective is to deliver a working, safe and accessible embedded product on time and within budget, protect design data and intellectual property, and keep the trust of customers, manufacturers and users. Assets in scope are schematics, layouts, firmware, test records, prototypes, the bill of materials, the repository and the reputation of the design team. Stakeholders include the engineers, the product manager, verification staff, the contract manufacturer, component distributors, licensors, customers, end users including people with disabilities, and the legal and safety reviewers. Every risk has one owner role, and the product manager reports the register to leadership at each design gate.

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: H08 Likelihood 4, impact 4, score 16, high: H01 H02 Likelihood 4, impact 5, score 20, critical: H04
3 Possible Likelihood 3, impact 3, score 9, medium: H07 Likelihood 3, impact 4, score 12, high: H03 H05 Likelihood 3, impact 5, score 15, high: 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: H05 H07 Likelihood 2, impact 3, score 6, medium: H01 H02 H03 H06 H08 Likelihood 2, impact 4, score 8, medium: H04
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 Unclear brief and scope creep 16 High 6 Medium Product manager
H02 Late defects from weak testing and corrective iteration 16 High 6 Medium Verification lead
H03 Production defects and component compatibility 12 High 6 Medium Supply chain manager
H04 Safety-relevant embedded failure in the field 20 Critical 8 Medium Hardware lead
H05 Intellectual property and licensing misuse 12 High 4 Low Legal counsel
H06 Confidential design data and privacy exposure 15 High 6 Medium Security lead
H07 Approval and version control failures in design releases 9 Medium 4 Low Configuration manager
H08 Schedule and budget pressure driving shortcuts 12 High 6 Medium Engineering manager
H01

Unclear brief and scope creep

Strategic Before 16 After 6

Requirements for voltage, power budget, interfaces or usability are vague or change after schematic capture, so boards are redesigned late and the product no longer matches what customers asked for.

Who or what is affected: Design engineers, product manager and customers

Causes

Vague customer input, requests added during design and no agreed freeze point.

Consequences

Board respins, missed launch, wasted budget and a product that fails acceptance.

Existing controls

  • Product requirements are written in a shared document.
  • Major changes go through a product manager sign off.

Control gaps

Change requests are accepted informally in meetings and not traced to requirements.

Additional controls

  • Prevent: Freeze a numbered requirements baseline before schematic capture and log every change request.
  • Detect: Review open change requests at each design gate and count those added after the freeze.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Product manager Target: Within 30 days Early warning: Requirement changes logged after the design freeze date.
H02

Late defects from weak testing and corrective iteration

Operational Before 16 After 6

Verification covers only nominal conditions, so timing faults, thermal drift, poor usability and inaccessible controls appear only after prototypes are built, forcing repeated corrective cycles.

Who or what is affected: Verification engineers, firmware team and end users with disabilities

Causes

Test plans written after design, limited bench time and no usability review.

Consequences

Repeat prototype spins, field returns and products some users cannot operate.

Existing controls

  • Bench tests run on each prototype before release.
  • Firmware unit tests run on every code merge.

Control gaps

Test coverage is not measured against the requirements list.

Additional controls

  • Prevent: Write a verification plan that covers corner cases, temperature range and accessibility checks before testing starts.
  • Detect: Track defects by root cause and report repeat faults at each gate.
  • Recover: Hold a corrective iteration review that updates the plan and closes each cause.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Verification lead Target: Within 60 days Early warning: Repeat defects with the same root cause across two build cycles.
H03

Production defects and component compatibility

Supplier Before 12 After 6

Substitute parts, tolerance stack-up or assembly steps differ from the prototype, so boards fail in the factory or in the field even though the design passed bench tests.

Who or what is affected: Contract manufacturer, quality team and customers

Causes

Component shortages, tight tolerances and assembly steps not reviewed for manufacturability.

Consequences

Scrapped boards, late shipments, warranty claims and supplier disputes.

Existing controls

  • Bill of materials is checked against the approved parts list.
  • Sample boards are inspected after each build.

Control gaps

Distributor part changes are not flagged when a lot code changes.

Additional controls

  • Prevent: Lock approved manufacturers and require a design review before any substitute part is used.
  • Detect: Run automated optical and in-circuit tests on every board before shipment.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Supply chain manager Target: Within 45 days Early warning: Yield below the agreed level on any build, or a substitute part with no review record.
H04

Safety-relevant embedded failure in the field

Safety Before 20 After 8

A sensor fault, power glitch or firmware lock-up drives an output into an unsafe state, such as heating beyond the limit or a motor running when it should stop, and the product gives no clear warning.

Who or what is affected: Product users, bystanders and service technicians

Causes

Reliance on a single sensor, noise on supply lines and unhandled fault states in firmware.

Consequences

Injury, property damage, product recall and serious liability.

Existing controls

  • Firmware has a watchdog timer that resets the processor.
  • Design review includes a basic failure mode analysis.

Control gaps

Fault modes are listed but not yet tested on the final board.

Additional controls

  • Prevent: Define a safe state for each output and verify it in the requirements.
  • Detect: Run fault injection tests on sensors and power inputs before each release.
  • Respond: Stop shipment and hold affected units when a safety-relevant defect is confirmed.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Hardware lead Target: Within 30 days Early warning: Watchdog resets or sensor range faults recorded in field logs.
H05

Intellectual property and licensing misuse

Legal and compliance Before 12 After 4

Open source code, a third party library or a licensed design block is used without the right licence, or own designs are shared with a partner without an agreement, so rights are disputed and products must be changed.

Who or what is affected: Design team, company and licensors

Causes

Copying snippets from the internet, reusing blocks from old projects and unclear licence terms.

Consequences

Infringement claims, forced redesign and loss of exclusive rights.

Existing controls

  • Licences for paid tools and libraries are recorded in a register.
  • Contract manufacturers sign a confidentiality agreement.

Control gaps

Scans are not run on hardware design blocks or vendor reference designs.

Additional controls

  • Prevent: Scan code and design blocks for licence terms before they enter the released build.
  • Detect: Review the licence register each quarter against the products shipped.
Likelihood 3 x impact 4 before; 2 x 2 after Owner: Legal counsel Target: Within 60 days Early warning: A new library or design block added without a licence entry.
H06

Confidential design data and privacy exposure

Technology and data Before 15 After 6

Schematics, firmware and customer test data are copied to personal drives, sent by email or left on lab machines, so competitors or attackers obtain designs and personal information.

Who or what is affected: Company, customers and product users

Causes

Shared accounts, remote work, unmanaged personal devices and deadline urgency.

Consequences

Loss of competitive advantage, privacy complaints and regulator contact where personal data is involved.

Existing controls

  • Design files are stored in a repository with named user accounts.
  • Staff sign a confidentiality clause on joining.

Control gaps

Test rigs store logs with customer identifiers that no one reviews.

Additional controls

  • Prevent: Limit repository access by project and require multi-factor sign in for all users.
  • Detect: Review download logs for unusual copying of design files each month.
  • Recover: Rotate keys and revoke access within one day of a suspected leak.
Likelihood 3 x impact 5 before; 2 x 3 after Owner: Security lead Target: Within 30 days Early warning: Bulk downloads from the design repository outside working hours.
H07

Approval and version control failures in design releases

Operational Before 9 After 4

Schematics, layout files or firmware images are released without sign off, or an older revision reaches the factory, so boards are built to a design nobody approved.

Who or what is affected: Manufacturing, field service and customers

Causes

Manual file copying, parallel branches and approvals given by email.

Consequences

Wrong boards built, rework, field failures and a confusing audit trail.

Existing controls

  • Each release has a numbered revision in the repository.
  • A design lead signs the release note.

Control gaps

Approval is not linked to the exact file hash shipped to the factory.

Additional controls

  • Prevent: Block builds that are not tagged with an approved revision number in the system.
  • Detect: Compare each factory build record with the released revision list each week.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Configuration manager Target: Within 45 days Early warning: A build record that cites a revision with no matching approval.
H08

Schedule and budget pressure driving shortcuts

People Before 12 After 6

Deadlines and fixed budgets push engineers to skip reviews, hide known defects or accept an unsafe workaround, and the team does not feel safe raising ethical or cultural concerns.

Who or what is affected: Engineers, managers and customers

Causes

Fixed launch dates, budget overruns and a culture where bad news is delayed.

Consequences

Hidden defects, burnout, poor decisions and damaged customer trust.

Existing controls

  • A monthly schedule review is held with the product manager.
  • An engineering code of conduct is shared with staff.

Control gaps

Waivers are given verbally and are not tracked.

Additional controls

  • Prevent: Set gate criteria that cannot be waived without a signed risk acceptance by a senior manager.
  • Respond: Offer a confidential route to raise ethical concerns and record each outcome.
  • Recover: Re-plan the schedule with a reduced scope when a gate is missed.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Engineering manager Target: Within 60 days Early warning: Gate reviews that close with open defects and no recorded waiver.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from 1, rare, to 5, almost certain, and impact runs from 1, minor, to 5, severe, covering cost, schedule, safety, customer harm and legal exposure. Multiplying the two gives a score from 1 to 25 in 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. Inherent risk is scored before any controls, and residual risk is scored after the existing and added controls. A residual score must never exceed the inherent score, and any inherent score of 10 or more must fall. Safety impact is never rated down only because a failure has not yet happened. Critical risks stop the gate until a senior owner signs a plan, High risks need a dated plan and a named owner, Medium risks need routine controls, and Low risks are accepted and watched. Ratings are challenged by the engineers who do the work, by a peer review at each gate, and whenever a monitoring indicator reaches its threshold.

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
Requirement changes logged after the design freeze date.Escalate to the product manager at once, and to the engineering manager if more than three changes arrive in one month.
Repeat defects with the same root cause across two build cycles.Escalate to the verification lead at once, and hold the gate until the cause is closed.
Factory yield below the agreed level on any build.Escalate to the supply chain manager when yield drops below the floor, and to the quality engineer if it stays low for two builds.
Bulk downloads from the design repository outside working hours.Escalate to the security lead at once and suspend the account until the activity is explained.
Gate closed with open defects and no recorded risk acceptance.Escalate to the engineering manager within one working day, and to the design authority if it recurs.

Contingency arrangements

If a safety-relevant defect or a confirmed data leak occurs, the hardware lead stops shipment and places affected units on hold. The security lead revokes access, preserves logs and informs the product manager. Customers and regulators are contacted through the legal counsel as the relevant rules require, and no one speaks publicly until the facts are checked. Spare boards and a fallback firmware image are kept ready so that service can continue while the root cause is fixed.

Prioritized action plan

  1. Freeze a numbered requirements baseline and route every change through a logged request, owner product manager, within 30 days.
  2. Write a verification plan covering corner cases, temperature range and accessibility checks, owner verification lead, within 60 days.
  3. Run fault injection tests on sensors and power inputs before the next release, owner hardware lead, within 30 days.
  4. Lock approved manufacturers and require design review for any substitute part, owner supply chain manager, within 45 days.
  5. Restrict design repository access by project and enable multi-factor sign in, owner security lead, within 30 days.

Conclusion

Reliable hardware depends on a few steady habits: a frozen requirements baseline, verification that covers corner cases and accessibility, approved parts only, controlled release records and protected design data. The highest scores sit with unclear briefs, weak testing and safety-relevant faults, and each has actions that bring the residual score down. Treat the register as a living record, review it every six months or after any major change, and seek qualified engineering, safety, certification or legal advice for any real product.

Assumptions and limitations

Assumptions

  • The product is a battery powered embedded device with a microcontroller, sensors and a custom board, and its jurisdiction is not specified.
  • A contract manufacturer builds boards from a bill of materials supplied by the design team.
  • Design files, firmware and test records are stored in a shared version-controlled repository.
  • Components come from several distributors, and some parts are sourced from outside the team's own region.

Limitations

  • The scores are examples for learning and describe no real product, factory or customer.
  • Electronics safety, electromagnetic behavior, semiconductor process rules and export controls vary by product and place, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed engineering, safety, certification or legal advice.

Related frameworks to study

  • Failure mode and effects analysis
  • Hierarchy of controls
  • Stage gate design review
  • Three lines model of risk ownership
  • Requirements traceability matrix

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.

Electronics, Semiconductor and Embedded Hardware Design course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,661 Learners