vaayaa Inclusive Education
Technical risk assessment

Cloud Computing and DevOps Engineering Risk Assessment: Identity, Pipelines, Data and Recovery Controls

A worked example of how a cloud and DevOps team finds, scores and controls risks to identities, build pipelines, stored data, service availability and logging, with inherent and residual ratings and named owners.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Cloud Computing and DevOps Engineering course

Executive summary

This assessment shows how a product team on a public cloud platform can find, rate and control the risks that matter most to its data, services and users. Eight risks were chosen because they are plausible in everyday cloud and DevOps work, from stolen identities and exposed storage to compromised pipelines, phishing, insider misuse, outages, logging gaps and privacy breaches. Each risk is scored before controls and again after existing and added controls. Storage misconfiguration is the highest natural risk, while most risks fall to Medium or Low once the recommended controls are in place. The first actions are phishing resistant sign in, account wide blocks on public storage, signed build images and rehearsed restores. The team is a teaching example, so every score illustrates method, not a real organization.

Focus area
Cloud computing and DevOps engineering
Setting
Software delivery teams running services on a public cloud platform with automated build and deployment pipelines
Method
Five by five likelihood and impact risk register

Scope

This assessment covers a product team that builds, deploys and runs services on a public cloud platform using infrastructure as code and automated pipelines. It covers identities, workloads, stored data, build pipelines, logging, incident response and recovery. It does not cover any real provider, account or contract. Provider region, data classes, regulatory regime and team size are assumptions made for teaching and must be checked before any real use.

Context

The team runs containerized services and managed databases across two cloud accounts, with a central identity provider, a version control system and a continuous delivery pipeline. Infrastructure is defined as code and changed only through reviewed merge requests. A small platform group supports several product squads, and an on-call rota responds to alerts. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls recommended here.

Objectives, assets and stakeholders

The objective is to deliver reliable services while protecting the confidentiality, integrity and availability of data, meeting privacy and compliance duties, and keeping the trust of customers and colleagues. The assets in scope are cloud accounts and their resources, identity and access records, source code and build pipelines, stored customer data and backups, logs and the platform itself. Stakeholders include the product squads, the platform group, the on-call engineers, the data protection lead, customers, suppliers of libraries and cloud services, and the regulators that may ask questions after an incident. Clear ownership matters: every risk has one owner role, and the site reliability lead reports the register to engineering 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 Likelihood 5, impact 4, score 20, critical: H02
4 Likely 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: H04 Likelihood 3, impact 5, score 15, high: H03 H06
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: H02
2 Unlikely Likelihood 2, impact 2, score 4, low: H07 Likelihood 2, impact 3, score 6, medium: H01 H04 H05 Likelihood 2, impact 4, score 8, medium: H03 H06
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 Unauthorized access through compromised cloud identities 16 High 6 Medium Identity and access lead
H02 Misconfigured storage exposing sensitive data 20 Critical 9 Medium Platform security engineer
H03 Compromised build pipeline and third party dependencies 15 High 8 Medium Release engineering lead
H04 Malware and phishing against engineer workstations 12 High 6 Medium End user computing manager
H05 Insider misuse of production privileges 10 High 6 Medium Head of engineering
H06 Service outage without a tested recovery path 15 High 8 Medium Site reliability lead
H07 Logging gaps that delay incident response 9 Medium 4 Low Security operations lead
H08 Privacy and data residency breach 8 Medium 4 Low Data protection lead
H01

Unauthorized access through compromised cloud identities

Technology and data Before 16 After 6

A stolen password, token or session cookie lets an attacker sign in as a real engineer or service account, reading data or changing resources without being noticed, because access is broad and rarely reviewed.

Who or what is affected: Engineers, product customers and data owners

Causes

Phished credentials, reused passwords and long lived keys stored on laptops.

Consequences

Data theft, altered infrastructure, service outage and loss of customer trust.

Existing controls

  • Single sign on is required for all console and command line access.
  • Access tokens expire after a set period and must be renewed.

Control gaps

Access reviews happen only at project close, so unused privileges persist for months.

Additional controls

  • Prevent: Enforce phishing resistant multi-factor sign in and remove standing administrator rights.
  • Detect: Alert on sign ins from new locations or unusual times and on token creation outside normal patterns.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Identity and access lead Target: Within 30 days Early warning: Administrator sign ins from an unfamiliar device or location, or a token issued without a matching change request.
H02

Misconfigured storage exposing sensitive data

Technology and data Before 20 After 9

A storage bucket, database snapshot or backup is set to public or shared too widely, often because a template default or a quick manual change was left in place, exposing customer records to anyone who finds the address.

Who or what is affected: Customers, data owners and the security team

Causes

Manual console changes, copied templates and unclear ownership of older resources.

Consequences

Regulatory notice, customer harm, forced disclosure work and reputational damage.

Existing controls

  • Storage is private by default in the team templates.
  • Backups are encrypted at rest with keys held by the platform group.

Control gaps

Resources created outside the pipeline are not scanned, so manual changes go unseen.

Additional controls

  • Prevent: Block public access at the account level and reject any template that sets a public policy.
  • Detect: Scan all storage settings daily and raise an alert for any resource that becomes publicly readable.
Likelihood 5 x impact 4 before; 3 x 3 after Owner: Platform security engineer Target: Within 14 days Early warning: Any storage resource whose access policy changes to allow public or anonymous reads.
H03

Compromised build pipeline and third party dependencies

Supplier Before 15 After 8

A malicious or vulnerable library, plugin or build image is pulled into the pipeline, or a secret stored in a pipeline variable is read, so attacker code reaches production releases that customers trust.

Who or what is affected: Release engineers, customers and downstream partners

Causes

Unvetted open source packages, long lived pipeline secrets and broad plugin permissions.

Consequences

Tampered releases, data theft, emergency rollbacks and supplier disputes.

Existing controls

  • Pipeline runners are isolated from production networks.
  • Dependencies are pinned to specific versions in the lock files.

Control gaps

Transitive dependencies are not reviewed, and pipeline secrets are not rotated on a schedule.

Additional controls

  • Prevent: Use signed build images and allow only approved package sources through a mirror.
  • Detect: Scan dependencies and container images on each build and block releases with known critical flaws.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Release engineering lead Target: Within 45 days Early warning: A new dependency or build plugin added without a review record, or a build that pulls from an unknown source.
H04

Malware and phishing against engineer workstations

Technology and data Before 12 After 6

A phishing message or a malicious download installs malware on a laptop that holds cloud keys, session tokens or source code, letting an attacker move into the cloud estate from a trusted device.

Who or what is affected: Engineers, the platform group and source code owners

Causes

Urgent requests, links in chat messages and developers installing tools from unknown sites.

Consequences

Stolen credentials, lateral movement, leaked code and costly rebuild work.

Existing controls

  • Endpoint protection runs on all managed laptops.
  • Staff complete a yearly course on spotting suspicious messages.

Control gaps

Keys are stored on laptops, and the response plan for a lost or infected device is informal.

Additional controls

  • Prevent: Restrict admin rights on laptops and block unmanaged software installs.
  • Respond: Isolate any device showing signs of malware and rotate every key it could have reached.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: End user computing manager Target: Within 30 days Early warning: Endpoint alerts for blocked malware on a device that holds production credentials.
H05

Insider misuse of production privileges

People Before 10 After 6

A current or former engineer with production rights changes data, deletes resources or copies customer records for personal gain or out of anger, and the action is hard to attribute because shared accounts are used.

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

Causes

Shared accounts, excessive rights, grievances and weak offboarding for contractors.

Consequences

Data loss or theft, legal exposure, dismissal disputes and loss of trust.

Existing controls

  • Background checks are made for roles with production access.
  • Leavers have their accounts disabled on their last working day.

Control gaps

Contractor accounts are sometimes not linked to an end date, so access can outlive the contract.

Additional controls

  • Prevent: Use named accounts only and require a second approver for deleting production data.
  • Detect: Log all privileged actions and review unusual activity by role each month.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: Head of engineering Target: Within 60 days Early warning: Bulk data exports or deletions by one user outside a scheduled change window.
H06

Service outage without a tested recovery path

Operational Before 15 After 8

A failed deployment, a regional fault or a bad configuration change takes a core service offline, and the team cannot restore it within the agreed time because recovery steps were never rehearsed.

Who or what is affected: Customers, support staff and on-call engineers

Causes

Untested runbooks, single region dependencies and changes made under time pressure.

Consequences

Lost revenue, service credits, customer churn and strained staff.

Existing controls

  • Deployments use a staged rollout with automatic health checks.
  • Databases take scheduled backups with retention rules.

Control gaps

Restore drills cover only one database, and the recovery time target is not tracked.

Additional controls

  • Prevent: Require a documented rollback plan and a canary stage for every production change.
  • Recover: Rehearse a full restore from backup each quarter and record the time taken against the target.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Site reliability lead Target: Within 60 days Early warning: A restore test that exceeds its target time, or a runbook step that has not been run in the last quarter.
H07

Logging gaps that delay incident response

Operational Before 9 After 4

Key events such as sign ins, configuration changes and network flows are not logged or are kept for too short a time, so responders cannot reconstruct what happened or confirm when an attack began.

Who or what is affected: Incident responders, auditors and affected customers

Causes

Logs turned off to save cost, mixed retention periods and no central store.

Consequences

Slow containment, unclear scope of breach and weak evidence for regulators.

Existing controls

  • Platform audit logs are switched on for the main accounts.
  • An incident channel and contact list are maintained.

Control gaps

Logs from the pipeline and from third party services are not collected centrally.

Additional controls

  • Prevent: Make audit logging a required part of every new resource template.
  • Respond: Run a tabletop exercise each half year using a logged scenario and record the gaps found.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security operations lead Target: Within 90 days Early warning: A production account with audit logging disabled or a log source that has gone silent for over a day.
H08

Privacy and data residency breach

Legal and compliance Before 8 After 4

Personal data is copied to a region, backup or analytics tool that the privacy duties do not permit, or is kept longer than needed, so the team must explain and correct the handling of data it did not mean to move.

Who or what is affected: Data subjects, the privacy officer and the legal team

Causes

Analytics exports, test data copied from production and unclear retention rules.

Consequences

Regulatory inquiry, fines where applicable, mandatory notices and loss of customer trust.

Existing controls

  • A data inventory lists the main personal data stores.
  • Data is stored only in approved regions as set in the templates.

Control gaps

Test environments are refreshed from production without masking, and the inventory is updated only once a year.

Additional controls

  • Prevent: Tag personal data resources and block their creation outside approved regions.
  • Detect: Review data copies and retention periods each quarter against the inventory.
Likelihood 2 x impact 4 before; 1 x 4 after Owner: Data protection lead Target: Within 90 days Early warning: A new copy of personal data created in a region or tool that is not listed in the data inventory.

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. 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 precise measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and added controls are working. Impact is judged on data exposed, service time lost, legal duties triggered, cost to recover and harm to customers. 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 monitored. Engineers who run the systems should challenge every rating, and the register is reviewed whenever an indicator reaches its threshold or a material change is made to the platform.

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
Administrator sign ins from unfamiliar devices or locations, or tokens issued without a matching change request.Escalate to the identity and access lead at once, revoke the session, and inform the security operations lead if the sign in is not confirmed within one hour.
Storage resources whose access policy changes to allow public or anonymous reads.Escalate to the platform security engineer immediately, restrict the resource, and report to the data protection lead within one working day.
New dependencies or build plugins added without a review record, or builds that pull from unknown sources.Escalate to the release engineering lead before the next release, and block promotion until a review record is complete.
Restore tests exceeding the target recovery time, or runbook steps not run in the last quarter.Escalate to the site reliability lead when a test misses its target, and to engineering leadership if two consecutive tests fail.
Production accounts with audit logging disabled, or log sources silent for more than one day.Escalate to the security operations lead within the same day, and to the head of engineering if the gap is still open after three days.

Contingency arrangements

If a serious event occurs, such as a confirmed credential theft, a public data exposure or a prolonged outage, the on-call lead opens the incident channel and assigns an incident commander. Affected keys and sessions are revoked, and the identity lead disables the accounts involved. Resources are isolated, evidence is preserved from the logs, and the latest tested backup is used for restoration. The data protection lead decides whether notices are required, and the head of engineering informs leadership and customers in plain language.

Prioritized action plan

  1. Enforce phishing resistant multi-factor sign in and remove standing administrator rights, owner identity and access lead, within 30 days.
  2. Block public access to storage at account level and scan all storage settings daily, owner platform security engineer, within 14 days.
  3. Sign build images and restrict package sources through an approved mirror, owner release engineering lead, within 45 days.
  4. Rehearse a full restore each quarter and record the time taken against target, owner site reliability lead, within 60 days.
  5. Turn on audit logging for all accounts and collect pipeline logs centrally, owner security operations lead, within 90 days.

Conclusion

Reliable cloud services depend on a few steady habits: strong sign in, private storage by default, reviewed and signed pipelines, complete logs and restores that have been rehearsed. The highest natural scores sit with storage exposure, identity compromise and pipeline tampering, 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 and legal advice for any real platform, contract or regulatory question.

Assumptions and limitations

Assumptions

  • The team uses a major public cloud provider under a shared responsibility model, and jurisdiction is not specified.
  • Engineers use managed laptops, and production access is granted through a central identity provider.
  • The service stores some personal data, so privacy duties apply in general terms only.
  • Team size, region and contract terms are not specified and are assumed for teaching purposes.

Limitations

  • The scores are examples for learning and do not describe any real platform, team or incident.
  • Cloud security settings and provider features change often, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed security advice.

Related frameworks to study

  • Shared responsibility model for cloud services
  • Least privilege access principle
  • Infrastructure as code review practices
  • Incident response lifecycle
  • Defense in depth layering

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.

Cloud Computing and DevOps Engineering course Read the best practices for this course

More Technical risk assessments

Hourly Active: 45,552 Learners