vaayaa Inclusive Education
Technical risk assessment

Azure Cloud Fundamentals Risk Assessment: Identity, Data, Recovery and Logging Controls

A worked example of how a learner builds a risk assessment for a small team running cloud services on Azure, covering identity, data, configuration, third parties, recovery and logging.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: High to Medium
See the Azure Cloud Fundamentals course

Executive summary

This assessment shows how a small team running a cloud application on Azure can find, score and control the risks that threaten its data, identities and services. Eight risks were chosen because they are plausible in everyday cloud operations. Identity compromise and misconfigured storage are the most likely to cause serious harm, and privacy duties carry the greatest impact. Each risk is scored before controls and again after existing and added controls. Most risks fall to Medium or Low once the proposed controls are in place, though identity compromise stays at Medium because its impact remains serious. The first actions are phishing resistant sign in for administrators, private data stores by default, a written shared responsibility matrix and centralized logs. The example is for teaching, so every score illustrates method rather than describing a real environment.

Focus area
Cloud security and service operations on Azure
Setting
Small team operating a customer-facing application and its data on a public cloud platform
Method
Likelihood and impact register with inherent and residual scoring

Scope

This assessment covers a small team's use of Azure cloud services to host a customer-facing application, store business and personal data, and manage identities, logs and backups. It covers confidentiality, integrity and availability of that data, plus the duties of the owning organization. Assumptions about region, regulation, workloads and team size are stated below and must be checked against any real environment. It does not give a formal security design or legal advice.

Context

The team runs a web application on Azure with a small group of administrators, developers and support staff. Business records and some personal data are held in managed databases and file storage. Identities are managed centrally, activity logs are kept in the platform, and backups run daily. A cloud supplier and a software vendor each provide part of the service. Each risk is scored before controls to show its natural level, then again after existing controls and the controls that should be added.

Objectives, assets and stakeholders

The objective is to keep customer and business data confidential, accurate and available, to keep cloud services running within agreed recovery times, and to meet the privacy and contract duties the team owes. The assets in scope are the Azure subscription and its identities, data stores, virtual networks, application services, backups, logs and configuration records. Stakeholders include customers whose data is held, staff who build and run the service, the data protection lead, the cloud and software suppliers, and the management team and board. Every risk has one owner role, and the security lead keeps the register current and reports to management 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 Likelihood 4, impact 4, score 16, high: H01
3 Possible Likelihood 3, impact 3, score 9, medium: H05 H07 Likelihood 3, impact 4, score 12, high: H02 H06 Likelihood 3, impact 5, score 15, high: H08
2 Unlikely Likelihood 2, impact 4, score 8, medium: H04
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: H02 H03 H04 H06 Likelihood 2, impact 4, score 8, medium: H01 H08
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 Unauthorized access through identity compromise 16 High 8 Medium Security lead
H02 Misconfigured storage exposing data 12 High 6 Medium Cloud platform administrator
H03 Phishing and malware on user devices 12 High 6 Medium IT operations manager
H04 Insider misuse or accidental deletion 8 Medium 6 Medium Service owner
H05 Third-party and shared responsibility gaps 9 Medium 4 Low Service owner
H06 Service outage and failed recovery 12 High 6 Medium Operations manager
H07 Logging gaps delaying incident response 9 Medium 4 Low Security lead
H08 Privacy and compliance duties for personal data 15 High 8 Medium Data protection lead
H01

Unauthorized access through identity compromise

Technology and data Before 16 After 8

Stolen or guessed passwords, over-broad administrator roles or unused accounts let an outsider or a former worker sign in to the subscription and read or change resources, which can then spread to stored data.

Who or what is affected: Customers, staff and the service owner

Causes

Shared administrator accounts, password reuse and roles granted for convenience and never removed.

Consequences

Data theft, altered configurations, service takeover and loss of customer trust.

Existing controls

  • Administrator accounts use multi-factor sign in.
  • Role assignments are reviewed when staff change jobs.

Control gaps

Reviews happen only at staff changes, and service accounts are not covered by multi-factor sign in.

Additional controls

  • Prevent: Apply least privilege roles and conditional access rules to all administrator sign ins.
  • Detect: Alert on sign ins from unfamiliar locations and on every change to role assignments.
Likelihood 4 x impact 4 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: Privileged role assignments added outside the approved change process.
H02

Misconfigured storage exposing data

Technology and data Before 12 After 6

A storage container, database or network rule is left open to the public internet or to a wider group than intended, so personal or business records can be read without any sign in.

Who or what is affected: Data subjects, customers and the data owner

Causes

Manual changes made under pressure, copied templates and missing review of network rules.

Consequences

Breach of confidentiality, notification duties, possible penalties and reputational harm.

Existing controls

  • Storage accounts are created from a standard template.
  • Public access is turned off by default for new storage.

Control gaps

Configuration drift is not checked after deployment, so manual changes go unseen.

Additional controls

  • Prevent: Block public network access to data stores unless a named owner approves a documented exception.
  • Recover: Rotate access keys and review access logs after any suspected exposure.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Cloud platform administrator Target: Within 45 days Early warning: A data store with public access enabled that is not on the approved exception list.
H03

Phishing and malware on user devices

Technology and data Before 12 After 6

Staff are tricked into entering credentials on a fake sign in page or open a malicious file, giving an attacker a foothold to reach cloud resources and the data they hold.

Who or what is affected: Staff, administrators and customers

Causes

Convincing lures, unpatched devices and staff rushing through approval requests.

Consequences

Credential theft, ransomware, data loss and service downtime.

Existing controls

  • Endpoints run managed anti-malware with automatic updates.
  • Email filtering blocks known malicious attachments.

Control gaps

Filters miss new lures, and staff have little practice reporting suspicious messages.

Additional controls

  • Prevent: Use phishing resistant sign in methods for administrators and block legacy sign in protocols.
  • Detect: Investigate unusual mailbox forwarding rules and repeated failed sign ins promptly.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: IT operations manager Target: Within 30 days Early warning: A rise in reported suspicious emails or new inbox forwarding rules.
H04

Insider misuse or accidental deletion

People Before 8 After 6

A staff member deletes resources, copies data out of the environment or changes settings without approval, either by mistake or on purpose, and the change is not caught in time.

Who or what is affected: Colleagues, customers and the data owner

Causes

Limited training, pressure to fix problems quickly and unclear rules on who may approve changes.

Consequences

Lost data, outages, disputes and possible breach of professional duty.

Existing controls

  • Staff sign ins are logged against named accounts.
  • Deletion of production resources needs a change ticket.

Control gaps

Locks are not applied to all data stores, and restores have not been rehearsed.

Additional controls

  • Prevent: Apply resource locks to production data and separate approval duties from deployment duties.
  • Respond: Restore deleted resources from backup under the recovery runbook.
Likelihood 2 x impact 4 before; 2 x 3 after Owner: Service owner Target: Within 60 days Early warning: Bulk deletion or export events recorded outside working hours.
H05

Third-party and shared responsibility gaps

Supplier Before 9 After 4

The team assumes the cloud provider or a software vendor covers a duty that actually sits with the team, such as patching, backup settings or access reviews, so the gap has no clear owner.

Who or what is affected: Service owner, customers and suppliers

Causes

An unclear split of duties, vendor features assumed to be fully secured and contracts that are not read closely.

Consequences

Unpatched components, unrecovered data and disputes over liability.

Existing controls

  • A shared responsibility summary is kept in the team wiki.
  • Supplier contracts list support hours and service levels.

Control gaps

The responsibility summary is not checked against the actual setup of each service.

Additional controls

  • Prevent: Record who owns each control for every service before it goes live.
  • Detect: Review supplier service notices and contract terms each quarter.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Service owner Target: Within 90 days Early warning: A service in production with no named control owner.
H06

Service outage and failed recovery

Operational Before 12 After 6

A regional fault, a faulty update or a misconfigured network stops the application, and backups or failover have never been tested, so the service stays down longer than the business can accept.

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

Causes

Single region dependency, untested backups and changes made without a rollback plan.

Consequences

Lost revenue, missed deadlines, damaged reputation and possible data loss.

Existing controls

  • Data is backed up on a daily schedule.
  • Key services run across more than one availability zone.

Control gaps

Restores are checked only on paper and recovery time targets are not set.

Additional controls

  • Prevent: Test changes in a non production environment and keep a rollback plan for each release.
  • Recover: Rehearse restoring the application and its data within the agreed recovery time each quarter.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Operations manager Target: Within 60 days Early warning: Backup jobs failing or restore tests not completed on schedule.
H07

Logging gaps delaying incident response

Technology and data Before 9 After 4

Logs are not collected, kept or reviewed, so an intrusion or misconfiguration goes unnoticed for longer, and responders cannot reconstruct what happened.

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

Causes

Logs kept for short periods, alerts that are not tuned and no one assigned to watch them.

Consequences

Longer attacker dwell time, weak evidence and slower notification.

Existing controls

  • Activity logs are turned on for the main subscription.
  • An on call contact list is kept for incidents.

Control gaps

Log retention is not set, and incident playbooks have not been exercised.

Additional controls

  • Detect: Send security logs to a central store and set alerts for high risk events.
  • Respond: Run a short incident playbook with named roles, steps and a record of decisions.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security lead Target: Within 45 days Early warning: Log sources that have stopped sending data for more than one day.
H08

Privacy and compliance duties for personal data

Legal and compliance Before 15 After 8

Personal data is kept longer than needed, copied to another location without a record, or accessed without a documented lawful basis, so the team breaches duties it may not know apply.

Who or what is affected: Individuals whose data is held, the data protection lead and the organization

Causes

Unclear data ownership, copies made for testing and no written retention schedule.

Consequences

Regulatory action, compensation claims, forced deletion and loss of customer trust.

Existing controls

  • A data inventory lists the main personal data sets.
  • Privacy notices are published for customers.

Control gaps

The inventory is not linked to live resources, so new data stores go unrecorded.

Additional controls

  • Prevent: Set data location and retention rules in the platform and document the lawful basis for each data set.
  • Detect: Review the data inventory each quarter and check for unexpected copies of personal data.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Data protection lead Target: Within 90 days Early warning: A new data store holding personal data with no entry in the inventory.

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 Insignificant to 5 Severe, covering data harm, downtime, legal exposure, cost and trust. Multiplying the two gives a score from 1 to 25, which falls into 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 the score before any controls, and residual risk is the score after existing and added controls. A residual score must never be higher than the inherent score, and any inherent score of 10 or more must fall after controls. Critical items need immediate senior attention, High items need a dated plan, Medium items need routine controls with a named owner, and Low items are accepted and watched. Ratings are challenged by the people who run the services, by a peer reviewer, and whenever a warning indicator reaches its threshold. Scores guide the order of work and are not measurements.

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
Privileged role assignments added outside the approved change process.Escalate to the security lead within one working day, and suspend the role until the change is approved.
Data stores with public network access enabled that are not on the approved exception list.Escalate to the cloud platform administrator at once, and to the service owner if still open after 24 hours.
Backup jobs failing or restore tests not completed on schedule.Escalate to the operations manager after one missed job, and to the IT manager if two restore tests are missed in a row.
Log sources that have stopped sending data for more than one day.Escalate to the security lead when a source is silent for a day, and to the IT manager if it stays silent for three days.
Personal data stores found without an inventory entry.Escalate to the data protection lead within five working days, and pause new copies of that data until the entry is made.

Contingency arrangements

If a serious event occurs, such as confirmed account takeover, public exposure of data or a prolonged outage, the security lead isolates the affected identities and resources and preserves logs. The service owner decides whether to pause the application and informs management. The operations manager restores service from the latest tested backup within the agreed recovery time. The data protection lead assesses any notification duty and passes it to qualified legal advisers in the relevant jurisdiction. Customers and staff receive plain, early updates.

Prioritized action plan

  1. Turn on phishing resistant multi-factor sign in for all administrators, owner security lead, within 30 days.
  2. Block public access to data stores by default and review existing exceptions, owner cloud platform administrator, within 45 days.
  3. Write a shared responsibility matrix for each service and confirm it with suppliers, owner service owner, within 90 days.
  4. Centralize security logs with set retention and test one restore and one incident playbook, owner operations manager, within 60 days.
  5. Update the personal data inventory and set retention rules for each data set, owner data protection lead, within 90 days.

Conclusion

Secure cloud operation rests on a few steady habits: strong sign in for administrators, private data by default, a written split of duties with each supplier, logs that are kept and read, and restores that are rehearsed. The highest scores sit with identity compromise and misconfiguration, and each has actions that lower the residual score. Treat the register as a living record, review it on the stated cycle and after any incident, and seek qualified advice for any real security, privacy or contract question.

Assumptions and limitations

Assumptions

  • The team runs one production subscription and a test environment in a single named region, which is an assumption for teaching.
  • Jurisdiction and applicable privacy rules are not specified, so legal duties are described only in general terms.
  • Staff use managed devices and a common email service, and administrator accounts are few in number.

Limitations

  • Scores are examples for learning and do not describe any real environment or provider configuration.
  • Cybersecurity and privacy are regulated fields, so specialist review is needed before any real decision.
  • This is educational content and does not replace a formal site-specific assessment or licensed advice.

Related frameworks to study

  • Confidentiality, integrity and availability model
  • Least privilege and zero trust access principles
  • Shared responsibility model for cloud services
  • Hierarchy of controls

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.

Azure Cloud Fundamentals course Read the best practices for this course

More Technical risk assessments

Hourly Active: 39,047 Learners