vaayaa Inclusive Education
Technical risk assessment

Mobile, Desktop and Embedded Application Development Risk Assessment: Release, Security and Device Risks

A worked example of how a development team finds, scores and controls the risks in building mobile, desktop and embedded applications, from release defects and insecure data to firmware updates, supplier code and store rules.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Mobile, Desktop and Embedded Application Development course

Executive summary

This assessment shows how a product team can find, rate and control the risks in building mobile, desktop and embedded applications. Eight risks were chosen because they are plausible in everyday development, release and support work. Insecure data handling and firmware update failure carry the greatest potential harm, so they are scored highest before controls. Most risks fall to Medium or Low once the existing controls and proposed additional controls are applied, but data security stays at Medium because the impact of a breach remains serious. The first actions are device testing before release, encrypted storage checks, power loss testing for firmware, dependency scanning and a privacy data map. The scores are a teaching example and illustrate method rather than any real product.

Focus area
Application development across mobile, desktop and embedded platforms
Setting
Product engineering team building customer-facing apps and an embedded device companion app for a small to mid-sized software business
Method
Five by five likelihood and impact risk register with inherent and residual scoring

Scope

This assessment covers the design, build, testing, release and maintenance of mobile apps, desktop applications and embedded device software, including the companion apps and update services that connect them. It looks at risks to users, devices, data, legal duties, reputation and delivery continuity. It does not assess any real product, device or store listing. Target platforms, jurisdictions, device hardware and data volumes are assumptions made for teaching.

Context

The team has a product owner, four application developers, two embedded engineers, a quality analyst and a platform engineer who manages build pipelines and device update servers. Mobile and desktop code is shared through a version control system with automated builds. Embedded firmware runs on a small set of hardware variants in the field and is updated over the air. Third-party libraries and a cloud service supply authentication, analytics and push messages. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls proposed here.

Objectives, assets and stakeholders

The objective is to ship reliable, secure and accessible applications and embedded software on schedule, protect user data and device safety, meet store and privacy duties, and keep the trust of users, partners and the business. The assets in scope are source code, build pipelines, signing keys, user accounts and personal data, embedded hardware and firmware images, update servers, third-party components and the team's delivery capacity. Stakeholders include end users, device owners, field technicians, developers, the product owner, platform and security staff, store reviewers, privacy and compliance advisers and the company leadership. Every risk has one owner role, and the product owner reports the register to leadership 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 2, score 8, medium: H08 Likelihood 4, impact 3, score 12, high: H04 Likelihood 4, impact 4, score 16, high: H01 Likelihood 4, impact 5, score 20, critical: H02
3 Possible Likelihood 3, impact 3, score 9, medium: H06 Likelihood 3, impact 4, score 12, high: H05 H07 Likelihood 3, impact 5, score 15, high: H03
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: H06 H08 Likelihood 2, impact 3, score 6, medium: H01 H04 H05 H07 Likelihood 2, impact 4, score 8, medium: H02 H03
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 Release defect reaches users after shipping 16 High 6 Medium Release manager
H02 Insecure storage and transmission of user data 20 Critical 8 Medium Security lead
H03 Failed firmware update leaves devices unusable 15 High 8 Medium Embedded systems lead
H04 Vulnerable third-party library or SDK 12 High 6 Medium Engineering manager
H05 Breach of store policy and privacy duties 12 High 6 Medium Compliance adviser
H06 Skills gap in secure coding and platform specifics 9 Medium 4 Low Engineering manager
H07 Accessibility and ethical design failures 12 High 6 Medium Product owner
H08 Operating system and device fragmentation breaks desktop builds 8 Medium 4 Low Platform engineer
H01

Release defect reaches users after shipping

Operational Before 16 After 6

A change passes review but fails on a device model, screen size or operating system version the test suite does not cover, so crashes or data loss reach users after release.

Who or what is affected: End users, support staff and the product owner

Causes

Limited device coverage, late code changes and reliance on emulators for final checks.

Consequences

Lost user data, negative store reviews, emergency patches and support costs.

Existing controls

  • Automated unit and interface tests run on every merge.
  • A staged rollout sends each release first to a small group of users.

Control gaps

Physical device testing is sampled rather than planned, and rollback steps are not rehearsed.

Additional controls

  • Prevent: Expand the device test matrix to cover the most used models and operating system versions before each release.
  • Detect: Track crash rates by version and device in the first 72 hours and compare them with the last release.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Release manager Target: Within 30 days Early warning: Crash rate for a new release above the agreed threshold within 72 hours of rollout.
H02

Insecure storage and transmission of user data

Technology and data Before 20 After 8

Tokens, personal details or device identifiers are stored in plain text on the device or sent over weak connections, so an attacker who obtains a phone or intercepts traffic can read them.

Who or what is affected: Users, account holders and the security lead

Causes

Shortcuts during development, copied sample code and logging of sensitive values for debugging.

Consequences

Account takeover, privacy breach, regulator interest and loss of user trust.

Existing controls

  • Sessions use encrypted connections to the cloud service.
  • Access tokens expire after a fixed period.

Control gaps

Debug logs are not checked before release, and no one reviews stored data on the device.

Additional controls

  • Prevent: Store secrets only in the platform secure storage and require encrypted transport with certificate checks.
  • Detect: Run static analysis and a dynamic test of network traffic on each build and log findings for review.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: A build that writes tokens or personal data to logs or plain storage in an automated scan.
H03

Failed firmware update leaves devices unusable

Safety Before 15 After 8

An over-the-air firmware update is interrupted by power loss or a network drop, or contains a bug in the boot code, so a device stops working or behaves unpredictably in use.

Who or what is affected: Device owners, field technicians and the embedded engineering lead

Causes

Many hardware variants, limited test rigs and update packages built from unverified branches.

Consequences

Devices out of service, unsafe behavior in use, costly returns and possible injury claims.

Existing controls

  • Updates are signed and checked before installation.
  • A separate recovery partition holds the previous firmware.

Control gaps

Power loss testing is not run on every hardware variant, and recovery steps are not drilled.

Additional controls

  • Prevent: Test updates on each hardware variant, including power loss during install, before any fleet release.
  • Respond: Keep a field recovery procedure and a staged rollback that can be triggered from the update server.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Embedded systems lead Target: Within 60 days Early warning: Failed update rate on a hardware variant above the agreed threshold in a staged rollout.
H04

Vulnerable third-party library or SDK

Supplier Before 12 After 6

A library, analytics kit or software development kit used in the apps contains a known flaw or is abandoned by its maintainer, so the product inherits a weakness the team did not write.

Who or what is affected: Users, the engineering manager and the platform engineer

Causes

Fast adoption of popular packages, pinned versions that are never updated and transitive dependencies nobody reviews.

Consequences

Data exposure, forced emergency updates and delays to delivery.

Existing controls

  • Libraries are chosen from a short approved list.
  • Dependency versions are pinned in the build file.

Control gaps

Transitive dependencies are not listed, and upgrade work is always postponed.

Additional controls

  • Prevent: Require a review of licence, maintenance status and security history before adding any new library.
  • Detect: Scan dependencies in the build pipeline and open a ticket for each new vulnerability found.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Engineering manager Target: Within 45 days Early warning: A scan result showing a high severity flaw in a library used by a shipped product.
H05

Breach of store policy and privacy duties

Legal and compliance Before 12 After 6

An app collects more data than it declares, lacks required permission prompts or fails a store review rule, so it is removed or the business faces a complaint about how it handles personal data.

Who or what is affected: Users, the product owner and the compliance adviser

Causes

Late feature additions, third-party analytics that collect more than expected and unclear permission wording.

Consequences

App removal, complaints, regulator contact and costly rework.

Existing controls

  • A checklist is used before each store submission.
  • The privacy notice is reviewed each year by the product owner.

Control gaps

Analytics data flows are not mapped, and store policy changes are noticed only after rejection.

Additional controls

  • Prevent: Map each data field to a stated purpose and remove any field that has no declared use before release.
  • Respond: Keep a store appeal and user notice template ready for a removal or complaint, reviewed by a qualified adviser.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Compliance adviser Target: Within 60 days Early warning: A store rejection or user complaint that cites permissions or undeclared data use.
H06

Skills gap in secure coding and platform specifics

People Before 9 After 4

Developers new to a platform or embedded toolchain make avoidable errors in memory use, permissions or threading, and the team does not notice because few people review the code deeply.

Who or what is affected: Developers, reviewers and the engineering manager

Causes

Fast hiring, rapid platform change and reviews that focus on style rather than safety.

Consequences

Defects in production, rework and weak trust in the team's output.

Existing controls

  • Code is reviewed by a second developer before merge.
  • New starters are paired with an experienced engineer for the first month.

Control gaps

Training records are not linked to code ownership, and review checklists are out of date.

Additional controls

  • Prevent: Set a short secure coding and platform course for every developer, with a completion record.
  • Detect: Sample merged code each month for common errors and feed results into the course content.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Engineering manager Target: Within 90 days Early warning: Repeated review comments on the same class of error by one or more developers.
H07

Accessibility and ethical design failures

Reputational Before 12 After 6

Screens lack support for screen readers or low vision, or use dark patterns that push users into costly choices, so groups of users are excluded or misled and the brand is harmed.

Who or what is affected: Users with disabilities, vulnerable users and the product owner

Causes

Visual design choices made without testing, pressure for conversion and limited accessibility expertise.

Consequences

Complaints, exclusion of users, negative reviews and loss of public trust.

Existing controls

  • Design reviews include a colour contrast check.
  • User testing is run with a small panel before major releases.

Control gaps

Accessibility testing is optional, and the user panel rarely includes people with disabilities.

Additional controls

  • Prevent: Add accessibility criteria to the definition of done and test each new screen with assistive technology.
  • Respond: Publish a clear route for users to report barriers and fix reported barriers in a set period.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Product owner Target: Within 60 days Early warning: Accessibility complaints or store reviews that mention unusable screens or misleading prompts.
H08

Operating system and device fragmentation breaks desktop builds

Operational Before 8 After 4

A new operating system version or hardware driver changes behavior, so a desktop application crashes, loses settings or fails to install for part of the user base.

Who or what is affected: Desktop users, support staff and the platform engineer

Causes

Frequent operating system updates, varied driver versions and reliance on one test machine.

Consequences

Support tickets, temporary loss of users and slower releases.

Existing controls

  • The team tests the desktop build on the current operating system version.
  • Installers are signed and versioned.

Control gaps

Beta operating systems are not tested, and older versions are no longer checked.

Additional controls

  • Prevent: Test beta operating system releases on a dedicated machine before they reach users.
  • Recover: Keep the previous installer available for download and document a settings reset step for support staff.
Likelihood 4 x impact 2 before; 2 x 2 after Owner: Platform engineer Target: Within 60 days Early warning: A rise in installation or launch failure reports within a week of an operating system update.

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 Catastrophic, with numeric values of 1 to 5 for each. Multiplying the two gives a score from 1 to 25 that 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. Low means accept and watch. Medium means routine controls with a named owner. High means senior attention and a dated plan. Critical means stop or limit the activity until the score is reduced. Inherent risk is the score before any controls. Residual risk is the score after the existing and additional controls are in place, and it must never be higher than the inherent score. Impact is judged on user harm, device safety, data exposure, legal consequence, delivery delay and reputation, and a risk is not rated down only because it has not yet happened. Developers, testers and support staff should challenge each rating, and any score is reviewed whenever a monitoring indicator reaches its escalation 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
Crash rate for a new release within 72 hours of rollout, by device and version.Escalate to the release manager when the rate exceeds the agreed threshold, and pause the staged rollout at once.
Builds that write tokens or personal data to logs or plain storage.Escalate to the security lead before the build is merged, and block release until the finding is closed.
Failed firmware update rate on a hardware variant during staged rollout.Escalate to the embedded systems lead when failures exceed the threshold, and halt further distribution to that variant.
High severity vulnerabilities in libraries used by shipped products.Escalate to the engineering manager within one working day, and to leadership if no fix is planned within 14 days.
Store rejections or complaints that cite permissions or undeclared data use.Escalate to the compliance adviser within two working days, and to the product owner for any removal notice.

Contingency arrangements

If a serious event occurs, such as a confirmed data exposure, a firmware failure in the field or a store removal, the product owner pauses the affected release or update channel and informs leadership. The security lead isolates the issue, revokes exposed tokens and confirms the scope from logs. The embedded lead triggers the staged rollback and dispatches field recovery steps. Legal and privacy advisers are contacted for any notice duty, and support staff receive a plain script for users.

Prioritized action plan

  1. Stop debug logging of tokens and personal data and run an automated storage scan on every build, owner security lead, within 30 days.
  2. Run power loss and rollback tests on each embedded hardware variant before any fleet update, owner embedded systems lead, within 60 days.
  3. Expand the device test matrix and rehearse rollback before each release, owner release manager, within 30 days.
  4. Map each data field in the apps to a declared purpose and remove unused fields, owner compliance adviser, within 60 days.
  5. Add dependency scanning and a library approval step to the pipeline, owner engineering manager, within 45 days.

Conclusion

Dependable applications and devices depend on steady habits: broad device testing, secure storage and transport, signed and recoverable updates, reviewed dependencies and a clear privacy map. The highest scores sit with data security and firmware updates, and each has actions that reduce the residual score. Treat the register as a living record, review it on the stated cycle and seek qualified advice for any real security, safety, legal or store policy question.

Assumptions and limitations

Assumptions

  • Apps target two mobile operating systems and one desktop platform, and the embedded device runs a real-time or small operating system.
  • Devices are deployed to users who cannot easily be reached in person, so over-the-air updates are the main route for fixes.
  • Jurisdiction is not specified, so privacy and consumer duties are described in general terms only and need local review.

Limitations

  • The scores are examples for learning and do not describe any real product, device, store listing or user base.
  • Privacy, product safety, accessibility and store policy rules differ by country and change over time, so specialist legal and safety review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed engineering, security or legal advice.

Related frameworks to study

  • OWASP mobile and web application security guidance
  • Secure software development lifecycle model
  • Hierarchy of controls
  • Three lines model of risk ownership

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.

Mobile, Desktop and Embedded Application Development course Read the best practices for this course

More Technical risk assessments

Hourly Active: 45,552 Learners