vaayaa Inclusive Education
Technical risk assessment

Cloud Architecture Planning Risk Assessment: Misconfiguration, Identity and Recovery Controls

A worked example of how a planning team finds, scores and controls the risks in a cloud platform design, from misconfigured storage and stolen credentials to outages, weak logging and privacy duties.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Cloud Architecture Planning course

Executive summary

This assessment shows how a planning team can find, rate and control the risks in a cloud platform design before it is built. Eight risks were chosen because they are plausible in everyday cloud work, from misconfigured storage and stolen identities to supplier dependence, untested recovery and privacy duties. Identity compromise and public exposure of data carry the highest inherent scores, and both fall sharply once policy checks, short-lived credentials and monitoring are in place. Untested recovery and supplier lock-in remain the main planning gaps because they depend on testing and contract choices rather than settings. The first actions are policy as code for storage and network rules, multi-factor sign in with short-lived credentials, and a tested restore. The platform is a teaching example, so each score illustrates the method, not a real organization.

Focus area
Cloud architecture planning
Setting
Planning of a cloud-hosted application platform for a mid-sized organization that stores customer data
Method
Likelihood and impact register with inherent and residual scoring

Scope

This assessment covers the planning of a cloud platform that hosts a customer-facing application, including its data stores, identity services, network design, logging, backup and third-party services. It covers design decisions made before and during build. It does not cover application code quality, physical data centers or any real provider contract. Provider, jurisdiction, data volumes and team size are assumptions made for teaching.

Context

The planned platform runs in one public cloud provider across two regions, with a container service, managed databases, object storage and a content delivery layer. Engineers deploy through infrastructure as code and a shared pipeline. A small platform team, an application team and a security function share responsibility for the design. Each risk is scored before controls to show its natural level, then again after the existing controls and the additional controls proposed here.

Objectives, assets and stakeholders

The objective is to design a cloud platform that keeps customer data confidential, accurate and available, meets privacy and contractual duties, and can be recovered within agreed limits. The assets in scope are customer data in databases and object storage, identity and access settings, infrastructure templates, logs, backups, and the application itself. Stakeholders include platform engineers, the application team, the security function, the data protection lead, customers, the procurement team and the provider. Each risk has one owner role. The cloud platform lead keeps the register current and reports to the technology steering group each quarter, and the design is revisited whenever a major new service is proposed.

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 4, score 16, high: H01 Likelihood 4, impact 5, score 20, critical: H02
3 Possible Likelihood 3, impact 3, score 9, medium: H07 Likelihood 3, impact 4, score 12, high: H03 H04 H08 Likelihood 3, impact 5, score 15, high: H05
2 Unlikely Likelihood 2, impact 5, score 10, high: H06
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: H07 Likelihood 2, impact 3, score 6, medium: H01 H03 H04 H05 H06 H08 Likelihood 2, impact 4, score 8, medium: H02
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 Misconfigured storage and network exposure 16 High 6 Medium Cloud platform lead
H02 Identity compromise and excessive privileges 20 Critical 8 Medium Identity and access manager
H03 Malware and phishing against workloads and staff 12 High 6 Medium Security engineer
H04 Third-party outage and supplier lock-in 12 High 6 Medium Supplier manager
H05 Service disruption without tested recovery 15 High 6 Medium Site reliability lead
H06 Insider misuse and unmonitored administrative actions 10 High 6 Medium People and security manager
H07 Logging gaps delaying incident response 9 Medium 4 Low Security operations lead
H08 Privacy and data residency non-compliance 12 High 6 Medium Data protection lead
H01

Misconfigured storage and network exposure

Technology and data Before 16 After 6

Object storage buckets, database endpoints or management ports are left open to the public internet because default settings were not reviewed, so data can be read or changed by outsiders.

Who or what is affected: Customers, platform engineers and the data protection lead

Causes

Copied templates, manual console changes and defaults that were never reviewed.

Consequences

Customer data exposure, reportable privacy incident and loss of customer trust.

Existing controls

  • Infrastructure templates set private networking as the default.
  • A provider tool scans for public storage buckets each week.

Control gaps

Manual changes in the console are not checked against the approved design.

Additional controls

  • Prevent: Enforce policy as code that blocks public storage and open management ports before any deployment.
  • Detect: Run continuous configuration checks and alert the platform team on any new public endpoint.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Cloud platform lead Target: Within 30 days Early warning: Any new storage bucket or network rule that allows access from all addresses.
H02

Identity compromise and excessive privileges

Technology and data Before 20 After 8

Stolen passwords, long-lived access keys or roles with broad permissions let an attacker move between services, read sensitive data or change the platform configuration.

Who or what is affected: All platform users, customers whose data is held and the security lead

Causes

Shared administrator accounts, keys stored in code and roles granted for convenience.

Consequences

Data theft, unauthorized changes to production and long recovery time.

Existing controls

  • Single sign on is used for all engineers.
  • Administrative roles are assigned by the platform lead.

Control gaps

Role permissions are rarely reviewed after a project ends.

Additional controls

  • Prevent: Require multi-factor sign in and replace long-lived access keys with short-lived role credentials.
  • Detect: Review privileged role use each month and alert on unusual sign in locations or times.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Identity and access manager Target: Within 30 days Early warning: A privileged role used from an unknown location or an access key older than the agreed maximum age.
H03

Malware and phishing against workloads and staff

Technology and data Before 12 After 6

A phishing email or a vulnerable container image gives an attacker a foothold in a workload, where malware can collect data, mine resources or pivot to other services.

Who or what is affected: Platform engineers, application users and the security function

Causes

Outdated base images, unpatched libraries and email lures aimed at engineers with production access.

Consequences

Data loss, service degradation, unexpected cost and a costly rebuild.

Existing controls

  • Container images come from an approved internal registry.
  • Staff complete a phishing awareness module when they join.

Control gaps

Scanning covers new images but not images already running in production.

Additional controls

  • Prevent: Scan images for known vulnerabilities before they are deployed and block images that fail the scan.
  • Respond: Isolate a suspect workload, rotate its credentials and rebuild it from a clean image.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Security engineer Target: Within 45 days Early warning: A workload that makes unusual outbound connections or sudden spikes in compute use.
H04

Third-party outage and supplier lock-in

Supplier Before 12 After 6

A managed service, a software vendor or the provider itself fails or changes terms, so the platform cannot run, or moving to another supplier becomes slow and expensive.

Who or what is affected: Customers, the application team and procurement

Causes

Heavy use of one provider, proprietary services and contract terms that are hard to change.

Consequences

Extended outage, high migration cost and weaker negotiating position.

Existing controls

  • Contracts include a stated uptime target and a service credit route.
  • Key services are listed in a supplier register.

Control gaps

The exit plan has not been tested against a realistic data volume.

Additional controls

  • Prevent: Prefer open formats and portable container images, and document which services are provider specific.
  • Recover: Keep a tested exit plan for the database and storage layers with a named supplier fallback.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Supplier manager Target: Within 90 days Early warning: A supplier notice of service change, price change or reduced support for a key service.
H05

Service disruption without tested recovery

Operational Before 15 After 6

A zone failure, a faulty deployment or a corrupted database stops the application, and recovery takes longer than the business can accept because backups and failover have not been tested.

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

Causes

Single points of failure, untested restores and deployments made without a rollback path.

Consequences

Lost sales, breached service agreements and damage to reputation.

Existing controls

  • Databases take automated daily backups.
  • Workloads are spread across two availability zones.

Control gaps

Restores have been tested on small data sets only.

Additional controls

  • Prevent: Use staged rollouts and automatic rollback so a faulty release reaches only part of the platform.
  • Recover: Test a full restore and regional failover each quarter and record the measured recovery time.
Likelihood 3 x impact 5 before; 2 x 3 after Owner: Site reliability lead Target: Within 60 days Early warning: A failed restore test or a recovery time that exceeds the agreed objective.
H06

Insider misuse and unmonitored administrative actions

People Before 10 After 6

A staff member or contractor with administrative access copies data, disables controls or changes settings for personal gain or through carelessness, and no one sees it in time.

Who or what is affected: Customers, colleagues and the people manager

Causes

Broad access granted to a few people, weak separation of duties and time pressure.

Consequences

Data theft, sabotage, disciplinary action and loss of customer trust.

Existing controls

  • Background checks are required for staff with production access.
  • Administrative actions are written to an audit log.

Control gaps

Audit logs are stored but nobody reviews them on a fixed schedule.

Additional controls

  • Prevent: Require two person approval for changes to logging, encryption and identity settings.
  • Detect: Review administrator activity each month against the approved change record.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: People and security manager Target: Within 60 days Early warning: A change to logging or encryption settings without an approved change record.
H07

Logging gaps delaying incident response

Operational Before 9 After 4

Logs are missing, incomplete or stored with short retention, so the team cannot tell what happened during an incident or contain it quickly.

Who or what is affected: Incident responders, the security lead and affected customers

Causes

Services added without logging, debug output turned off and retention set to the lowest default.

Consequences

Slow investigation, longer exposure and weak evidence for regulators or customers.

Existing controls

  • Core provider activity logs are switched on.
  • An on call rota covers alerts from production.

Control gaps

Application logs are not collected in the central store.

Additional controls

  • Prevent: Standardize log collection for every service and set a minimum retention period in the design standard.
  • Respond: Write and rehearse a short incident playbook that names the first actions and who makes each call.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security operations lead Target: Within 45 days Early warning: A production service that sends no logs for more than an agreed period.
H08

Privacy and data residency non-compliance

Legal and compliance Before 12 After 6

Personal data is stored, copied or processed in a region or by a service that does not match the privacy commitments made to customers, and the required records and notices are missing.

Who or what is affected: Customers, the data protection lead and the legal team

Causes

Backups copied to other regions, analytics tools added without review and unclear ownership of personal data.

Consequences

Regulatory investigation, fines where applicable, and loss of customer confidence.

Existing controls

  • A data inventory lists the main personal data stores.
  • Customer data is encrypted at rest with provider managed keys.

Control gaps

The inventory is not updated when new services are added.

Additional controls

  • Prevent: Restrict data stores to approved regions in policy and review new services against the data inventory before use.
  • Detect: Compare the data inventory with actual storage locations each quarter and log any gap.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Data protection lead Target: Within 90 days Early warning: A new personal data store that is not recorded in the data 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, minor, to 5, severe. Multiplying the two gives a score from 1 to 25 in one of four bands. Low covers scores from 1 to 4 and needs routine checks only. Medium covers 5 to 9 and needs a named owner and a scheduled review. High covers 10 to 16 and needs a dated plan approved by the platform lead. Critical covers 17 to 25 and must be fixed or formally accepted by the technology steering group before go live. Inherent risk is the score before any controls, based on the design as first drawn. Residual risk is the score after existing and additional controls are applied. Residual scores must never be higher than inherent scores, and a risk that starts at 10 or more must end lower. Impact is judged on customer harm, data loss, recovery time, legal exposure and cost. Ratings are challenged in a short review where the security lead and an engineer from another team must agree or record a different view. Any indicator that reaches its threshold triggers a fresh rating, so the scores stay honest as the platform changes.

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
Storage buckets or network rules that allow access from all addresses.Escalate to the cloud platform lead at once for any new public exposure, and to the technology steering group if it remains open after 24 hours.
Privileged roles used from unknown locations or access keys older than the agreed maximum age.Escalate to the identity and access manager immediately, and suspend the credential until its owner confirms the use.
Failed restore tests or measured recovery times above the agreed objective.Escalate to the site reliability lead at once, and to the technology steering group if the objective is missed twice in a row.
Production services that send no logs for more than the agreed period.Escalate to the security operations lead within one hour, and to the cloud platform lead if the gap continues for a day.
Personal data stores that are not recorded in the data inventory.Escalate to the data protection lead within five working days, and to legal counsel if personal data has left the approved regions.

Contingency arrangements

If a serious event occurs, such as confirmed data exposure, a compromised administrator account or a regional outage, the incident lead opens the response playbook and freezes non-essential changes. The security operations lead isolates affected accounts and workloads and preserves logs. The cloud platform lead fails traffic over to the standby region or restores from the latest tested backup. The data protection lead assesses any notification duty under the applicable law, and legal counsel approves external statements. Customers and staff receive plain, timely updates.

Prioritized action plan

  1. Enforce policy as code that blocks public storage and open management ports, owner cloud platform lead, within 30 days.
  2. Require multi-factor sign in and replace long-lived access keys with short-lived role credentials, owner identity and access manager, within 30 days.
  3. Run a full restore and regional failover test and record the measured recovery time, owner site reliability lead, within 60 days.
  4. Standardize log collection and retention for every service, owner security operations lead, within 45 days.
  5. Document a tested exit plan for key managed services and review supplier terms, owner supplier manager, within 90 days.

Conclusion

A sound cloud design depends on a few steady habits: policy checks before deployment, short-lived credentials, central logging, tested recovery and a clear record of where personal data lives. The highest scores sit with identity compromise and public data exposure, and both respond well to preventive controls. Untested recovery and supplier dependence need planning time and budget rather than configuration alone. Treat the register as a living record, review it every six months or after any major change, and seek qualified security, legal and engineering advice for any real platform decision.

Assumptions and limitations

Assumptions

  • The provider and region choices are not specified, so provider features are described only in general terms.
  • The platform holds personal data from customers, so privacy duties apply, but the jurisdiction is assumed for teaching.
  • Teams use infrastructure as code and a managed identity service with multi-factor sign in available.

Limitations

  • The scores are examples for learning and do not describe any real platform or provider.
  • Cloud services, security settings and privacy laws change often, so specialist review is needed before any build decision.
  • This is educational content and is not legal, security or professional engineering advice.

Related frameworks to study

  • Shared responsibility model between the provider and the customer
  • Least privilege access principle
  • Defense in depth with layered controls
  • Business continuity planning with recovery time and recovery point objectives
  • Threat modeling using a structured method such as STRIDE

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 Architecture Planning course Read the best practices for this course

More Technical risk assessments

Hourly Active: 39,499 Learners