1. Purpose
The Cloud Services Register is a centralized record of cloud services used by the organization to store, process, transmit, host, monitor, develop, secure, or manage organizational information and business operations.
The register provides visibility into:
- Which cloud services are being used
- Who provides them
- Why they are being used
- What information they process
- Who can access them
- How critical they are
- What security risks they present
- What security controls apply
- Whether they have been assessed and approved
- When they must be reviewed
The register supports effective cloud governance, supplier management, information-security risk management, access management, business continuity, and ISO 27001 audit readiness.
2. Scope
The register should include relevant cloud services such as:
- IaaS platforms
- PaaS platforms
- SaaS applications
- Cloud databases
- Cloud storage
- Cloud networking
- Cloud identity services
- Cloud security services
- Cloud backup services
- Cloud monitoring services
- Cloud development platforms
- CI/CD platforms
- Cloud-hosted applications
- Container platforms
- Serverless platforms
- Cloud APIs
- AI/ML cloud services
- Cloud-based collaboration tools
- Cloud-based HR, finance, CRM, support, and business applications
Not every minor online service necessarily requires the same level of registration. The organization should define the threshold based on risk, information handled, business importance, access, and contractual or regulatory requirements.
3. Core Principle
The register should answer:
What cloud service do we use → why do we use it → who provides it → what information does it handle → who can access it → how critical is it → what risks exist → what controls apply → who approved it → when was it last reviewed?
4. Cloud Services Register – Main Fields
| Field | Description |
|---|---|
| Cloud Service ID | Unique identifier |
| Cloud Service Name | Name of the service |
| Provider | Cloud service provider |
| Service Type | IaaS / PaaS / SaaS / Other |
| Service Category | Hosting / Storage / CRM / Security / Development etc. |
| Business Purpose | Why the service is used |
| Business Process | Business process supported |
| Business Owner | Person responsible for business use |
| Technical Owner | Person responsible for technical management |
| Supplier ID | Link to Supplier Register |
| Critical Supplier | Yes / No |
| Criticality | Low / Medium / High / Critical |
| Environment | Production / Test / Development / Corporate |
| Application/System | Related application or system |
| Information Processed | Type of information handled |
| Information Classification | Classification applicable to information |
| Customer Data | Yes / No |
| Personal Data | Yes / No |
| Sensitive Data | Yes / No |
| Data Location | Country/region where applicable |
| User Population | Employees / Customers / Suppliers / Public |
| Administrative Access | Yes / No |
| Privileged Access | Yes / No |
| Production Access | Yes / No |
| Authentication | SSO / MFA / Password / API etc. |
| Encryption | Applicable encryption controls |
| Integration | Key integrations |
| Subprocessors | Yes / No / Details |
| Contract Status | Active / Pending / Expired |
| DPA Required | Yes / No / N/A |
| Security Assessment | Completed / Pending / Not Required |
| Risk Assessment | Completed / Pending |
| Risk Rating | Current risk rating |
| Security Assurance | ISO 27001 / SOC 2 / Other |
| Backup | Applicable backup arrangement |
| Recovery Requirement | RTO/RPO where applicable |
| Monitoring | Security/service monitoring |
| Incident Requirement | Notification requirement |
| Exit Plan | Available / Not Required / Pending |
| Approval Status | Approved / Pending / Rejected |
| Approval Date | Date approved |
| Go-Live Date | Date service became operational |
| Last Review Date | Most recent review |
| Next Review Date | Planned review |
| Review Frequency | Annual / Periodic / Risk-based |
| Current Status | Active / Suspended / Retired |
| Evidence Location | Reference to supporting evidence |
| Remarks | Additional information |
5. Cloud Service Identification
Each cloud service should have a unique identifier.
Example:
CLOUD-001 – AWS Production Environment
CLOUD-002 – GitHub Enterprise
CLOUD-003 – Customer Support SaaS
CLOUD-004 – Microsoft 365
The identifier should remain stable even if the service is reviewed multiple times.
6. Cloud Service Provider
Record the organization providing the service.
Examples:
- Amazon Web Services
- Microsoft Azure
- Google Cloud
- GitHub
- Microsoft 365
- Salesforce
- Datadog
- Cloudflare
- Auth0
- Stripe
The provider should also be linked to the organization’s Supplier Register where supplier management is applicable.
7. Cloud Service Type
Classify the service according to its primary cloud model.
IaaS
Examples:
- Virtual machines
- Cloud networking
- Virtual storage
PaaS
Examples:
- Managed databases
- Application platforms
- Serverless platforms
SaaS
Examples:
- CRM
- HR platform
- Collaboration platform
- Customer-support system
Other
Where the service does not fit neatly into the organization’s defined categories.
8. Business Purpose
Clearly document why the organization uses the cloud service.
Example:
AWS is used to host the organization’s customer-facing SaaS application, application database, object storage, monitoring, security services, and backup infrastructure.
Avoid descriptions such as:
“IT service.”
The purpose should explain the actual business dependency.
9. Business Process and Application
Record the business process and systems dependent on the cloud service.
Example:
| Cloud Service | Business Process | Application |
|---|---|---|
| AWS | SaaS Service Delivery | Customer SaaS Platform |
| GitHub | Software Development | Application Source Code |
| Stripe | Payment Processing | Billing Platform |
| Zendesk | Customer Support | Support Platform |
This helps connect cloud services to the organization’s asset and dependency management processes.
10. Information Processed
Document the types of information handled by the service.
Examples:
- Customer account information
- Employee information
- Application data
- Source code
- Financial information
- Security logs
- Support tickets
- Authentication information
- Business documents
- Personal data
Where possible, link the information to the organization’s information classification scheme.
11. Information Classification
Record the highest applicable classification.
Example classification:
| Classification | Example |
|---|---|
| Public | Public website content |
| Internal | Internal operational information |
| Confidential | Business/customer information |
| Restricted | Highly sensitive information |
These labels are examples and should be aligned with the organization’s approved classification scheme.
12. Customer and Personal Data
The register should identify whether the cloud service handles:
- Customer data
- Employee data
- Personal data
- Sensitive personal data where applicable
- Financial information
- Authentication information
- Security information
Where personal data is processed, the organization should also consider applicable privacy requirements and related records such as the RoPA and DPA.
13. Data Location
Record the applicable cloud hosting or processing location where relevant.
Example:
Primary Region: AWS Mumbai
Backup Region: AWS Singapore
The organization should consider:
- Contractual requirements
- Customer requirements
- Privacy obligations
- Regulatory requirements
- International data transfers
- Business continuity requirements
Do not assume that the location of the primary application automatically represents all locations where data may be processed.
14. Access Information
Record whether the cloud service provides:
- Employee access
- Customer access
- Supplier access
- Administrative access
- Production access
- Privileged access
- API access
- Machine-to-machine access
Where appropriate, link the service to the organization’s access-management records.
15. Authentication
Record the primary authentication mechanism.
Examples:
- SSO
- MFA
- Password authentication
- Federated identity
- API key
- Service account
- Certificate-based authentication
For sensitive or privileged cloud services, the organization should verify that appropriate authentication controls are implemented.
16. Criticality
The organization should assign a risk-based criticality classification.
Example:
Low
Limited business impact if unavailable or compromised.
Medium
Important service with manageable business impact.
High
Significant operational, customer, security, or compliance impact.
Critical
Failure, compromise, or unavailability could significantly affect critical business operations, customers, sensitive information, regulatory obligations, or service delivery.
These categories are organizational examples rather than universal ISO classifications.
17. Security Assessment
Record whether the cloud service has undergone an appropriate security assessment.
Possible status:
- Completed
- In Progress
- Not Started
- Not Required
- Expired
- Reassessment Required
Supporting evidence may include:
- Cloud security assessment
- Supplier due diligence
- Security questionnaire
- ISO certificate
- SOC report
- Penetration-test evidence
- Security architecture
- Configuration assessment
- Contract review
- DPA review
18. Risk Assessment
The register should identify whether the cloud service has been subject to an appropriate risk assessment.
Example:
Risk: Unauthorized privileged access to production cloud resources.
Impact: High
Likelihood: Medium
Risk: High
Treatment: MFA, least privilege, privileged-access review, logging, monitoring, and periodic access review.
The organization’s approved risk methodology should be used rather than creating a separate scoring method solely for this register.
19. Security Assurance
Record relevant assurance provided by the cloud provider.
Examples:
- ISO/IEC 27001 certification
- SOC 1 report
- SOC 2 report
- PCI DSS
- Independent penetration testing
- Other relevant assurance
Record:
- Assurance type
- Scope
- Provider/entity covered
- Reporting/certification period
- Expiry date where applicable
- Exceptions or limitations
- Review status
A provider’s certification should not be treated as automatically proving that the organization’s own cloud environment is securely configured.
20. Contract and DPA
Record contractual status.
Example:
| Requirement | Status |
|---|---|
| Contract | Active |
| NDA | Active |
| Security Addendum | Active |
| DPA | Active |
| SLA | Active |
| Subprocessor Terms | Reviewed |
| Exit Requirements | Defined |
The exact requirements should depend on the service, data, risk, and applicable legal/contractual obligations.
21. Backup and Recovery
For important cloud services, record:
- Backup required?
- Backup frequency
- Backup location
- Retention
- Encryption
- Recovery responsibility
- RTO
- RPO
- Recovery testing status
Example:
AWS RDS: Daily automated backups with defined retention and periodic recovery testing.
22. Monitoring
Record how the service is monitored.
Examples:
- Security monitoring
- Availability monitoring
- Authentication monitoring
- Administrative activity monitoring
- Configuration monitoring
- Vulnerability monitoring
- Provider security alerts
- SLA monitoring
Critical cloud services should generally have stronger monitoring arrangements than low-risk services.
23. Subprocessors
Where applicable, record whether the cloud provider uses subprocessors.
Capture relevant information such as:
- Subprocessor name
- Service provided
- Information processed
- Processing location
- Approval/review status
- Change-notification mechanism
This can be linked to the organization’s Subprocessor Review Checklist.
24. Exit and Migration
For important cloud dependencies, document whether an exit or migration arrangement exists.
Consider:
- Data export
- Backup availability
- Data portability
- Alternative provider
- Migration complexity
- Contract termination
- Data deletion
- Credential revocation
- Application dependency
- Customer impact
For critical cloud services, exit planning should be proportionate to the business dependency.
25. AWS SaaS Example
A startup operates a customer-facing SaaS platform on AWS.
Example Register Entry
| Field | Example |
|---|---|
| Cloud Service ID | CLOUD-001 |
| Service | AWS Production Environment |
| Provider | Amazon Web Services |
| Type | IaaS/PaaS |
| Purpose | Host customer SaaS platform |
| Business Process | SaaS Service Delivery |
| Owner | CTO |
| Criticality | Critical |
| Environment | Production |
| Information | Customer/application data |
| Classification | Confidential |
| Customer Data | Yes |
| Personal Data | Yes |
| Production Access | Yes |
| Privileged Access | Yes |
| Authentication | IAM + MFA |
| Database | Amazon RDS |
| Storage | Amazon S3 |
| Logging | CloudTrail |
| Monitoring | CloudWatch |
| Encryption | AWS KMS |
| Web Protection | AWS WAF |
| Risk Assessment | Completed |
| Supplier Assessment | Completed |
| Contract | Active |
| Backup | Enabled |
| Recovery Testing | Periodic |
| Security Review | Completed |
| Status | Active |
The register does not need to contain every individual AWS resource. Detailed resource inventories can be maintained separately where necessary.
26. Recommended Register Structure
For a startup or growing SaaS organization, a spreadsheet or GRC system can use the following tabs:
Tab 1 – Cloud Services Register
Central inventory of all cloud services.
Tab 2 – Cloud Risk Assessment
Detailed risks associated with important cloud services.
Tab 3 – Cloud Access Review
User, privileged-access, production-access, and service-account reviews.
Tab 4 – Security Assurance Tracker
ISO certificates, SOC reports, penetration-test evidence, and other assurance.
Tab 5 – Cloud Findings & Actions
Security findings, corrective actions, owners, due dates, and closure evidence.
Tab 6 – Cloud Review Schedule
Upcoming security, supplier, access, and risk reviews.
Tab 7 – Cloud Exit & Dependency
Critical dependencies, alternatives, migration considerations, and recovery arrangements.
27. Review Frequency
Review frequency should be risk-based.
Example:
| Criticality | Example Review Approach |
|---|---|
| Low | Annual or risk-based |
| Medium | Periodic/annual |
| High | More frequent security and access review |
| Critical | Enhanced monitoring and formal periodic review |
Additional review should be triggered by events such as:
- Security incident
- Data breach
- Major vulnerability
- Significant architecture change
- New sensitive information
- New production access
- New subprocessor
- Data-location change
- Provider ownership change
- Contract renewal
- Assurance expiry
- Significant service outage
- Increased business dependency
These frequencies are examples and should be aligned with the organization’s risk methodology.
28. Roles and Responsibilities
Business Owner
Responsible for:
- Business purpose
- Business criticality
- Continued business need
- Business approval
Technical Owner
Responsible for:
- Technical configuration
- Security controls
- Availability
- Technical monitoring
Information Security
Responsible for:
- Security requirements
- Risk assessment support
- Security review
- Monitoring security risks
- Audit evidence
Procurement / Vendor Management
Responsible for:
- Supplier records
- Contract status
- Supplier due diligence
- Renewal monitoring
Privacy / Legal
Where applicable, responsible for:
- Privacy assessment
- DPA
- Data-processing requirements
- Transfer requirements
- Contractual requirements
29. Evidence to Retain
Depending on risk, evidence may include:
- Cloud service approval
- Cloud risk assessment
- Supplier due diligence
- Security questionnaire
- Security architecture
- IAM/access review
- Configuration assessment
- Security assurance reports
- ISO certificates
- SOC reports
- Penetration-test reports
- DPA
- Security addendum
- Backup/recovery evidence
- Monitoring records
- Incident records
- Change records
- Subprocessor review
- Exit/migration assessment
- Periodic review records
Do not store passwords, API keys, private keys, tokens, or other secrets in the register.
30. Relationship With Other ISMS Documents
| ISMS Document | Relationship |
|---|---|
| Cloud Security Policy | Defines cloud-security requirements |
| Asset Register | Identifies assets supported by cloud services |
| Supplier Register | Identifies cloud providers as suppliers |
| Critical Supplier Register | Identifies critical cloud providers |
| Supplier Risk Assessment | Assesses supplier-related risk |
| ICT Dependency Register | Records business dependency on cloud technology |
| Risk Register | Records significant cloud risks |
| Access Register | Records relevant user access |
| Vulnerability Register | Tracks cloud vulnerabilities |
| Incident Register | Records cloud-related incidents |
| Business Continuity Plan | Addresses cloud-service disruption |
| Backup Policy | Defines cloud backup requirements |
| Change Management | Controls significant cloud changes |
| Subprocessor Review | Assesses relevant downstream providers |
| DPA | Addresses applicable personal-data processing |
31. Common Mistakes
Mistake 1: Only listing AWS
A company may list “AWS” but fail to identify what AWS services are actually being used.
Better: Record the cloud service/business dependency while maintaining detailed technical inventories separately.
Mistake 2: No owner
A service exists but nobody is responsible for reviewing it.
Better: Assign a business and technical owner.
Mistake 3: No information classification
The register says “customer data” but does not identify its sensitivity.
Better: Link the service to the organization’s information-classification scheme.
Mistake 4: Certification treated as risk assessment
A cloud provider has ISO 27001 certification, so the organization assumes no further assessment is needed.
Better: Consider both provider assurance and the organization’s actual use/configuration.
Mistake 5: No access information
The register identifies the service but not who can administer it.
Better: Link cloud services to IAM and privileged-access reviews.
Mistake 6: Register becomes outdated
New SaaS services are adopted without updating the register.
Better: Connect the register to procurement, supplier onboarding, technology onboarding, and change-management processes.
Mistake 7: No retirement process
Old cloud services remain listed as active.
Better: Update the register when services are replaced, discontinued, or offboarded.
32. Internal Audit Checklist
An auditor may verify:
- Is there a maintained Cloud Services Register?
- Are significant cloud services identified?
- Does each service have an owner?
- Is the business purpose documented?
- Is the provider identified?
- Is the service type identified?
- Is information processed documented?
- Is information classification identified?
- Is customer/personal data identified?
- Is data location understood where relevant?
- Is production/privileged access identified?
- Has the service been risk assessed where required?
- Has supplier due diligence been completed?
- Are applicable contracts and DPAs in place?
- Is relevant security assurance reviewed?
- Are critical services identified?
- Are backups/recovery arrangements understood?
- Is security monitoring defined?
- Are subprocessors considered?
- Are significant changes tracked?
- Are periodic reviews performed?
- Are retired services removed or marked accordingly?
- Can supporting evidence be produced?
33. ISO 27001 Connection
The Cloud Services Register supports the organization’s risk-based management of cloud services and can provide evidence for processes related to:
- Cloud-service security
- Asset management
- Access control
- Supplier relationships
- ICT supply-chain security
- Information classification
- Configuration management
- Logging and monitoring
- Vulnerability management
- Backup
- Business continuity
- Change management
- Incident management
The register itself is an organizational management record, not a universally prescribed ISO 27001 document.
The organization should determine what must be recorded based on its ISMS scope, risk assessment, applicable controls, legal/regulatory requirements, contractual obligations, and operational needs.
34. Final Cloud Services Audit Trail
A well-maintained register should connect:
Cloud Service Identified
↓
Business Purpose
↓
Provider Identified
↓
Information Identified
↓
Classification
↓
Access Identified
↓
Criticality
↓
Supplier / Security Assessment
↓
Risk Assessment
↓
Security Requirements
↓
Approval
↓
Implementation
↓
Monitoring
↓
Periodic Review
↓
Risk Reassessment
↓
Change / Incident Management
↓
Renewal or Offboarding
↓
Register Updated
35. Final Principle
The Cloud Services Register should not become just a list of software subscriptions.
Its real purpose is to provide security visibility and accountability:
What cloud services do we use? → Why do we use them? → What information do they handle? → Who provides them? → Who can access them? → How critical are they? → What risks exist? → What controls protect them? → Who approved them? → When were they last reviewed?
That traceability turns the register from a simple inventory into a useful ISO 27001 cloud-governance and audit-evidence record.