vaayaa Inclusive Education
Technical risk assessment

Infrastructure as Code Risk Assessment: Identity, Configuration and Recovery Controls

A worked example of how a platform team finds, scores and controls the risks in managing cloud infrastructure through version-controlled code, from identity and misconfiguration to state, supply chain and recovery.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the Infrastructure as Code course

Executive summary

This assessment shows how a platform team can find, rate and control the risks that come with defining cloud infrastructure as code. Eight hazards were selected because they are plausible in everyday provisioning work, from pipeline identity and misconfigured storage to drifted state, unreviewed changes and weak recovery. Identity compromise carries the highest inherent score because one stolen credential can rebuild or expose an entire environment. Each risk is scored before controls and again after existing and added controls. Most fall to Medium or Low once controls are in place, but identity and recovery exposure remain worth close attention because the impact stays serious. The first actions are scoped deployment identities, policy checks before every apply, a locked and encrypted state store and a tested rebuild from code. The scores are teaching examples and do not describe any real environment.

Focus area
Infrastructure as code and cloud configuration management
Setting
Platform engineering team provisioning cloud infrastructure from version-controlled templates and an automated pipeline
Method
Five by five likelihood and impact risk register

Scope

This assessment covers the provisioning of cloud infrastructure from version-controlled code, including the repository, the pipeline that applies changes, the state store, the deployment identities and the running environment. It labels assumptions where the provider, jurisdiction and data types are not specified. It does not assess any real platform, provider contract or regulated workload, and it does not replace a formal site-specific review.

Context

The team has five engineers and a security lead who manage networks, compute, storage and databases for a customer-facing web service. Infrastructure is described in modules stored in a shared repository, reviewed through pull requests and applied by an automated pipeline. A remote state file records what has been built and is shared by the team. Some third-party modules and images are reused from public sources. Each risk is scored before controls to show its natural level, then again after the existing controls and the controls that should be added. Assumptions and limits are listed separately so the scoring can be followed.

Objectives, assets and stakeholders

The objective is to build and change infrastructure in a repeatable, reviewable way while keeping the service available, protecting customer data and meeting the duties the business owes. The assets in scope are cloud accounts and subscriptions, deployment identities and secrets, the code repository, the pipeline, the state file, the running services, stored customer data and the logs that record what happened. Stakeholders include the platform team, the security lead, the product owners who depend on the service, customers whose data is held, auditors or regulators where duties apply, and the authors of third-party modules that are reused. Each risk has one owner role, and the platform lead keeps the register current and reports 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
4 Likely Likelihood 4, impact 4, score 16, high: H02 Likelihood 4, impact 5, score 20, critical: H01
3 Possible Likelihood 3, impact 3, score 9, medium: H08 Likelihood 3, impact 4, score 12, high: H04 Likelihood 3, impact 5, score 15, high: H03
2 Unlikely Likelihood 2, impact 4, score 8, medium: H05 H06 Likelihood 2, impact 5, score 10, high: 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: H08 Likelihood 2, impact 3, score 6, medium: H02 H03 H04 H05 H07 Likelihood 2, impact 4, score 8, medium: H01
1 Rare Likelihood 1, impact 4, score 4, low: H06
  • 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 Compromised deployment identity or credentials 20 Critical 8 Medium Security lead
H02 Misconfigured storage and network rules 16 High 6 Medium Cloud operations lead
H03 Secrets and sensitive data held in code and state 15 High 6 Medium Security lead
H04 Third-party module and image supply chain 12 High 6 Medium Platform engineer
H05 State drift and failed applies causing outage 8 Medium 6 Medium Cloud operations lead
H06 Unreviewed change or insider misuse 8 Medium 4 Low Platform lead
H07 Recovery failure after loss of state or environment 10 High 6 Medium Site reliability lead
H08 Privacy and retention gaps in logs and test data 9 Medium 4 Low Privacy and compliance lead
H01

Compromised deployment identity or credentials

Technology and data Before 20 After 8

A deployment account or access key is stolen, phished or left in a shared place, and an attacker can change or delete infrastructure across the whole environment.

Who or what is affected: Platform team, customers whose data is held, the service owners

Causes

Long-lived access keys, shared service accounts and phishing of engineers who hold broad rights.

Consequences

Data theft, destruction of environments, ransom demands and loss of customer trust.

Existing controls

  • Multi-factor sign in is required for human accounts.
  • Keys are stored in a managed vault, not in code.

Control gaps

Some older keys were issued without expiry, and no one reviews where they are used.

Additional controls

  • Prevent: Scope each deployment identity to one environment and remove standing administrator rights.
  • Detect: Alert on sign ins and API calls from unfamiliar locations and on rights changes.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Security lead Target: Within 30 days Early warning: Sign in to a deployment identity from an unfamiliar network or at an unusual hour.
H02

Misconfigured storage and network rules

Technology and data Before 16 After 6

A module sets a storage bucket, database or firewall rule too widely, so data or management ports are reachable from the internet.

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

Causes

Copied example modules, time pressure and default settings that are left open.

Consequences

Exposed customer records, misuse of open services and a reportable incident.

Existing controls

  • Templates include default private settings for storage.
  • Peer review checks new network rules before merge.

Control gaps

Exceptions are approved in chat and not recorded, and daily scans cover only production.

Additional controls

  • Prevent: Add policy as code checks that reject public access unless a named exception is approved.
  • Detect: Scan running resources each day and compare them with the code.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Cloud operations lead Target: Within 45 days Early warning: Storage or network rules open to public access that the code does not permit.
H03

Secrets and sensitive data held in code and state

Technology and data Before 15 After 6

Passwords, tokens or personal data are written into templates, variables, logs or the state file, which is then copied, shared or kept in backups.

Who or what is affected: Platform team, repository users, customers

Causes

Quick fixes in templates, default values inside modules and state files that hold plain values.

Consequences

Unauthorized access, a compliance breach and emergency rotation across several services.

Existing controls

  • Secret scanning runs on commits to the main branch.
  • Sensitive variables are marked so they are hidden in pipeline logs.

Control gaps

State files are not encrypted at rest, and backups of them are not reviewed.

Additional controls

  • Prevent: Keep all secrets in a managed vault and reference them by name only.
  • Respond: Rotate any exposed secret at once and record the time taken to revoke it.
Likelihood 3 x impact 5 before; 2 x 3 after Owner: Security lead Target: Within 30 days Early warning: A secret found in a commit, build log or state file by the scanning tool.
H04

Third-party module and image supply chain

Supplier Before 12 After 6

Public or vendor modules, base images and plugins carry vulnerabilities, hidden behavior or changes that are pulled in automatically when a version is not pinned.

Who or what is affected: Platform team, customers, teams that reuse the modules

Causes

Unpinned versions, wide version ranges and modules copied without being read in full.

Consequences

Hidden access, vulnerable services, failed deployments and loss of confidence in the platform.

Existing controls

  • Only modules from an approved list are used.
  • Base images are updated on a regular schedule.

Control gaps

The approved list is not checked against what the code actually pulls in.

Additional controls

  • Prevent: Pin exact versions and checksums for every external module and image.
  • Detect: Review release notes and run vulnerability scans on images before each deployment.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Platform engineer Target: Within 60 days Early warning: A reused module or image changes version without a review record.
H05

State drift and failed applies causing outage

Operational Before 8 After 6

Changes made by hand or a partly failed apply leave the live environment different from the code, so the next apply deletes or breaks working services.

Who or what is affected: Service owners, customers, on-call staff

Causes

Urgent fixes made by hand, parallel applies and state that falls out of step with reality.

Consequences

Service outage, data loss on replacement and hours of manual repair.

Existing controls

  • The pipeline locks state during an apply.
  • Manual console changes are discouraged in the access policy.

Control gaps

Break glass use is not logged, and daily plan output is not read by anyone.

Additional controls

  • Prevent: Block manual changes to production except through a logged break glass route.
  • Detect: Run a scheduled plan each day and alert on any unexpected difference.
Likelihood 2 x impact 4 before; 2 x 3 after Owner: Cloud operations lead Target: Within 60 days Early warning: Drift between the deployed environment and the code, found in scheduled checks.
H06

Unreviewed change or insider misuse

People Before 8 After 4

A person with access merges or applies a change without review, or misuses rights to take data or disrupt services, whether by accident or on purpose.

Who or what is affected: Platform team, the employing business, customers

Causes

A small team, deadline pressure, shared trust and access rights that persist after a role changes.

Consequences

Unauthorized change, data theft, disciplinary action and damage to team trust.

Existing controls

  • Branch protection requires one approving review before merge.
  • Access to production is granted by role and every use is logged.

Control gaps

A reviewer from the author's own team can approve a change without an independent second check.

Additional controls

  • Prevent: Require two reviewers for production modules and separate the people who merge from those who apply.
  • Respond: Remove access at once when misuse is suspected and preserve the audit trail.
Likelihood 2 x impact 4 before; 1 x 4 after Owner: Platform lead Target: Within 30 days Early warning: Pipeline runs that apply changes without a second reviewer approval.
H07

Recovery failure after loss of state or environment

Operational Before 10 After 6

The state file is lost or corrupted, or an environment is deleted, and the team cannot rebuild the services from code and data backups within the time customers accept.

Who or what is affected: Customers, support staff, service owners

Causes

Untested recovery steps, missing import instructions and backups held in the same account as production.

Consequences

Extended outage, permanent data loss and breach of promised service levels.

Existing controls

  • State is stored remotely with versioning enabled.
  • Database backups run each night.

Control gaps

Backups have not been restored end to end, and no one owns the state recovery steps.

Additional controls

  • Recover: Rehearse a full rebuild in a separate account every quarter and record the time taken.
  • Prevent: Enable deletion protection on stateful resources and keep a copy of state in a second location.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: Site reliability lead Target: Within 90 days Early warning: A rebuild test that does not finish within the agreed recovery time.
H08

Privacy and retention gaps in logs and test data

Legal and compliance Before 9 After 4

Personal data is copied into test environments or logs, kept longer than needed or moved between regions without a documented basis, so duties owed to customers are not met.

Who or what is affected: Customers, the people whose data is held, the legal and compliance team

Causes

Convenience copies, unclear ownership of retention rules and logs that capture full request bodies.

Consequences

Regulator questions, customer complaints, fines where they apply and reputational harm.

Existing controls

  • Production data is not copied to test environments by default.
  • Retention periods are written in the service documentation.

Control gaps

Jurisdiction is not confirmed, so retention rules rest on assumptions that no one has checked.

Additional controls

  • Detect: Scan logs and test stores for personal data patterns each month and record the findings.
  • Respond: Delete or mask data found outside its permitted place and log the action taken.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Privacy and compliance lead Target: Within 90 days Early warning: Personal data found in a non-production environment or log without a documented reason.

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, with each level described in plain words for the team. 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, assuming the code and pipeline work as they would by default. Residual risk is the score after the existing and added controls are working, and it must never be higher than the inherent score. A risk with an inherent score of 10 or more must show a lower residual score, so the controls are visibly doing work. Impact is judged on data exposed, service hours lost, cost to correct, legal duties triggered and harm to customer trust. 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 watched. Scores are challenged in a review where someone who did not write the module or pipeline asks what evidence supports each rating, and the risk owner must agree any change in score. The register is also reviewed whenever an early warning 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
Deployment identities holding permissions outside their assigned environment.Escalate to the security lead at once, and revoke the excess permission within one working day.
Pipeline runs that apply changes without a second reviewer approval.Escalate to the platform lead when any run bypasses review, and pause the pipeline until it is reviewed.
Drift between the deployed environment and the code, found in scheduled checks.Escalate to the cloud operations lead when drift is found in production, and to the platform lead if it is not resolved within 3 days.
Storage or network rules open to public access that the code does not permit.Escalate to the security lead within one hour, and close the rule while the owner investigates.
Rebuild tests that do not finish within the agreed recovery time.Escalate to the site reliability lead and the platform lead at once, and reschedule the test within 30 days.

Contingency arrangements

If a serious event occurs, such as a leaked deployment credential or a destroyed production environment, the platform lead freezes the pipeline and revokes the affected identities. The security lead preserves logs and the state file before anything is changed. The team rebuilds services from the last reviewed code in a separate account, restores data from tested backups and checks each step against the recovery plan. Legal and privacy contacts are informed through the security lead as the relevant jurisdiction requires, and customers are told early what happened and what they should do.

Prioritized action plan

  1. Scope deployment identities to single environments and rotate all long-lived keys, owner platform lead, within 30 days.
  2. Run automated policy checks and secret scanning before every apply, owner security lead, within 45 days.
  3. Lock and encrypt the remote state store with restricted access and versioning, owner cloud operations lead, within 30 days.
  4. Pin and review third-party modules and images, owner platform engineer, within 60 days.
  5. Rehearse a full rebuild from code in a separate account and record the time taken, owner site reliability lead, within 90 days.

Conclusion

Infrastructure as code is powerful because it makes change visible, but that same power means one weak identity, one unchecked change or one lost state file can reach the whole environment. The highest scores sit with identity compromise, misconfiguration and secrets held in code, and each has actions that bring the residual score down. Keep the register alive, review it on the stated cycle, rehearse a rebuild from code, and seek qualified advice for any real security, privacy or legal question.

Assumptions and limitations

Assumptions

  • Infrastructure runs on one public cloud provider under a shared responsibility model, which is assumed for teaching.
  • Jurisdiction and data protection duties are not specified, so legal points are described in general terms only.
  • Engineers have standard access to repositories and pipelines, and production changes are expected to go through them.

Limitations

  • The scores are examples for learning and do not describe any real platform or service.
  • Provider features, security settings and legal duties change over time, so specialist review is needed.
  • This is educational content and is not security, legal or compliance advice.

Related frameworks to study

  • Least privilege access principle
  • Defense in depth with layered controls
  • Shared responsibility model for cloud services
  • Hierarchy of controls
  • Three lines model of risk ownership

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.

Infrastructure as Code course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,661 Learners