1. Purpose
The purpose of the Cloud Security Risk Assessment is to identify, evaluate, and manage information-security risks arising from the use of cloud services.
The assessment provides a structured method for determining:
- What cloud service is being used
- What information and systems depend on it
- Who can access it
- What threats and vulnerabilities exist
- What could happen if the cloud service is compromised or unavailable
- What security controls are already implemented
- What additional treatment is required
- What residual risk remains
- Who approved the resulting risk decision
The assessment should support the organization’s overall information-security risk-management process and Statement of Applicability where applicable.
2. Scope
The assessment may be applied to:
- IaaS
- PaaS
- SaaS
- Cloud databases
- Cloud storage
- Cloud networking
- Cloud identity services
- Cloud security platforms
- Cloud backup services
- Cloud-hosted applications
- Containers
- Serverless services
- Cloud APIs
- CI/CD platforms
- Cloud-based AI/ML services
- Critical cloud suppliers
- Cloud services processing customer or personal data
The depth of assessment should be proportionate to the service’s criticality, information handled, access, business dependency, regulatory requirements, and security risk.
3. Core Risk Assessment Principle
The assessment should follow this chain:
Cloud Service → Business Process → Information → Access → Dependency → Threat → Vulnerability → Exposure → Impact → Likelihood → Risk → Controls → Treatment → Residual Risk → Approval → Monitoring
This prevents the assessment from becoming merely a checklist of cloud-provider features.
4. When to Perform the Assessment
A Cloud Security Risk Assessment should be considered:
- Before introducing a significant new cloud service
- Before processing sensitive information
- Before using a cloud service for production
- When a cloud service becomes business-critical
- When significant architecture changes occur
- When new privileged access is introduced
- When new customer or personal data is processed
- When data location changes
- When a new subprocessor is introduced
- Following a significant security incident
- Following a major vulnerability
- During significant supplier changes
- During periodic ISMS risk reviews
- When contractual or regulatory requirements change
- When the organization significantly increases its dependency on a cloud service
Minor or low-risk changes may be handled through the organization’s normal change-management process rather than requiring a full new assessment.
5. Assessment Record
| Field | Details |
|---|---|
| Assessment ID | Unique assessment number |
| Cloud Service ID | Reference to Cloud Services Register |
| Cloud Service Name | Name of service |
| Provider | Cloud provider |
| Service Type | IaaS / PaaS / SaaS |
| Business Owner | Responsible business owner |
| Technical Owner | Technical owner |
| Assessment Date | Date performed |
| Assessment Lead | Person conducting assessment |
| Reviewers | Relevant reviewers |
| Previous Assessment | Reference if applicable |
| Assessment Trigger | New service / periodic / change / incident etc. |
| Status | Draft / In Review / Approved / Closed |
6. Cloud Service Identification
Document the cloud service being assessed.
Capture:
- Provider
- Service name
- Service type
- Account/subscription/environment
- Application supported
- Business purpose
- Production/non-production status
- Service owner
- Technical owner
- Supplier ID
- Criticality
Example:
AWS production environment used to host a customer-facing SaaS application, including application workloads, database, object storage, logging, monitoring, and security services.
7. Business Dependency Assessment
Identify what business activities depend on the cloud service.
Consider:
- Critical business processes
- Customer-facing services
- Revenue-generating activities
- Internal operations
- Regulatory processes
- Security operations
- Development and deployment
- Communication
- Payment processing
- Customer support
Example
Cloud Service: AWS
Business Dependency: Customer SaaS platform
Impact of prolonged outage: Customers cannot access the application and service delivery is disrupted.
8. Information Assessment
Identify the information processed, stored, or transmitted by the cloud service.
Examples:
- Customer information
- Personal data
- Employee information
- Application data
- Source code
- Financial information
- Security logs
- Authentication information
- Business documents
- Intellectual property
Record the applicable information classification.
| Information | Classification | Cloud Service |
|---|---|---|
| Customer application data | Confidential | AWS |
| Security logs | Internal/Confidential | Cloud logging platform |
| Source code | Confidential | GitHub |
| Employee records | Restricted | HR SaaS |
Classification labels should follow the organization’s approved information-classification scheme.
9. Data Location Assessment
Determine where information may be:
- Stored
- Processed
- Backed up
- Replicated
- Transferred
Consider:
- Primary region
- Backup region
- Disaster recovery region
- Provider processing locations
- Subprocessor locations
- International transfers
Example:
Production customer data is hosted in AWS Mumbai, while certain provider support or subprocessors may process limited information in other jurisdictions.
The assessment should consider applicable contractual, privacy, and regulatory requirements.
10. Access Assessment
Identify all significant forms of access.
Consider:
- Employee access
- Administrator access
- Developer access
- Customer access
- Supplier access
- Support access
- API access
- Service accounts
- Machine identities
- Privileged access
- Production access
Record whether access is:
- Individual
- Shared
- Role-based
- Temporary
- Persistent
- Privileged
11. Authentication Assessment
Evaluate whether appropriate authentication mechanisms are implemented.
Consider:
- MFA
- SSO
- Federated identity
- Strong passwords
- Service accounts
- API authentication
- Certificate authentication
- Privileged authentication
- Break-glass accounts
Example Finding
Two cloud administrator accounts are not protected by MFA.
Risk: Unauthorized privileged access.
Treatment: Enforce MFA and verify implementation.
12. Privileged Access Assessment
Determine:
- Who has administrative privileges?
- Why are privileges required?
- Is least privilege implemented?
- Are production permissions restricted?
- Are privileged activities logged?
- Are privileged accounts periodically reviewed?
- Are temporary privileges removed after use?
- Are emergency accounts controlled?
Privileged cloud access should generally receive enhanced protection because compromise could affect multiple systems and information assets.
13. Cloud Architecture Assessment
Review the relevant architecture.
Consider:
- Network segmentation
- Public exposure
- Private resources
- Internet-facing services
- Security groups/firewalls
- Load balancers
- Databases
- Storage
- APIs
- Containers
- Serverless functions
- Identity services
- Logging
- Monitoring
- Backup
- Disaster recovery
The assessment should identify architecture-related threats and weaknesses rather than simply recording whether an architecture diagram exists.
14. Configuration Security Assessment
Evaluate whether cloud resources are securely configured.
Examples:
- Storage not publicly accessible
- Security groups appropriately restricted
- Unnecessary ports disabled
- Administrative interfaces restricted
- Encryption enabled
- Logging enabled
- Secure network configuration
- Database access restricted
- Default credentials removed
- Unused services disabled
- Security controls consistently configured
Configuration baselines should be aligned with organizational requirements and risk.
15. Encryption Assessment
Evaluate encryption requirements for:
Data at Rest
Examples:
- Databases
- Object storage
- Backups
- Snapshots
- Logs
Data in Transit
Examples:
- Application traffic
- APIs
- Administrative connections
- Service-to-service communication
Also consider:
- Key management
- Key access
- Key rotation
- Separation of duties
- Key recovery
- Compromise response
16. Secrets and Credential Assessment
Identify how the cloud environment manages:
- Passwords
- API keys
- Tokens
- Access keys
- Private keys
- Database credentials
- Application secrets
- Certificates
Check whether secrets are stored in approved mechanisms rather than:
- Source code
- Git repositories
- Public storage
- Unprotected spreadsheets
- Container images
- Chat messages
17. Logging and Monitoring Assessment
Evaluate whether security-relevant cloud activities are logged and monitored.
Consider:
- Authentication
- Privileged actions
- API activity
- Configuration changes
- Network activity
- Security alerts
- Data access
- Application events
- Failed login attempts
- Resource changes
Also assess:
- Log retention
- Log protection
- Alerting
- Monitoring ownership
- Investigation process
18. Vulnerability Assessment
Identify vulnerabilities affecting:
- Operating systems
- Applications
- Containers
- Dependencies
- Cloud configurations
- APIs
- Network services
- Databases
- Serverless workloads
- Infrastructure-as-Code
For each significant finding, consider:
- Severity
- Exposure
- Exploitability
- Business impact
- Existing controls
- Remediation status
A scanner severity should not automatically determine the organization’s final risk rating.
19. Application Security Assessment
For cloud-hosted applications, evaluate:
- Authentication
- Authorization
- Input validation
- API security
- Secure coding
- Dependency management
- Secrets management
- Security testing
- Code review
- CI/CD security
- Container security
- Security monitoring
Where applicable, connect the assessment to the organization’s secure-development process.
20. Network Security Assessment
Consider:
- Network segmentation
- Firewall rules
- Security groups
- Network ACLs
- Private endpoints
- VPN
- Internet exposure
- Administrative access
- Egress controls
- WAF
- DDoS protection
Example:
A production database is directly accessible from the internet.
Potential risk: Unauthorized access or exploitation.
Treatment: Remove public exposure and permit access only from authorized application components.
21. Backup and Recovery Assessment
Evaluate:
- What information is backed up?
- Backup frequency
- Backup retention
- Backup encryption
- Backup access
- Backup isolation
- Recovery process
- Recovery testing
- RTO
- RPO
The assessment should determine whether the backup arrangement is sufficient for the business impact of cloud-service failure.
22. Availability and Resilience Assessment
Consider potential failures involving:
- Cloud provider outage
- Availability-zone failure
- Region failure
- Database failure
- Network failure
- Storage failure
- Identity-provider failure
- Key-management failure
- Third-party dependency
- Supplier service termination
Evaluate:
- Redundancy
- Failover
- Recovery procedures
- Alternative arrangements
- Dependency concentration
- Recovery testing
23. Supplier and Provider Risk
Assess the cloud provider itself.
Consider:
- Security assurance
- Contract
- SLA
- Security obligations
- Incident notification
- Data protection
- Subprocessors
- Data locations
- Provider dependency
- Financial/operational stability where relevant
- Exit capability
- Provider concentration
The provider’s security certification may be useful evidence, but it does not replace assessment of how the organization uses and configures the service.
24. Shared Responsibility Assessment
Document which controls are the responsibility of:
Cloud Provider
Examples:
- Physical data center
- Underlying hardware
- Certain infrastructure controls
Organization
Examples:
- IAM
- User accounts
- Application security
- Data classification
- Configuration
- Encryption configuration
- Logging
- Vulnerability management
- Backup configuration
Shared
Examples:
- Security monitoring
- Incident response
- Availability
- Vulnerability management
- Compliance
The exact responsibility model depends on the cloud service.
25. Subprocessor Assessment
Where applicable, evaluate:
- Subprocessor identity
- Service provided
- Information processed
- Data location
- Access
- Security assurance
- Contractual controls
- Incident notification
- Change notification
Particular attention should be given to subprocessors handling customer or personal data.
26. Cloud Dependency and Concentration Risk
Assess whether the organization is overly dependent on a single cloud provider or technology.
Consider:
- Single cloud provider
- Single region
- Single identity provider
- Single database technology
- Single security provider
- Single backup provider
- Proprietary cloud services
- Data portability
- Migration complexity
A concentration risk does not necessarily mean that multiple providers must be used. The organization should determine whether the dependency is acceptable and what compensating resilience measures are appropriate.
27. Threat Assessment
Identify realistic threats.
Examples:
| Threat | Example |
|---|---|
| Credential compromise | Administrator credentials stolen |
| Misconfiguration | Storage accidentally made public |
| Insider misuse | Privileged user abuses access |
| Vulnerability exploitation | Internet-facing workload exploited |
| Malware | Malicious code deployed |
| Data leakage | Sensitive data exposed |
| Cloud outage | Provider service unavailable |
| Supply-chain compromise | Third-party dependency compromised |
| DDoS | Application becomes unavailable |
| Unauthorized API access | API credentials compromised |
Threats should be based on the actual cloud environment rather than a generic threat list.
28. Vulnerability and Exposure Assessment
For each threat, identify relevant vulnerabilities or weaknesses.
Example:
Threat: Unauthorized cloud administration
Vulnerability: Excessive IAM privileges
Exposure: Administrator account can modify production resources
Existing Control: MFA
Additional Control: Least-privilege role redesign and quarterly privileged-access review
29. Risk Assessment
Each identified risk should be assessed using the organization’s approved risk methodology.
A basic structure is:
Risk = Likelihood × Impact
However, the organization’s established methodology should define the actual scoring model.
Example
| Risk Element | Example |
|---|---|
| Asset | AWS Production Environment |
| Threat | Credential compromise |
| Vulnerability | Excessive privileged access |
| Exposure | Production administrator role |
| Impact | High |
| Likelihood | Medium |
| Inherent Risk | High |
| Existing Controls | MFA, logging |
| Treatment | Least privilege + access review |
| Residual Risk | Medium |
The example is illustrative only.
30. Cloud Risk Register
Significant risks should be recorded in the organization’s risk register or an approved linked risk record.
Recommended fields:
| Field | Description |
|---|---|
| Risk ID | Unique identifier |
| Cloud Service ID | Related cloud service |
| Risk Description | Clear statement of risk |
| Asset | Affected asset |
| Threat | Threat scenario |
| Vulnerability | Weakness |
| Exposure | How threat can act |
| Impact | Business/security impact |
| Likelihood | Likelihood |
| Inherent Risk | Risk before treatment |
| Existing Controls | Current controls |
| Treatment | Required action |
| Owner | Risk/action owner |
| Due Date | Target date |
| Residual Risk | Risk after treatment |
| Acceptance | Acceptance decision |
| Approval | Authorized approver |
| Review Date | Next review |
| Status | Open/Closed/etc. |
31. Risk Treatment
Treatment should be based on the organization’s approved risk-treatment approach.
Possible approaches include:
Reduce
Implement additional controls.
Example:
Implement MFA and least privilege.
Avoid
Stop using the cloud service where the risk cannot be appropriately managed.
Transfer/Share
Use contractual, insurance, or other arrangements where appropriate.
Accept
Accept the remaining risk through an authorized risk-acceptance process.
Risk acceptance should be formally authorized and should not simply be used to avoid remediation.
32. Cloud Security Treatment Plan
For each significant risk, document:
- Required control
- Action
- Responsible owner
- Target date
- Priority
- Dependencies
- Required evidence
- Validation method
- Residual-risk expectation
Example:
| Finding | Treatment | Owner | Evidence |
|---|---|---|---|
| Public S3 bucket | Restrict public access | Cloud Engineer | Configuration evidence |
| Excessive IAM privileges | Redesign roles | Security/Cloud | IAM review |
| No recovery test | Perform restore test | IT | Recovery test record |
33. Residual Risk Assessment
After treatment, reassess the risk.
The assessment should determine:
- Were controls implemented?
- Are they operating?
- Has exposure decreased?
- Has likelihood changed?
- Has impact changed?
- Is additional treatment required?
- Is remaining risk acceptable?
Example:
Inherent Risk: High
↓ MFA + least privilege + monitoring
Residual Risk: Medium
The residual-risk decision should follow the organization’s approved risk methodology and acceptance authority.
34. AWS SaaS Example
A SaaS startup hosts its production platform on AWS.
Architecture includes:
- ECS/EC2
- RDS
- S3
- IAM
- KMS
- CloudTrail
- CloudWatch
- WAF
Scenario
A review identifies that several developers have broad production IAM permissions.
Threat: Compromised developer account.
Vulnerability: Excessive IAM permissions.
Exposure: Developer account can modify production infrastructure and access sensitive resources.
Potential Impact:
- Customer data exposure
- Application disruption
- Unauthorized configuration changes
- Security incident
- Customer trust impact
Existing Controls:
- MFA
- CloudTrail
- Security monitoring
Treatment:
- Implement role-based least privilege
- Separate development and production permissions
- Restrict privileged production access
- Perform periodic access reviews
- Monitor privileged actions
Verification Evidence:
- IAM role configuration
- Access review
- CloudTrail evidence
- Security monitoring configuration
- Approved risk treatment record
Residual Risk: Reassess after implementation.
35. Cloud Risk Assessment Summary
At the end of the assessment, summarize:
Key Risks
List significant identified risks.
Key Controls
List important existing controls.
Security Gaps
Identify unresolved weaknesses.
Required Actions
Identify corrective/treatment actions.
Residual Risk
Document remaining risk.
Decision
Possible organizational decisions include:
- Approved
- Approved with Conditions
- Further Assessment Required
- Treatment Required
- Risk Accepted
- Service Not Approved
These are organizational decision options, not ISO-prescribed outcomes.
36. Approval
The assessment should be reviewed and approved by appropriate stakeholders based on risk.
Depending on the organization, this may include:
- Business Owner
- Technical Owner
- Information Security
- Privacy
- IT/Cloud Team
- Risk Owner
- Senior Management
Higher-risk cloud services should receive appropriate management oversight.
37. Monitoring and Reassessment
Cloud risk should not be treated as a one-time assessment.
Reassessment should occur when there is:
- Major cloud architecture change
- Security incident
- Significant vulnerability
- New data processing
- New privileged access
- New subprocessor
- Data-location change
- Significant provider change
- Major outage
- Increased business dependency
- Material contractual change
- Regulatory change
- Significant change in threat environment
Periodic reassessment should also be performed according to the organization’s risk-management requirements.
38. Evidence Register
Maintain references to evidence supporting the assessment.
| Evidence | Example |
|---|---|
| Cloud architecture | Architecture diagram |
| IAM | Access review |
| MFA | Identity configuration |
| Configuration | Cloud security assessment |
| Encryption | KMS/configuration evidence |
| Logging | CloudTrail configuration |
| Monitoring | CloudWatch/security monitoring |
| Vulnerability | Vulnerability report |
| Backup | Backup configuration |
| Recovery | Recovery test |
| Supplier | ISO/SOC evidence |
| Contract | Cloud agreement |
| DPA | Data Processing Agreement |
| Risk | Approved risk assessment |
| Treatment | Corrective action evidence |
Evidence should be stored in the organization’s approved repository.
Secrets and credentials must never be stored as assessment evidence.
39. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Cloud Security Policy | Defines cloud-security requirements |
| Cloud Services Register | Identifies the cloud service being assessed |
| Asset Register | Identifies affected information assets |
| Risk Register | Records significant cloud risks |
| Risk Treatment Plan | Tracks treatment actions |
| Statement of Applicability | Records applicable ISO controls |
| Supplier Risk Assessment | Assesses provider-related risk |
| Critical Supplier Register | Identifies critical providers |
| ICT Dependency Register | Records cloud dependencies |
| Access Review | Validates cloud access |
| Vulnerability Register | Tracks vulnerabilities |
| Incident Register | Records cloud incidents |
| Business Continuity Plan | Addresses cloud disruption |
| Backup Policy | Defines backup requirements |
| Change Management | Controls significant cloud changes |
40. Common Mistakes
1. Treating the provider as the entire risk
“AWS is ISO certified, therefore our cloud is secure.”
Provider assurance does not establish that the organization’s IAM, configuration, applications, data, or operational processes are secure.
2. Only checking technical controls
Business dependency, customer impact, privacy, availability, concentration, and exit risks should also be considered.
3. No data-flow assessment
The assessment should identify where information is stored, processed, replicated, and transferred where relevant.
4. Ignoring privileged access
Cloud administrator access can create significant exposure.
5. No residual-risk decision
Closing findings without reassessing the remaining risk weakens the risk-management trail.
6. Treating vulnerability severity as the entire risk
A vulnerability should be evaluated in context of exposure, exploitability, existing controls, and business impact.
7. Assessment never updated
Cloud architecture and risks change continuously.
41. Internal Audit Checklist
An auditor may verify:
- Is the cloud service identified?
- Is it recorded in the Cloud Services Register?
- Is the business purpose documented?
- Are business dependencies identified?
- Is information processed identified?
- Is information classification defined?
- Is customer/personal data identified?
- Is data location understood?
- Are users and privileged users identified?
- Is MFA implemented where required?
- Is least privilege assessed?
- Is cloud architecture reviewed?
- Are configuration risks assessed?
- Is encryption assessed?
- Are secrets protected?
- Are logging and monitoring assessed?
- Are vulnerabilities considered?
- Are backup and recovery assessed?
- Is availability considered?
- Is supplier risk assessed?
- Are subprocessors considered?
- Is concentration/dependency risk considered?
- Are significant risks recorded?
- Are treatment actions assigned?
- Is residual risk assessed?
- Is risk acceptance formally approved where applicable?
- Is evidence available?
- Is the assessment periodically reviewed?
- Are material changes triggering reassessment?
42. ISO 27001 Connection
The Cloud Security Risk Assessment supports the organization’s risk-based ISMS by connecting cloud usage with information-security risks and controls.
It can provide evidence supporting areas such as:
- Cloud service security
- Information classification
- Access control
- Identity management
- Privileged access
- Supplier management
- ICT supply-chain security
- Configuration management
- Logging and monitoring
- Vulnerability management
- Backup
- Network security
- Secure development
- Incident management
- Business continuity
The assessment itself is an organizational risk-management tool. ISO 27001 does not require every organization to use this exact template.
The organization should determine the required assessment depth based on its ISMS scope, risk methodology, cloud usage, applicable controls, legal/regulatory obligations, contractual requirements, and business context.
43. Final Cloud Security Risk Audit Trail
A complete assessment should demonstrate:
Cloud Service Identified
↓
Business Dependency
↓
Information Identified
↓
Data Location
↓
Access & Privileged Access
↓
Architecture & Configuration
↓
Threat Identification
↓
Vulnerability / Exposure
↓
Business Impact
↓
Likelihood
↓
Inherent Risk
↓
Existing Controls
↓
Risk Treatment
↓
Control Implementation
↓
Verification
↓
Residual Risk
↓
Risk Acceptance / Further Treatment
↓
Approval
↓
Monitoring
↓
Periodic Reassessment
44. Final Principle
A useful Cloud Security Risk Assessment should answer seven questions:
What cloud service are we using?
What business and information depend on it?
Who can access it?
What could go wrong?
What controls protect it?
What risk remains after those controls?
Who accepted or treated that remaining risk, and how do we know the controls continue to work?
The objective is not to prove that the cloud provider is secure. The objective is to demonstrate that the organization understands and manages the security risks created by its own use of cloud services.