1. Purpose
The Cloud Provider Due Diligence Questionnaire is used to evaluate the security, privacy, availability, resilience, operational, contractual, and compliance capabilities of a cloud service provider before and during the use of its services.
The questionnaire helps the organization determine whether the provider’s capabilities are appropriate for:
- The information being processed
- The systems being hosted
- The level of access provided
- The business dependency
- Customer requirements
- Regulatory obligations
- Contractual requirements
- The organization’s risk appetite
The questionnaire should be used together with the organization’s supplier-management and cloud-risk-management processes.
2. Scope
This questionnaire may be used for:
- IaaS providers
- PaaS providers
- SaaS providers
- Cloud database providers
- Cloud storage providers
- Cloud backup providers
- Cloud security providers
- Cloud identity providers
- Cloud hosting providers
- Cloud networking providers
- Cloud monitoring providers
- Cloud AI/ML providers
- Cloud development platforms
- Cloud-based business applications
The depth of due diligence should be proportionate to the provider’s criticality, information handled, access, dependency, and risk.
3. How to Complete the Questionnaire
For each applicable question, the provider should respond using:
- Yes
- No
- Partially
- Not Applicable (N/A)
Where appropriate, the provider should provide:
- Explanation
- Supporting evidence
- Document name
- Certification/report reference
- URL to public documentation
- Scope information
- Date/validity period
The provider should not provide passwords, API keys, private keys, confidential credentials, or other secrets as questionnaire evidence.
4. Provider Information
| Field | Response |
|---|---|
| Provider Name | |
| Legal Entity | |
| Headquarters | |
| Website | |
| Primary Contact | |
| Security Contact | |
| Privacy Contact | |
| Service Name | |
| Service Type | IaaS / PaaS / SaaS / Other |
| Service Description | |
| Assessment Date | |
| Assessment Owner | |
| Provider Account Manager | |
| Contract Status | |
| Service Criticality | |
| Cloud Service ID | |
| Supplier ID |
5. Service Overview
Questions
- Describe the cloud service being provided.
- What business functions does the service support?
- Is the service IaaS, PaaS, SaaS, or another model?
- What major components make up the service?
- What geographic regions are available?
- What regions will be used by the organization?
- Does the service support production environments?
- Does the service process customer information?
- Does the service process personal data?
- Does the service process confidential or restricted information?
- Does the provider provide dedicated or shared infrastructure?
- Are there service dependencies on other providers?
Evidence
Request, where relevant:
- Service architecture
- Product documentation
- Service description
- Data-flow documentation
- Shared-responsibility documentation
6. Business Continuity and Criticality
- What availability commitments are provided?
- What are the provider’s standard service availability targets?
- Does the provider maintain business continuity plans?
- Does the provider maintain disaster recovery plans?
- Are continuity plans tested?
- How frequently are recovery tests performed?
- Are recovery objectives documented?
- What are the applicable RTOs?
- What are the applicable RPOs?
- How does the provider handle major regional outages?
- Does the provider have alternative infrastructure?
- How are customers informed about major service disruptions?
Evidence
- BCP summary
- DR summary
- Availability/SLA documentation
- DR testing summary
- Relevant assurance reports
7. Information Security Governance
- Does the provider maintain an information-security program?
- Is there a formally approved information-security policy?
- Is responsibility for information security assigned?
- Does the provider perform security risk assessments?
- Is information security reviewed by management?
- Are security objectives defined?
- Are security policies periodically reviewed?
- Does the provider maintain security procedures?
- Are security requirements incorporated into service design?
- Does the provider maintain a security governance function?
Evidence
- Security policy summary
- Governance structure
- ISO 27001 certificate, if applicable
- SOC report, if applicable
- Independent assessment
8. Security Certifications and Assurance
- Is the provider ISO/IEC 27001 certified?
- What entity is covered by the certification?
- What services and locations are included in the certification scope?
- What is the certificate validity period?
- Are there applicable exclusions?
- Does the provider have a SOC 1 report?
- Does the provider have a SOC 2 report?
- What Trust Services Criteria are covered?
- What reporting period does the SOC report cover?
- Are there exceptions or qualified findings?
- Does the provider undergo independent penetration testing?
- Does the provider undergo other independent security assessments?
- Are significant assessment findings tracked to remediation?
Evidence
Request appropriate assurance documents rather than relying solely on provider marketing statements.
9. Shared Responsibility Model
- Does the provider publish a shared-responsibility model?
- Which controls are the provider’s responsibility?
- Which controls are the customer’s responsibility?
- Which controls are shared?
- Does responsibility vary by service?
- Does responsibility vary by deployment model?
- Are customer configuration responsibilities documented?
- Are security configuration recommendations provided?
- Are customers notified when responsibility changes because of a service change?
Evidence
- Shared-responsibility documentation
- Security architecture documentation
- Service-specific security guidance
10. Physical Security
Where applicable:
- Are data centers physically protected?
- Is physical access restricted?
- Is visitor access controlled?
- Is physical access monitored?
- Are physical access records maintained?
- Are environmental controls implemented?
- Are power systems protected?
- Are fire detection and suppression controls implemented?
- Are physical security controls independently assessed?
- Are physical security incidents managed?
The organization should normally rely on appropriate independent assurance rather than requesting sensitive data-center security details.
11. Identity and Access Management
- Does the provider use formal identity-management controls?
- Are individual administrative accounts supported?
- Is MFA supported?
- Is SSO supported where applicable?
- Are privileged accounts separately managed?
- Is least privilege implemented internally?
- Are privileged activities logged?
- Are access rights periodically reviewed?
- Are terminated personnel removed promptly?
- Are service accounts controlled?
- Are API credentials protected?
- Are administrative interfaces protected?
- Is emergency or break-glass access controlled?
12. Customer Access Controls
- Does the service support role-based access control?
- Can customers restrict user permissions?
- Can customers enforce MFA?
- Can customers manage administrator roles?
- Can customers review access logs?
- Can customers disable users?
- Can customers restrict API access?
- Can customers configure session controls?
- Can customers enforce password requirements where applicable?
- Does the provider provide guidance for secure customer configuration?
13. Privileged Access
- How is provider administrative access controlled?
- Is privileged access limited to authorized personnel?
- Is MFA required for provider administrators?
- Is privileged access logged?
- Are privileged activities monitored?
- Is privileged access periodically reviewed?
- Is temporary or just-in-time access used where appropriate?
- Are privileged accounts segregated from normal accounts?
- Are administrative activities attributable to individual users?
- How are privileged-access incidents investigated?
14. Data Protection
- What categories of information can the service process?
- Where is customer data stored?
- Where is customer data processed?
- Can customers select data regions?
- Is data replicated across regions?
- Are backups stored separately?
- How is customer data logically separated?
- Can one customer access another customer’s information?
- Are data-processing activities documented?
- Are data-retention options available?
- Can customers request deletion?
- How is deletion verified?
- Are deleted data and backups eventually removed?
15. Data Classification
- Does the provider have an information-classification process?
- Are customer information types identified?
- Are sensitive data-handling requirements defined?
- Are employees trained on information classification?
- Are access controls aligned with information sensitivity?
- Are sensitive information transfers controlled?
16. Encryption
Data in Transit
- Is customer data protected during transmission?
- Are secure protocols supported?
- Are insecure protocols disabled or restricted?
Data at Rest
- Is customer data encrypted at rest?
- Are backups encrypted?
- Are snapshots encrypted?
- Are logs protected?
Key Management
- How are encryption keys protected?
- Is key access restricted?
- Is key rotation supported?
- Can customers manage their own keys where applicable?
- Are key-management activities logged?
17. Secrets and Credential Security
- How are provider credentials protected?
- How are API keys protected?
- Are secrets stored in dedicated secure systems?
- Are credentials encrypted?
- Is credential access restricted?
- Are secrets rotated?
- Are compromised credentials revoked?
- Are secrets prevented from being exposed in logs?
18. Network Security
- Are provider networks segmented?
- Are customer environments logically isolated?
- Are firewalls implemented?
- Are network access controls implemented?
- Are administrative interfaces protected?
- Are network security events monitored?
- Is DDoS protection available?
- Are secure private connectivity options available?
- Can customers restrict network access?
- Are network configuration changes controlled?
19. Cloud Configuration Security
- Does the provider provide secure configuration guidance?
- Are secure configuration baselines maintained?
- Are insecure default settings minimized?
- Are configuration changes controlled?
- Are security-relevant configuration changes logged?
- Are configuration vulnerabilities identified?
- Are customers notified about significant security configuration changes?
- Are automated configuration-security capabilities available?
20. Vulnerability Management
- Does the provider maintain a vulnerability-management program?
- Are infrastructure vulnerabilities regularly identified?
- Are applications tested for vulnerabilities?
- Are vulnerabilities risk-rated?
- Are critical vulnerabilities prioritized?
- Are remediation timelines defined?
- Are vulnerability scans performed regularly?
- Is penetration testing performed?
- Are significant findings tracked through remediation?
- How are customers informed about vulnerabilities affecting their service?
- Does the provider maintain unsupported/EOL software controls?
Evidence
Where appropriate:
- Vulnerability-management summary
- Penetration-test summary
- SOC report
- Independent assessment
21. Secure Development
Where the provider develops software:
- Does the provider maintain a secure SDLC?
- Are security requirements defined during development?
- Is source code protected?
- Is code reviewed?
- Is security testing performed?
- Are dependencies monitored?
- Are open-source components assessed?
- Is software composition analysis used?
- Are secrets detected in source code?
- Are vulnerabilities tracked before release?
- Are production releases controlled?
- Is separation between development and production maintained?
22. Software Supply Chain
- Does the provider maintain visibility of third-party software components?
- Are software dependencies tracked?
- Are vulnerable dependencies identified?
- Are open-source components reviewed?
- Are container images assessed?
- Are build pipelines protected?
- Is source-code integrity protected?
- Is an SBOM maintained where appropriate?
- Are critical software-supply-chain risks monitored?
- Are compromised components addressed through incident-response processes?
23. Logging and Monitoring
- Does the provider maintain security logging?
- Are administrative actions logged?
- Are authentication events logged?
- Are configuration changes logged?
- Are security events monitored?
- Are logs protected from unauthorized alteration?
- Are logs retained for defined periods?
- Are security alerts investigated?
- Are customers provided with relevant logs?
- Can customers export logs?
- Is monitoring performed continuously where appropriate?
24. Security Incident Management
- Does the provider maintain a documented incident-response process?
- Are security incidents classified by severity?
- Is an incident-response team established?
- Are incidents investigated?
- Are security events escalated?
- Are incident records maintained?
- Is evidence preserved?
- Are lessons learned captured?
- Are corrective actions tracked?
- Are customers notified of incidents affecting their information or services?
25. Security Incident Notification
- What constitutes a reportable security incident?
- How will the organization be notified?
- What notification timeframe applies?
- Is notification available 24/7 for critical incidents?
- What information is included in an incident notification?
- Will the provider provide ongoing updates?
- Will the provider provide a post-incident report where appropriate?
- Will the provider cooperate with customer investigations?
Contractual requirements should define the applicable notification obligations.
26. Data Breach and Privacy
- Does the provider have a personal-data breach procedure?
- Does the provider identify privacy incidents separately where appropriate?
- Are privacy incidents escalated?
- Are customers notified according to applicable obligations?
- Does the provider assist customers with regulatory obligations?
- Are data-subject rights supported where applicable?
- Are privacy complaints managed?
- Are privacy risks assessed?
- Is privacy training provided?
- Is personal data processed only for agreed purposes?
27. Data Processing and DPA
Where personal data is involved:
- Will the provider enter into a DPA?
- Does the DPA define the processing relationship?
- Are processing purposes defined?
- Are data categories defined?
- Are data-subject categories defined?
- Are security measures described?
- Are subprocessors addressed?
- Are international transfers addressed?
- Are breach-notification obligations addressed?
- Are return/deletion requirements defined?
- Are audit/assurance provisions included?
- Are government-access requests addressed?
28. Subprocessors
- Does the provider use subprocessors?
- Is a current subprocessor list available?
- What services do subprocessors provide?
- What information can they access?
- Where are subprocessors located?
- Are subprocessors subject to security requirements?
- Are subprocessors assessed before engagement?
- Does the provider monitor subprocessors?
- How are new subprocessors communicated to customers?
- Can customers object where contractually applicable?
- Are fourth parties used?
29. Data Location and International Transfers
- Where will organizational data be stored?
- Where will it be processed?
- Where are backups stored?
- Can customers select processing regions?
- Is data transferred internationally?
- What legal mechanism supports international transfers where applicable?
- Are customers informed about material location changes?
- Are subprocessors included in the location assessment?
30. Backup
- Is customer data backed up?
- How frequently?
- What retention applies?
- Are backups encrypted?
- Are backups protected from unauthorized modification?
- Are backups logically or physically separated?
- Are backup restoration tests performed?
- Are recovery failures monitored?
- Are backup responsibilities clearly divided between provider and customer?
31. Disaster Recovery
- Does the provider maintain a disaster-recovery plan?
- Is the plan periodically tested?
- What recovery objectives apply?
- Is geographic redundancy available?
- Can services recover after regional failures?
- Are recovery tests independently reviewed?
- Are significant recovery findings remediated?
- Are customers informed about major disaster-recovery limitations?
32. Availability and Service Resilience
- What SLA applies?
- What availability target is provided?
- How are outages monitored?
- How are customers notified?
- What redundancy exists?
- Are multiple availability zones supported?
- Are multiple regions supported?
- What happens during provider infrastructure failure?
- What service credits or contractual remedies apply where applicable?
- Are availability metrics available to customers?
33. Physical and Environmental Security
Where relevant:
- Are data centers access-controlled?
- Are visitors controlled?
- Is CCTV used?
- Is environmental monitoring implemented?
- Are power systems redundant?
- Are fire controls implemented?
- Are physical security incidents monitored?
- Are physical security controls independently assessed?
Sensitive physical-security details need not be provided where independent assurance adequately demonstrates control effectiveness.
34. Personnel Security
- Are background checks performed where legally permitted?
- Are employees required to sign confidentiality agreements?
- Are security responsibilities defined?
- Is security awareness training provided?
- Is role-specific security training provided?
- Are employees with privileged access subject to enhanced controls?
- Is access removed promptly upon termination?
- Are contractor controls implemented?
35. Security Awareness
- Is security awareness training mandatory?
- Is training provided periodically?
- Is phishing/security awareness included?
- Is role-specific training provided?
- Is completion monitored?
- Are privileged administrators provided with additional security training?
36. Change Management
- Does the provider have a formal change-management process?
- Are security impacts assessed?
- Are significant changes tested?
- Are changes approved?
- Are emergency changes controlled?
- Are changes logged?
- Are customers notified of material changes?
- Are major service changes assessed for security impact?
37. Configuration and Asset Management
- Does the provider maintain an asset inventory?
- Are critical infrastructure components identified?
- Are configurations controlled?
- Are configuration changes tracked?
- Are unauthorized changes detected?
- Are unsupported assets identified?
- Are asset owners assigned?
38. Business and Operational Resilience
- Does the provider assess operational risks?
- Does the provider have continuity plans?
- Are critical suppliers identified?
- Are critical dependencies assessed?
- Is concentration risk considered?
- Are alternative arrangements available?
- Are major operational disruptions tested?
- Are lessons learned from disruptions recorded?
39. Contractual and Legal Requirements
- Does the contract define security responsibilities?
- Are confidentiality obligations included?
- Are data-protection requirements included?
- Are security incident requirements included?
- Are availability commitments defined?
- Are security-assurance obligations defined?
- Are audit/assessment rights addressed?
- Are subcontractors/subprocessors addressed?
- Are data-return requirements included?
- Are deletion requirements included?
- Are termination obligations defined?
- Are material security changes addressed?
40. Audit and Assurance Rights
- Does the provider permit customer security assessments?
- Are independent assurance reports available?
- Can customers review applicable certifications?
- Can the organization request additional security information?
- Are audit rights defined contractually?
- Are audit limitations clearly documented?
- Can significant security findings be communicated to customers?
- Can remediation evidence be provided where appropriate?
41. Regulatory and Compliance Requirements
- What regulatory frameworks apply to the service?
- Does the provider support applicable customer compliance requirements?
- Does the provider maintain compliance certifications?
- Are regulatory changes monitored?
- Are compliance obligations assigned between provider and customer?
- Does the provider notify customers of material compliance changes?
The organization should verify that the provider’s compliance claim applies to the specific service, legal entity, geography, and scope being considered.
42. AI and Machine Learning
Where the cloud service includes AI/ML:
- Is customer information used to train provider models?
- Can customers opt out of model training?
- How is customer data isolated?
- Are AI/ML subprocessors used?
- Where is AI data processed?
- Are AI security risks assessed?
- Are prompts and outputs retained?
- Are AI-related logs maintained?
- Are AI services covered by security assurance?
- Are AI-specific incident and privacy controls implemented?
43. Cloud Exit and Data Portability
- Can customers export their data?
- What formats are supported?
- Are APIs available for migration?
- Are backups exportable?
- What assistance is provided during migration?
- What happens to customer data after contract termination?
- How is deletion verified?
- Are copies in backups eventually deleted?
- Are customer credentials revoked?
- Are there proprietary dependencies that make migration difficult?
44. Service Termination
- What happens when the service is terminated?
- How long does the customer have to retrieve data?
- How is data securely deleted?
- Are backups eventually deleted?
- Is deletion evidence available?
- Are accounts and credentials disabled?
- Are integrations disconnected?
- Are subprocessors notified where appropriate?
45. Security Exceptions and Findings
- Does the provider maintain a security exception process?
- Are security findings risk assessed?
- Are significant findings assigned owners?
- Are remediation deadlines defined?
- Are overdue findings escalated?
- Is management approval required for significant exceptions?
- Are recurring findings analyzed?
46. Provider Security Metrics
Where available, request relevant metrics such as:
- Security incidents
- Critical vulnerabilities
- Patch performance
- Availability
- Recovery testing
- Security-training completion
- Privileged-access reviews
- Significant audit findings
- Incident response performance
Metrics should be interpreted in context and should not be treated as universally comparable between providers.
47. Provider Declaration
The provider should confirm:
We confirm that the information provided in this questionnaire is accurate and complete to the best of our knowledge as of the assessment date. Material changes affecting the security, privacy, availability, processing location, subprocessors, or contractual commitments associated with the service will be communicated in accordance with the applicable agreement.
Provider Representative: __________________
Title: __________________
Date: __________________
Signature / Electronic Approval: __________________
48. Evidence Register
Supporting evidence should be recorded separately.
| Evidence ID | Requirement | Evidence | Scope | Date | Valid Until | Status |
|---|---|---|---|---|---|---|
| E-001 | Security governance | ISO 27001 certificate | Relevant entity/service | |||
| E-002 | Assurance | SOC 2 report | Relevant service | |||
| E-003 | Vulnerability management | Pen-test summary | Relevant environment | |||
| E-004 | Continuity | DR test summary | Relevant service | |||
| E-005 | Privacy | DPA | Relevant processing |
Evidence should be checked for scope, validity, relevance, currency, limitations, exceptions, and applicability.
49. Evidence Review Principle
A provider response of “Yes” should not automatically be treated as sufficient evidence.
For important controls, the organization should consider:
Question → Provider Response → Evidence → Scope → Validation → Finding → Risk Decision
For example:
Question: Is MFA supported?
Provider: Yes.
This does not necessarily establish that MFA is enabled for the organization’s administrative users.
The organization should determine whether MFA is:
- Supported by the service
- Contractually required where appropriate
- Configured by the organization
- Actually enforced
- Verified through evidence
50. Questionnaire Evaluation
The completed questionnaire should be evaluated against the organization’s requirements.
A simple internal evaluation model may use:
| Result | Meaning |
|---|---|
| Satisfactory | Requirement adequately addressed |
| Partially Satisfactory | Some limitations or gaps |
| Unsatisfactory | Requirement not adequately addressed |
| Evidence Required | Response requires supporting evidence |
| N/A | Requirement genuinely does not apply |
These labels are organizational assessment categories, not ISO-prescribed ratings.
51. Risk-Based Review
Not every questionnaire response represents the same level of risk.
For example:
Low concern:
A provider does not offer a feature that is irrelevant to the organization’s use of the service.
Potentially significant concern:
A critical SaaS provider processing customer personal data cannot provide adequate information about incident notification, data deletion, or subprocessors.
The organization should evaluate gaps in the context of:
- Information sensitivity
- Service criticality
- Access
- Business dependency
- Customer impact
- Regulatory obligations
- Existing compensating controls
- Contractual protections
52. Findings and Corrective Actions
Identified gaps should be recorded.
| Finding | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|
| MFA not available for privileged users | High | Implement stronger administrative authentication | Provider | Open | |
| Subprocessor list unclear | Medium | Obtain current subprocessor information | Provider | Open | |
| DR evidence outdated | Medium | Provide current DR test evidence | Provider | Pending |
The organization should determine whether each finding requires:
- Remediation
- Additional evidence
- Contractual control
- Compensating control
- Risk acceptance
- Further assessment
- Service rejection
53. Cloud Provider Risk Summary
At the end of the assessment, summarize:
Provider
Name and service.
Service
What the organization intends to use.
Information
What information will be processed.
Criticality
Business and security criticality.
Key Security Strengths
Important controls and assurance.
Key Gaps
Important deficiencies or evidence gaps.
Key Risks
Risks requiring treatment.
Contractual Requirements
Security, privacy, incident, availability, and termination requirements.
Residual Risk
Risk remaining after controls and treatment.
Recommendation for Internal Decision
Possible internal outcomes include:
- Approved
- Approved with Conditions
- Further Assessment Required
- Additional Controls Required
- Management Risk Acceptance
- Not Approved
These are organizational decision options, not ISO-prescribed outcomes.
54. AWS Example
For a SaaS organization considering AWS as its production cloud provider, due diligence may cover:
- AWS security governance
- ISO 27001/SOC assurance
- Shared-responsibility model
- Data-center security
- IAM capabilities
- MFA
- Encryption
- KMS
- CloudTrail
- CloudWatch
- GuardDuty/Security Hub
- Network security
- WAF
- Vulnerability management
- Backup
- Multi-AZ resilience
- Regional availability
- Incident notification
- Subprocessors
- Data locations
- Contractual terms
- Exit and data portability
The assessment should then distinguish between:
AWS provider controls
and
controls that the SaaS organization must configure and operate itself.
For example, AWS may provide IAM functionality, but the organization remains responsible for configuring appropriate IAM roles, permissions, MFA, privileged access, monitoring, and reviews for its own environment.
55. Startup-Friendly Approach
A startup does not necessarily need to send a 200-question questionnaire to every cloud provider.
Low-Risk Cloud Service
Review:
- Service purpose
- Data handled
- Basic security
- Privacy
- Contract
- Provider assurance
- Availability
Medium-Risk Service
Add:
- Access
- Encryption
- Incident management
- Vulnerability management
- Backup
- Subprocessors
- Data location
High/Critical Cloud Provider
Perform enhanced due diligence covering:
- Security governance
- Shared responsibility
- IAM
- Privileged access
- Architecture
- Encryption
- Logging
- Vulnerability management
- Incident response
- Privacy
- Subprocessors
- Data location
- BCP/DR
- Resilience
- Concentration risk
- Exit/migration
- Assurance reports
- Contractual protections
The level of due diligence should be proportionate to actual risk.
56. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Cloud Services Register | Identifies the cloud service |
| Cloud Security Policy | Defines security requirements |
| Cloud Security Risk Assessment | Converts due-diligence findings into cloud risk |
| Supplier Risk Assessment | Evaluates broader supplier risk |
| Supplier Due Diligence Checklist | General supplier assessment |
| Supplier Security Questionnaire | Broader supplier security questionnaire |
| Critical Supplier Register | Identifies critical providers |
| Supplier Security Requirements | Defines required controls |
| Supplier Security Addendum | Converts requirements into contractual obligations |
| DPA | Addresses applicable personal-data processing |
| Subprocessor Review | Reviews downstream providers |
| Supplier Security Evidence Review | Validates provider evidence |
| Supplier Monitoring Register | Tracks ongoing monitoring |
| ICT Dependency Register | Records business/technology dependency |
| Risk Register | Records significant identified risks |
57. Common Mistakes
1. Asking only about certifications
“Do you have ISO 27001?”
A certificate alone does not answer how the specific service handles the organization’s information.
2. Ignoring shared responsibility
A provider may secure its infrastructure while the customer remains responsible for configuration, access, data, and applications.
3. Accepting questionnaire answers without evidence
Important claims should be validated through appropriate assurance.
4. Ignoring data location
The organization should understand where information is stored, processed, replicated, and backed up where relevant.
5. Ignoring subprocessors
Cloud providers may rely on other providers for parts of their service.
6. Ignoring exit
Critical cloud dependencies should be considered from both onboarding and termination perspectives.
7. Using identical due diligence for every provider
The depth of assessment should reflect actual risk and criticality.
58. Internal Audit Checklist
An auditor may verify:
- Is cloud-provider due diligence performed where appropriate?
- Is the provider identified?
- Is the service clearly defined?
- Is service criticality documented?
- Is the information processed identified?
- Is customer/personal data identified?
- Is data location considered?
- Has the shared-responsibility model been reviewed?
- Has provider security assurance been reviewed?
- Has IAM capability been assessed?
- Has privileged access been considered?
- Has encryption been assessed?
- Has vulnerability management been assessed?
- Has logging and monitoring been assessed?
- Has incident response been assessed?
- Are incident-notification requirements understood?
- Has privacy/DPA been assessed where applicable?
- Have subprocessors been reviewed?
- Has business continuity been assessed?
- Has disaster recovery been assessed?
- Has service availability been assessed?
- Has exit/data portability been considered?
- Are contractual security requirements defined?
- Are evidence documents current and in scope?
- Are gaps recorded?
- Are risks assessed?
- Are corrective actions tracked?
- Is the final approval documented?
- Is reassessment performed when circumstances change?
59. ISO 27001 Connection
Cloud provider due diligence supports the organization’s risk-based management of supplier and cloud relationships.
It can provide evidence relevant to areas such as:
- Supplier relationships
- ICT supply-chain security
- Cloud-service security
- Information security in supplier agreements
- Monitoring and review of supplier services
- Supplier changes
- Information classification
- Access control
- Incident management
- Business continuity
- Data protection
- Vulnerability management
The questionnaire itself is an organizational due-diligence tool and is not a universally mandatory ISO 27001 document.
The organization should determine the appropriate questions and evidence based on its:
- Risk assessment
- ISMS scope
- Information handled
- Cloud dependency
- Access requirements
- Customer requirements
- Legal/regulatory obligations
- Contractual requirements
60. Final Cloud Provider Due Diligence Audit Trail
A complete process should demonstrate:
Cloud Provider Identified
↓
Service Defined
↓
Business Need
↓
Information Identified
↓
Criticality Determined
↓
Questionnaire Issued
↓
Provider Responses Received
↓
Evidence Collected
↓
Evidence Scope & Validity Checked
↓
Security / Privacy / Availability Review
↓
Findings Identified
↓
Cloud Security Risk Assessment
↓
Risk Treatment / Additional Controls
↓
Contractual Requirements
↓
Approval
↓
Cloud Service Onboarding
↓
Ongoing Monitoring
↓
Periodic Reassessment
61. Final Principle
A strong Cloud Provider Due Diligence Questionnaire should not ask only:
“Is the cloud provider secure?”
It should establish:
Who is the provider? → What service are we buying? → What information will they handle? → Where will it be processed? → Who can access it? → What controls does the provider operate? → What controls remain our responsibility? → What evidence supports their claims? → What risks remain? → What contractual protections are required? → How will we monitor the provider after onboarding?
The objective is to make the provider assessment evidence-based, risk-based, and connected to the organization’s actual cloud usage, rather than treating a completed questionnaire or certification as automatic proof of security.