THE CONTROL BOUNDARY CHANGES
Moving a service to the cloud changes who operates each layer
A cloud provider secures contracted platform components. The customer still makes decisions about identity, data, applications, configuration, monitoring and recovery. The exact division depends on the service and deployment model.
"Responsibility should be documented at control level, not assumed from the contract."
Identity and access
The customer remains responsible for its users, administrators, service identities and access decisions.
Configuration
Security depends on how accounts, services, storage, networks and workloads are configured.
Applications and data
The organisation controls the code, information and business processes placed in the service.
Monitoring and response
Provider logs and notifications must connect with the customer's investigation and response process.
Resilience and recovery
Provider availability does not replace customer recovery planning, data protection and dependency testing.
RESPONSIBILITY VARIES BY SERVICE MODEL
Know which controls remain with your organisation
Use the model as an illustrative guide. The actual boundary must be confirmed through service documentation, architecture and contract terms.
NIST's cloud reference architecture defines cloud actors and their roles, providing a useful basis for discussing responsibility. NIST Cloud Computing Reference Architecture
| Responsibility layer | Infrastructure as a service | Platform as a service | Software as a service |
|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider |
| Platform services | Shared | Provider | Provider |
| Workloads and applications | Customer | Customer | Contract-dependent |
| Identity and configuration | Customer | Customer | Customer |
| Data and business use | Customer | Customer | Customer |
KNOW THE CLOUD ESTATE
A useful inventory includes purpose, ownership and dependency
A list of cloud accounts shows what exists. Security decisions also require the business purpose, responsible owner, data, external exposure and service dependency for each environment.
| Account or service | Business owner | Environment | Data classification | External exposure | Recovery priority |
|---|---|---|---|---|---|
| Production | Platform team | Production | Confidential | Partial | Critical |
| Development | Engineering | Non-production | Internal | None | Standard |
| Shared services | Infrastructure | Shared | Internal | None | High |
| Data platform | Data team | Production | Restricted | None | Critical |
PRIORITY EXPOSURES
Cloud risk is shaped by identity, configuration and rapid change
Compromised cloud identity
A stolen administrator, developer or workload credential may provide access to multiple cloud services and data sources.
Unsafe configuration
Public exposure, excessive permissions or weak service settings can create paths into critical workloads and information.
Unmanaged service accounts
Long-lived keys and poorly governed machine identities can retain broad access.
Exposed data stores
Incorrect access policies may expose sensitive files, backups, logs or databases.
Insecure management interfaces
Administrative services may be reachable through insufficiently protected paths.
Workload vulnerabilities
Images, packages, code and runtime configuration may introduce exploitable weaknesses.
Missing telemetry
Incomplete or unavailable logs can delay detection and investigation.
Provider concentration
Several critical services may depend on one platform, region or identity service.
ESTABLISH A GOVERNED FOUNDATION
Separate responsibility and risk through account structure
Organisation or tenant
Defines identity integration, policy boundaries, billing, service restrictions and central administration.
Security
Holds agreed security services, delegated access and controlled security administration.
Logging
Receives protected audit and security events according to retention requirements.
Shared services
Provides approved network, identity, deployment or operational capabilities.
Production
Runs live customer or business services within tighter access and change controls.
Non-production
Supports development and testing without providing an uncontrolled route into production.
Sandbox
Allows approved experimentation with clear data, access, spending and connectivity restrictions.
IDENTITY IS THE PRIMARY CONTROL PLANE
Limit human and machine access according to need
Cloud access decision
Central control point
Workforce users
Privileged administrators
Developers and engineers
Workload identities
External support providers
CONTROL REACHABILITY
Make every public and administrative path intentional
Public access
Internet-facing gateways, applications, APIs and approved public services.
Application services
Internal workloads, service communication and shared application components.
Restricted services
Sensitive databases, management services, secrets and critical processing.
Management and support access
Administrator, developer, automation and third-party access paths.
PROTECT DATA THROUGHOUT CLOUD USE
Know where information moves, rests and leaves
Question
How does data reach the cloud environment?
Control direction
Approved transfer, validation, identity and encryption
Question
Which services, regions and replicas contain the information?
Control direction
Inventory, classification, access, encryption and configuration
Question
Which users, workloads and external services can use it?
Control direction
Role and workload permissions, secrets and activity monitoring
Question
Can information leave through links, integrations, APIs or exports?
Control direction
Controlled sharing, egress policy and third-party review
Question
How are copies, snapshots, archives and backups handled?
Control direction
Retention, secure deletion and recovery governance
SECURE THE WORKLOAD LIFECYCLE
Protect what is built, deployed and operated
Source and dependencies
Review repositories, third-party components, secrets and developer access.
Build process
Protect automation, build identities, runners and generated artefacts.
Image or package
Assess provenance, vulnerabilities, integrity and approved storage.
Deployment configuration
Validate permissions, network exposure, secrets and resource policies.
Runtime
Monitor behaviour, administrative activity, network connections and security events.
Cloud workload security requires coordination between development, platform, infrastructure and security teams. Ownership should be documented for each lifecycle stage.
Assess Cloud-Native WorkloadsCONTROL CLOUD CHANGE BEFORE DEPLOYMENT
Use repeatable configuration with accountable review
Define
Document the intended architecture, owner and control requirements.
Build
Create configuration through approved repositories and reusable components.
Review
Check access, network exposure, data handling and policy compliance.
Test
Validate configuration and expected security behaviour.
Deploy
Use controlled identities, approvals and protected pipelines.
Monitor
Detect drift, unauthorised change and control failure.
CONSISTENCY WITHOUT FALSE UNIFORMITY
Set common outcomes across different cloud platforms
Cloud services differ in architecture and terminology. A common control model should define required outcomes while allowing platform-appropriate implementation.
| Control band | Cloud environment A | Cloud environment B | SaaS and external cloud services |
|---|---|---|---|
| Identity | Define consistent authentication, privilege and lifecycle requirements. | ||
| Policy | Set minimum requirements for exposure, data, encryption, workload and administrative controls. | ||
| Logging | Identify required events while respecting platform-specific capabilities. | ||
| Incident response | Maintain a common escalation and decision process across provider boundaries. | ||
VISIBILITY INTO THE CLOUD CONTROL PLANE
Monitor the actions that can change access and exposure
Cloud event
- ·Administrative sign-in
- ·Privilege change
- ·Policy update
- ·New public service
- ·Data access change
- ·Workload deployment
- ·Security-control change
Context
- ·Identity
- ·Asset
- ·Environment
- ·Business owner
- ·Data sensitivity
- ·Approved change
Detection
- ·Unexpected privilege
- ·Unapproved exposure
- ·Suspicious identity use
- ·Logging interruption
- ·Configuration drift
- ·High-risk data activity
Response
- ·Validate
- ·Restrict access
- ·Reverse change
- ·Isolate workload
- ·Preserve evidence
- ·Escalate
PREPARE FOR CLOUD-SPECIFIC DECISIONS
Respond across identities, services, data and provider boundaries
Establish facts
- ·Identify affected accounts
- ·Confirm identities and roles
- ·Preserve cloud events
- ·Determine affected services and data
Restrict access
- ·Revoke compromised sessions
- ·Disable exposed credentials
- ·Limit privileged roles
- ·Protect emergency access
Contain the environment
- ·Restrict public exposure
- ·Isolate affected workloads
- ·Preserve snapshots where appropriate
- ·Coordinate with the cloud provider
Restore and improve
- ·Validate configuration and data
- ·Rebuild through trusted processes
- ·Restore by service priority
- ·Monitor for renewed activity
PRESERVE CLOUD EVIDENCE BEFORE IT IS NEEDED
Forensic readiness must account for provider and service limitations
Identity events
Authentication, privilege and account lifecycle records.
Administrative activity
Configuration, policy and resource-management actions.
Workload evidence
Runtime events, images, snapshots and application records.
Network evidence
Approved flow, gateway, DNS and security-service records.
Provider evidence
Service notifications, support records and contracted evidence access.
NIST's Cloud Computing Forensic Reference Architecture identifies forensic challenges and mitigation considerations within cloud environments. NIST cloud forensic reference architecture
Evidence access and retention vary by cloud service and subscription. Required evidence should be identified before an incident occurs.
DESIGN FOR SERVICE FAILURE
Cloud availability does not replace recovery planning
Critical cloud service
Identity
Determine whether the organisation can administer and recover the service if the primary identity system is unavailable.
Region and platform
Understand the service's dependence on locations, provider capabilities and central platform components.
Data and backup
Confirm recovery sources, access, integrity, retention and restoration time.
External integrations
Identify suppliers, APIs, networks and services required for recovery.
ASSESS THE PROVIDER AND THE DEPLOYMENT
External assurance covers only part of the cloud risk
Provider evidence
- ·Independent assurance reports
- ·Service architecture
- ·Security responsibilities
- ·Data locations
- ·Subprocessors
- ·Incident notification
- ·Resilience
- ·Exit support
Your implementation
- ·Service configuration
- ·Identity and privilege
- ·Data use
- ·Application security
- ·Logging
- ·Recovery
- ·Connected providers
- ·Operating ownership
CLOUD ASSURANCE WITH CONTEXT
Map cloud controls to applicable obligations
Applicable requirements depend on the service, data, customers, industry and jurisdictions involved. Digisecuritas helps organisations connect framework requirements with cloud responsibilities, working controls and evidence.
The Cloud Security Alliance's Cloud Controls Matrix provides a cloud-specific, vendor-neutral control framework that can support assessment and responsibility mapping. CSA Cloud Controls Matrix
Framework alignment does not confirm that every cloud service or configuration is secure. Requirements must be assessed against the organisation's actual environment.
INDEPENDENT CLOUD SECURITY SUPPORT
Assess architecture, validate controls and improve cloud operations
Cloud security assessment
Develop an evidence-based view of cloud architecture, identity, configuration, data, workloads, monitoring and resilience.
Cloud architecture review
Assess account structure, trust boundaries, connectivity and control ownership.
Cloud configuration assessment
Review approved services, policies, exposure and security settings.
Cloud penetration testing
Validate exploitable weaknesses within an authorised provider-compliant scope.
Cloud identity assessment
Review human and workload access, privilege, credentials and emergency controls.
Container security assessment
Assess build, image, deployment, orchestration and runtime controls.
DevSecOps review
Review repositories, pipelines, infrastructure as code, secrets and release controls.
Cloud data security assessment
Map data, access, encryption, sharing, retention and recovery.
Cloud incident readiness
Develop logging, response, evidence and recovery procedures.
Multi-cloud governance review
Define common control outcomes and accountable platform ownership.
A CLEAR WORKING METHOD
Move from cloud context to validated improvement
Understand
Discuss cloud services, business priorities, data and operating responsibilities.
Discover
Build the inventory of accounts, services, owners, identities and exposure.
Map
Document architecture, trust boundaries, data flows and provider responsibilities.
Validate
Review evidence and conduct approved technical testing.
Prioritise
Rank findings by exposure, consequence and remediation dependency.
Improve
Support remediation, target architecture and validation of completed work.
OUTPUTS TEAMS CAN USE
Cloud findings presented for decision and implementation
Executive cloud-risk summary
Key exposure, business dependencies and decisions requiring leadership attention.
Cloud architecture map
Accounts, services, trust boundaries, identities and important data flows.
Technical findings report
Verified configuration, identity, workload, data and monitoring findings.
Shared-responsibility matrix
Control ownership across the organisation and cloud providers.
Remediation roadmap
Priorities, owners, dependencies and validation criteria.
Retest record
Results of agreed remediation verification.
Final deliverables must be confirmed during scoping.
Common reasons to assess cloud security
Cloud security advice should remain independent of the platform decision
Digisecuritas assesses cloud controls against architecture, data, business dependency and operating evidence. Recommendations are not tied to cloud or security-product resale targets.
Provider-neutral perspective
Security outcomes guide recommendations across cloud platforms.
Architecture depth
Identity, data, workloads, networks and operations are assessed together.
Independent validation
Findings are supported by evidence and approved technical testing.
Practical remediation
Recommendations identify ownership, dependency and validation conditions.
FREQUENTLY ASKED QUESTIONS
Cloud security questions
Common questions about cloud security assessments and advisory services.
START WITH THE CLOUD SERVICES THAT MATTER MOST
Strengthen cloud security with clear ownership and tested controls
Tell us which environments, workloads and data require greater assurance. Digisecuritas will help you define a focused assessment and a practical route forward.
Independent cloud security guidance for public cloud, hybrid, multi-cloud and cloud-native environments.