vaayaa Inclusive Education
Technical risk assessment

Google Cloud Platform Basics Risk Assessment: Misconfiguration, Access and Recovery Controls

A worked example showing how a small team learning a public cloud platform finds, scores and controls risks to data, identities, services and compliance, from misconfiguration and phishing to outages and weak logging.

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

Executive summary

This assessment shows how a small team learning a public cloud platform can find, rate and control the risks that matter most to its data, identities and services. Eight risks were chosen because they are plausible in early cloud work, from misconfigured storage and over-privileged accounts to outages, weak logging and privacy duties. Misconfiguration and excessive access carry the highest inherent scores, because a single mistake can expose many records. Each risk is scored before controls and again after existing and additional controls. Most risks fall to Low or Medium once the added controls are in place, but account compromise and outage recovery stay at Medium while recovery is untested. The first actions are organization-wide public access prevention, narrower roles, phishing resistant sign in and a rehearsed restore. The example is for teaching and every score illustrates the method, not a real environment.

Focus area
Cloud platform fundamentals, identity, data protection and operations
Setting
Small technical team using a public cloud platform for storage, managed databases, virtual machines and an internal reporting application
Method
Five by five likelihood and impact register with inherent and residual scoring

Scope

This assessment covers a small team's first use of a public cloud platform, including projects, identity and access, object storage, virtual machines, managed databases, network settings, logging and incident response. It does not cover any real tenant, contract or live environment. Jurisdiction, data types, budget and regional placement are assumptions made for teaching and are labelled as such in the assumptions list.

Context

The team has six engineers, a team lead, a named security champion, a finance approver and one shared administrator account used during early setup. Customer records sit in a managed database, uploaded files are stored in object storage, and a reporting web application runs on virtual machines. Code is deployed through an automated pipeline that uses service accounts. Each risk is scored before controls to show its natural level, then again after the existing controls and the additional controls that should be added. Ratings are a teaching device and should be revisited whenever the platform configuration or the team changes.

Objectives, assets and stakeholders

The objective is to run cloud services that keep data confidential, accurate and available, meet privacy and contractual duties, and allow the team to recover quickly when something goes wrong. The assets in scope are customer records in the managed database, uploaded files in object storage, the virtual machines and application code, deployment pipeline credentials, audit logs and the backups that protect them. Stakeholders include the engineers, the team lead, the security champion, the finance approver, customers whose data is held, and any auditor or regulator who may ask for evidence. Every risk has one owner role, and the team lead reviews the register with the whole team after each review trigger.

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: H05 H06 Likelihood 3, impact 4, score 12, high: H03 H08
2 Unlikely Likelihood 2, impact 4, score 8, medium: H04 H07
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 Likelihood 2, impact 3, score 6, medium: H01 H03 H06 H07 H08 Likelihood 2, impact 4, score 8, medium: H02
1 Rare Likelihood 1, impact 3, score 3, low: H04
  • 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 exposing data publicly 16 High 6 Medium Cloud platform lead
H02 Over-privileged accounts and service keys 20 Critical 8 Medium Identity and access administrator
H03 Phishing and account credential theft 12 High 6 Medium Security champion
H04 Accidental deletion or insider misuse 8 Medium 3 Low Team lead
H05 Weak logging delaying incident detection 9 Medium 4 Low Security champion
H06 Third-party components and supplier dependency 9 Medium 6 Medium Development lead
H07 Service outage and failed recovery 8 Medium 6 Medium Operations lead
H08 Privacy and data residency breaches 12 High 6 Medium Privacy lead
H01

Misconfigured storage exposing data publicly

Technology and data Before 16 After 6

An object storage bucket or dataset is left readable by anyone with the link or by all users, so files containing customer details can be viewed or downloaded outside the team.

Who or what is affected: Customers, staff and the team that owns the data

Causes

Default settings copied from tutorials, rushed setup and unclear ownership of buckets.

Consequences

Disclosure of personal data, breach notice duties, loss of customer trust and remediation cost.

Existing controls

  • Buckets are created in the development project only by default.
  • Staff are told to review sharing settings before publishing a file.

Control gaps

Scans run only when someone remembers, and new projects inherit no organization-wide restriction.

Additional controls

  • Prevent: Enforce public access prevention at the organization level and block public sharing of buckets holding personal data.
  • Detect: Run a scheduled configuration scan and alert when any bucket becomes readable by public principals.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Cloud platform lead Target: Within 30 days Early warning: Any storage bucket with a public or allUsers access entry appears in a configuration report.
H02

Over-privileged accounts and service keys

Technology and data Before 20 After 8

Users and automated service accounts hold broad roles such as owner or editor, or long-lived keys are stored in code, so a single compromise can reach many resources.

Who or what is affected: Team members, customers whose data is reachable and the platform owner

Causes

Speed of early setup, unclear role design and keys copied into repositories.

Consequences

Wide data access, resource abuse, costly misuse and difficult containment.

Existing controls

  • Identity access management roles are assigned by the team lead.
  • Service accounts are named by purpose in the project.

Control gaps

Access is granted but never reviewed, and no one tracks which keys are still active.

Additional controls

  • Prevent: Replace broad roles with narrow predefined roles and remove owner rights from daily accounts.
  • Prevent: Stop creating long-lived service account keys and use short-lived credentials from the pipeline.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Identity and access administrator Target: Within 30 days Early warning: A new owner or editor role grant, or a service account key created outside the approved process.
H03

Phishing and account credential theft

Technology and data Before 12 After 6

A staff member is tricked into giving up a password or approving a sign in prompt, letting an attacker reach the console, the mail account or the deployment pipeline.

Who or what is affected: All staff with platform access and the customers whose data is stored

Causes

Urgent requests that look genuine, reused passwords and approval prompts accepted without thought.

Consequences

Unauthorized access, data theft, malicious deployments and a costly clean up.

Existing controls

  • Staff use company email with spam filtering.
  • Passwords must meet a minimum length set by the team.

Control gaps

Multi-factor sign in is not yet enforced for every account, and reporting is informal.

Additional controls

  • Prevent: Require phishing resistant multi-factor sign in for every administrator and developer account.
  • Respond: Run a short procedure to revoke sessions and rotate credentials when a phishing report is received.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Security champion Target: Within 30 days Early warning: Repeated sign in alerts from unfamiliar locations or staff reporting unexpected approval prompts.
H04

Accidental deletion or insider misuse

People Before 8 After 3

A team member deletes a database, disk or project by mistake, or misuses access to read records they do not need, causing outages or privacy breaches.

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

Causes

Hurried commands, unclear environment labels and access that is wider than the job needs.

Consequences

Data loss, service downtime, privacy complaints and loss of trust within the team.

Existing controls

  • Production changes are discussed in a team channel before release.
  • Database backups run every night.

Control gaps

Deletion protection is not switched on for every resource and log reviews are not scheduled.

Additional controls

  • Prevent: Add deletion protection to production databases and disks and require a second approver for project deletion.
  • Detect: Review audit logs of data access for production records each month and investigate unusual reads.
Likelihood 2 x impact 4 before; 1 x 3 after Owner: Team lead Target: Within 60 days Early warning: A delete or disable action on a production resource, or a spike in reads of personal records by one user.
H05

Weak logging delaying incident detection

Operational Before 9 After 4

Audit and access logs are not enabled, retained or reviewed, so suspicious activity is noticed late or cannot be proven, and the team cannot tell what an attacker reached.

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

Causes

Logging is optional on some services, costs are unclear and no one owns log review.

Consequences

Late detection, weak evidence, longer outages and difficulty meeting breach reporting duties.

Existing controls

  • Administrative activity logs are enabled in the main project.
  • Application logs are kept by the reporting web application for a short time.

Control gaps

Data access logs are off by default and retention is not defined.

Additional controls

  • Detect: Enable data access logs for storage and databases and forward them to a central, protected store.
  • Respond: Write a short incident runbook that names who reads alerts and how evidence is preserved.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security champion Target: Within 45 days Early warning: Logging is disabled on a production project or a log source has been silent for more than a day.
H06

Third-party components and supplier dependency

Supplier Before 9 After 6

The team relies on open source libraries, marketplace images and a managed service provider whose updates, licences or security issues could affect the application without warning.

Who or what is affected: Application users, the development team and the procurement owner

Causes

Fast adoption of libraries, pinned versions that age and limited review of licence terms.

Consequences

Exploitable flaws, forced emergency upgrades, licence disputes and service interruption.

Existing controls

  • Dependencies are pinned to versions in the build file.
  • Images are taken only from the official catalogue.

Control gaps

Scans are not part of the release process and supplier contracts are not reviewed.

Additional controls

  • Prevent: Scan dependencies and images for known vulnerabilities before each release and block builds that fail.
  • Respond: Keep a list of third-party services with contacts and a plan to replace each one if it fails.
Likelihood 3 x impact 3 before; 2 x 3 after Owner: Development lead Target: Within 60 days Early warning: A scan reports a high severity flaw in a component used in production.
H07

Service outage and failed recovery

Operational Before 8 After 6

A regional fault, a bad configuration change or a corrupted database stops the application, and restore steps have never been tested, so recovery takes longer than users can tolerate.

Who or what is affected: Users of the reporting application, the operations team and the business owner

Causes

Single region deployment, untested restore steps and changes made without review.

Consequences

Extended downtime, data gaps, missed deadlines and unhappy customers.

Existing controls

  • Nightly backups of the managed database are kept.
  • Virtual machines are rebuilt from a stored template.

Control gaps

No recovery time target is set and restores have never been rehearsed.

Additional controls

  • Recover: Test a full restore of the database into a separate project each quarter and record the time taken.
  • Prevent: Route production changes through a reviewed change process with a rollback step written in advance.
Likelihood 2 x impact 4 before; 2 x 3 after Owner: Operations lead Target: Within 90 days Early warning: A restore test takes longer than the agreed recovery time, or a backup job fails twice in a week.
H08

Privacy and data residency breaches

Legal and compliance Before 12 After 6

Personal data is stored in a region, kept for longer than needed or shared with a third party without the right agreement, so the team may breach privacy duties that apply in its jurisdiction.

Who or what is affected: Data subjects, the privacy lead and the business owner

Causes

Unclear residency rules, copies of data made for testing and no retention schedule.

Consequences

Regulatory complaints, forced deletion, reputational harm and costly notification.

Existing controls

  • Personal data fields are listed in a simple data inventory.
  • Customer sign up notices state that data is stored in the cloud.

Control gaps

Testing copies are not inventoried and no retention rule is written down.

Additional controls

  • Prevent: Choose storage regions that match the stated residency rule and block creation of resources elsewhere.
  • Detect: Review the data inventory each quarter for retention periods that have passed and purge data that is no longer needed.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Privacy lead Target: Within 90 days Early warning: A new resource created outside the approved region or a dataset held past its retention date.

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, covering data exposure, downtime, cost and trust. 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 measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and additional controls, and it must never be higher than the inherent score. Anything still High or Critical needs senior attention and a dated plan, anything Medium needs routine controls with a named owner, and anything Low is accepted and watched. Ratings are challenged by the engineers who run the platform, by a peer reviewer who did not write the entry, and by any new evidence such as a failed restore test or a scan result. A rating is lowered only when a control is in place and has been checked, not because it is planned.

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 datasets readable by public or all users.Escalate to the cloud platform lead at once when any public entry is found, and to the team lead if it is not removed within one day.
Owner or editor roles granted, or long-lived service account keys created.Escalate to the identity and access administrator on the same day, and revoke the grant or key unless approved in writing.
Failed multi-factor prompts or sign in alerts from unfamiliar locations.Escalate to the security champion within one hour, and start the credential revocation procedure if account compromise is suspected.
Restore test duration or backup job failures over a week.Escalate to the operations lead when a restore exceeds the recovery time target, and to the team lead if two backup jobs fail in one week.
Resources created outside approved regions or personal data held past its retention date.Escalate to the privacy lead within two working days, and to the team lead if the data cannot be removed or moved promptly.

Contingency arrangements

If a serious event occurs, such as an exposed bucket, a stolen credential or a failed production database, the team lead stops the affected pipeline, revokes the relevant sessions and keys, and preserves logs before any change is made. The security champion leads containment and records each step. The privacy lead decides whether a notice is needed under the rules that apply in the relevant jurisdiction. Service is restored from the latest tested backup, and customers and staff are told what they need to know early and plainly.

Prioritized action plan

  1. Enforce organization-wide public access prevention and scan for public buckets, owner cloud platform lead, within 30 days.
  2. Replace broad roles and stop creating long-lived service account keys, owner identity and access administrator, within 30 days.
  3. Require phishing resistant multi-factor sign in for all administrator and developer accounts, owner security champion, within 30 days.
  4. Test a full database restore into a separate project and record the time taken, owner operations lead, within 90 days.
  5. Enable data access logs and set retention periods for personal data, owner privacy lead, within 90 days.

Conclusion

Safe cloud work depends on a few steady habits: narrow roles, enforced multi-factor sign in, default private storage, logs kept and read, rehearsed restores and a clear list of data and its regions. The highest scores sit with misconfiguration and excessive access, and each has controls that lower the residual score. Treat the register as a living record, review it on the stated cycle, and seek qualified advice for any real security, privacy or legal question.

Assumptions and limitations

Assumptions

  • The team uses one organization account with separate projects for development and production.
  • Personal data is held in the cloud, but the jurisdiction of the users is not specified, so legal duties are described in general terms only.
  • Staff have basic administrative training and work on managed company devices.
  • Backup and log retention periods are set by the team, not by any regulator, and are assumed for teaching.

Limitations

  • Scores are illustrative and do not describe any real environment or provider configuration.
  • Cloud security settings and service features change over time, so current official documentation and specialist review are needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed security, privacy or legal advice.
  • The register does not test any system, so residual scores assume the stated controls operate as described.

Related frameworks to study

  • Shared responsibility model for cloud services
  • Least privilege access principle
  • Defense in depth with layered controls
  • Incident response lifecycle of prepare, detect, contain, recover and learn
  • Business continuity planning with recovery time and recovery point objectives
  • Privacy by design principles

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.

Google Cloud Platform Basics course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,661 Learners