vaayaa Inclusive Education
Technical risk assessment

Software Architecture and Engineering Best Practices Risk Assessment: Dependencies, Cloud, Identity and Recovery Controls

A worked example of how a software team identifies, scores and controls the risks that threaten the confidentiality, integrity and availability of a shared application, from dependencies and identities to logging, recovery and privacy duties.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Software Architecture and Engineering Best Practices course

Executive summary

This assessment shows how a small engineering team can find, rate and control the risks that threaten its software and the data it holds. Eight hazards were chosen because they are plausible in everyday architecture and delivery work, from vulnerable dependencies and misconfigured storage to phishing, insider misuse and weak recovery. Identity compromise carries the highest inherent score because one stolen credential can reach many services. Most hazards fall to Medium or Low once the proposed controls are in place, and the dependency and cloud exposures stay at Medium because they are hard to remove completely. The first actions are multi-factor sign in for all staff, automated dependency scanning, locked down storage defaults and a tested restore. The register is a teaching example, so every score illustrates method rather than describing a real system.

Focus area
Software architecture, secure engineering and delivery practices
Setting
Product engineering team building and running a networked business application on managed cloud infrastructure
Method
Five by five likelihood and impact risk register with inherent and residual scoring

Scope

This assessment covers the design, build, deployment and running of a networked business application, including its source code, build pipeline, cloud services, third-party components, developer devices and the personal data it holds. It does not cover a specific product, vendor or legal system. Jurisdiction, hosting provider, team size and data types are assumptions made for teaching and must be replaced by the real facts in any live assessment.

Context

A small engineering team of developers, a platform engineer and a product owner ships changes several times a week. The application uses a service layer, a relational database, object storage for files and open source libraries pulled from public repositories. Users sign in through a central identity service, and some of them store contact details and account records. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls proposed here, so students can see how treatment changes the rating.

Objectives, assets and stakeholders

The objective is to deliver a reliable and secure application that keeps customer data confidential, accurate and available, while meeting privacy and contract duties and allowing the team to change the system safely. The assets in scope are source code, build pipelines, cloud accounts and configuration, the production database and object storage, personal data about users, credentials and secrets, and the logs that show what happened. Stakeholders include developers, the platform engineer, the product owner, customers, end users, the security lead and any regulator or auditor who may later ask questions. Each risk has one owner role, and the engineering lead reviews the register with the product owner at each release cycle.

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: H04 Likelihood 4, impact 4, score 16, high: H01 Likelihood 4, impact 5, score 20, critical: H03
3 Possible Likelihood 3, impact 3, score 9, medium: H07 Likelihood 3, impact 4, score 12, high: H06 Likelihood 3, impact 5, score 15, high: H02
2 Unlikely Likelihood 2, impact 4, score 8, medium: H08 Likelihood 2, impact 5, score 10, high: H05
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 Likelihood 3, impact 3, score 9, medium: H01
2 Unlikely Likelihood 2, impact 2, score 4, low: H07 Likelihood 2, impact 3, score 6, medium: H04 H05 H06 Likelihood 2, impact 4, score 8, medium: H02 H03
1 Rare Likelihood 1, impact 4, score 4, low: H08
  • 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 Vulnerable dependencies and software supply chain compromise 16 High 9 Medium Engineering lead
H02 Cloud storage and service misconfiguration 15 High 8 Medium Platform engineer
H03 Identity compromise and weak access control 20 Critical 8 Medium Security lead
H04 Phishing and malware on developer devices 12 High 6 Medium IT support lead
H05 Insider misuse and secrets leakage 10 High 6 Medium People and operations lead
H06 Single points of failure and service disruption 12 High 6 Medium Reliability lead
H07 Weak logging and slow incident response 9 Medium 4 Low Security lead
H08 Privacy and personal data handling breaches 8 Medium 4 Low Privacy lead
H01

Vulnerable dependencies and software supply chain compromise

Supplier Before 16 After 9

Open source libraries or build plugins carry known flaws or malicious code, and the team pulls them in without checking versions, sources or updates, so the application inherits the weakness.

Who or what is affected: Developers, end users and customers

Causes

Reliance on many small packages, fast adoption of new libraries and build tools that fetch code from outside sources.

Consequences

Data theft, backdoored releases, emergency patching and loss of customer trust.

Existing controls

  • Dependencies are pinned to fixed versions in the lock file.
  • Developers review new libraries in the pull request.

Control gaps

Transitive dependencies are not scanned, and build plugins are trusted without any review after first adoption.

Additional controls

  • Prevent: Allow only approved package sources and verify package checksums during every build.
  • Detect: Run automated dependency scanning on each build and alert the team on critical findings.
Likelihood 4 x impact 4 before; 3 x 3 after Owner: Engineering lead Target: Within 30 days Early warning: A critical dependency vulnerability that remains open for more than 14 days.
H02

Cloud storage and service misconfiguration

Technology and data Before 15 After 8

A storage bucket, database or administrative port is left publicly reachable or unencrypted because defaults were accepted or a setting was changed in a hurry, exposing stored records to anyone who finds them.

Who or what is affected: Customers, end users and the operations team

Causes

Manual console changes, copied templates with open defaults and unclear ownership of individual cloud resources.

Consequences

Mass data exposure, regulator interest, forced disclosure and a long effort to rebuild trust.

Existing controls

  • Infrastructure is defined in version controlled templates.
  • Encryption at rest is enabled for the main database.

Control gaps

Console changes bypass the template review, and nobody checks for drift between releases.

Additional controls

  • Prevent: Deny public access by default and require a second review for any change to network or storage rules.
  • Detect: Scan cloud settings against a secure baseline each day and report any drift from it.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Platform engineer Target: Within 45 days Early warning: A storage or database resource that is reachable from the public internet.
H03

Identity compromise and weak access control

Technology and data Before 20 After 8

Passwords are reused, phished or guessed, or service accounts hold broad rights, so an attacker or former team member signs in and reaches many services at once.

Who or what is affected: All users, administrators and customers whose accounts are linked

Causes

Reused passwords, long standing administrator rights, phishing and shared service credentials.

Consequences

Account takeover, data theft, fraudulent changes and loss of control over production systems.

Existing controls

  • Staff accounts require a password that meets a minimum length.
  • Administrator rights are granted through a central directory.

Control gaps

Service accounts are not reviewed, and sessions are not revoked when a role changes.

Additional controls

  • Prevent: Enforce multi-factor sign in and least privilege roles for all staff and service accounts.
  • Respond: Revoke sessions and rotate shared secrets within one hour of a suspected compromise.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: A successful sign in from an unusual location or device, followed by a privilege change.
H04

Phishing and malware on developer devices

Technology and data Before 12 After 6

A developer opens a malicious attachment or fake login page, or installs a tainted tool, and malware or stolen tokens reach the source code and the deployment pipeline.

Who or what is affected: Developers, the build system and production credentials

Causes

Email lures, unmanaged personal devices used for code and developers who install tools quickly.

Consequences

Stolen source code, poisoned builds and access to production secrets.

Existing controls

  • Antivirus runs on company laptops and is updated automatically.
  • Staff complete a short phishing awareness course each year.

Control gaps

Personal devices used to reach code are not inventoried, and access token scopes are broader than needed.

Additional controls

  • Prevent: Use managed devices with disk encryption, application allow lists and hardware keys for sign in.
  • Detect: Alert on new unsigned software and on pipeline access from an unexpected developer token.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: IT support lead Target: Within 45 days Early warning: A build pipeline run triggered from an unrecognized device or token.
H05

Insider misuse and secrets leakage

People Before 10 After 6

A current or former team member copies data, changes code without review or commits passwords and keys to a shared repository, either by mistake or on purpose, so information leaves the business or the system is harmed.

Who or what is affected: Customers, colleagues and the business

Causes

Shared secrets kept in code, broad read access and departures that are handled late.

Consequences

Data leakage, sabotage, breach of contract and reputational harm.

Existing controls

  • Repository access is granted per project and reviewed when someone joins.
  • Staff sign confidentiality agreements before they receive access.

Control gaps

The exit checklist is not linked to repository and cloud access, and secret scanning is optional.

Additional controls

  • Prevent: Scan commits for secrets before merge and store credentials in a managed vault.
  • Respond: Revoke access on the same day as an exit and review recent downloads from that account.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: People and operations lead Target: Within 60 days Early warning: A secret detected in a commit, or a large download by a user who is leaving.
H06

Single points of failure and service disruption

Operational Before 12 After 6

A shared database, a single message queue or an untested deployment step fails under load or during a release, and the whole service goes down for longer than customers can accept.

Who or what is affected: Customers, support staff and operations

Causes

Heavy coupling between services, untested configuration changes and peak demand.

Consequences

Lost sales, breached service commitments and frustrated users.

Existing controls

  • Production runs across two availability zones.
  • Releases roll out gradually to a small share of users first.

Control gaps

Failover has not been tested in full, and rollback steps are still carried out by hand.

Additional controls

  • Prevent: Remove single points of failure for the database and queue and set capacity limits.
  • Recover: Test a full restore and a failover at least twice a year against a written recovery time target.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Reliability lead Target: Within 60 days Early warning: An error rate or response time above the agreed limit for more than ten minutes.
H07

Weak logging and slow incident response

Operational Before 9 After 4

Logs are missing, incomplete or stored on the same system they record, so an intrusion or fault goes unseen for weeks and the team cannot show what happened.

Who or what is affected: Security team, customers and regulators

Causes

Logging added late, no standard fields and noisy alerts that the team learns to ignore.

Consequences

Slow containment, poor evidence for regulators and repeated incidents.

Existing controls

  • Application errors are written to a central log.
  • An on-call rota exists for production faults.

Control gaps

Security events are not kept long enough to investigate, and the playbook has never been rehearsed.

Additional controls

  • Detect: Record sign ins, privilege changes and data exports with time stamps, stored away from the main system.
  • Respond: Write a short incident playbook with named responders and a communication step.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security lead Target: Within 45 days Early warning: Security events that are not reviewed within one working day.
H08

Privacy and personal data handling breaches

Legal and compliance Before 8 After 4

Personal data is collected beyond need, kept longer than necessary, copied into test environments or shared with a third party without proper notice, which can breach privacy duties in some jurisdictions.

Who or what is affected: End users and customers whose personal data is held

Causes

An unclear data inventory, copied datasets and features added without a privacy review.

Consequences

Regulatory action, compensation claims and loss of user trust.

Existing controls

  • A privacy notice is published for users.
  • Production data is not used for development by default.

Control gaps

There is no current inventory of personal data, and new third party tools are not checked.

Additional controls

  • Prevent: Minimize data fields, set retention limits and mask personal data in test environments.
  • Respond: Log data subject requests and route them to the privacy lead within two working days.
Likelihood 2 x impact 4 before; 1 x 4 after Owner: Privacy lead Target: Within 90 days Early warning: A new third party integration added without a privacy review.

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, covering data loss, downtime, financial cost, legal duty and harm to users. 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 orders work and does not measure anything precisely. Inherent risk is the score before any controls, assessed as if the system had no safeguards beyond basic practice. Residual risk is the score after the existing controls and the additional controls named in the register, and it must never be higher than the inherent score. A Critical or High residual needs senior attention and a dated plan, a Medium needs routine controls with a named owner, and a Low is accepted and watched. Ratings are challenged in a peer review where a second engineer tries to find a scenario that makes the score worse, and a security specialist checks any hazard touching credentials, personal data or regulated duties. Ratings are reopened 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
Accounts without multi-factor sign in, or shared credentials found in code or chat.Escalate to the security lead at once, rotate the credential and remove the account within 24 hours.
Open dependency vulnerabilities rated critical that are older than 14 days.Escalate to the engineering lead when any is found, and to the product owner if still open after 30 days.
Storage buckets or database instances that are publicly reachable or missing encryption settings.Escalate to the platform engineer immediately and block the release until the setting is corrected.
Failed sign in attempts or privilege changes outside normal working hours.Escalate to the security lead within one working day, and to the incident lead if access is confirmed.
Restore tests not completed in the last quarter.Escalate to the reliability lead when a test is overdue, and to the product owner if it slips beyond 30 days.

Contingency arrangements

If a serious event occurs, such as a confirmed credential theft, a data exposure or a production outage that cannot be fixed quickly, the incident lead opens an incident record and stops the affected deployments. The platform engineer isolates the affected accounts, rotates secrets and restores service from the latest tested backup. The product owner informs customers, and where a legal duty applies the privacy lead decides on notification with specialist advice. Evidence and logs are preserved before any clean up, and the team holds a short review within a week to update the register.

Prioritized action plan

  1. Enforce multi-factor sign in and remove shared accounts, owner platform engineer, within 30 days.
  2. Turn on automated dependency scanning and block builds with critical known vulnerabilities, owner engineering lead, within 30 days.
  3. Set safe defaults for storage and cloud network rules, with a review before each release, owner platform engineer, within 45 days.
  4. Test a full restore from backup and write a recovery runbook, owner reliability lead, within 60 days.
  5. Add structured logging and an on-call incident process with named responders, owner security lead, within 45 days.

Conclusion

Reliable and secure software depends on a few steady habits: multi-factor sign in, scanned dependencies, safe defaults for cloud settings, tested backups, useful logs and a clear incident path. The highest scores sit with identity compromise, misconfiguration and supply chain exposure, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle and after any significant release, and seek qualified security, privacy and legal advice for any real system.

Assumptions and limitations

Assumptions

  • The application runs on a managed cloud platform with shared responsibility for infrastructure.
  • The team uses version control, automated builds and a standard set of open source libraries.
  • Jurisdiction is not specified, so privacy and security duties are described in general terms only.

Limitations

  • The scores are examples for learning and do not describe any real product or organization.
  • Security, privacy and cloud rules differ by country and change over time, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed advice.

Related frameworks to study

  • STRIDE threat modeling for identifying spoofing, tampering and disclosure threats
  • OWASP Top Ten as a checklist of common web application weaknesses
  • NIST Cybersecurity Framework functions of identify, protect, detect, respond and recover
  • Hierarchy of controls for ordering elimination, engineering and procedural measures
  • Defense in depth across network, identity, application and data layers

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.

Software Architecture and Engineering Best Practices course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,186 Learners