On-Premises to Cloud Shift

Purpose

This module clarifies which security assumptions remain valid from on-premises operations and which must be redesigned for cloud delivery.

Compliance obligations remain in force during migration; the main change is the implementation model in cloud operations.

Key transition differences

• Boundary model: On-premises often relies on static perimeters, while cloud requires dynamic boundaries.
• Control implementation: On-premises controls are often manual, while cloud controls should be automated.
• Responsibility model: Cloud strengthens shared-responsibility patterns across platform and teams.
• Change velocity: Cloud delivery cycles require controls testable in CI and CD.

Compliance continuity and adaptation

• Same requirement, different mechanism: A requirement keeps its intent, but cloud implementation shifts toward policy-based controls and automation.
• Same audit objective, different evidence model: Evidence shifts from periodic collection to continuous generation from telemetry and audit trails.
• Same accountability, revised operating split: Enterprise accountability stays unchanged, while responsibilities are redistributed across shared-responsibility boundaries.

Typical adaptation patterns by compliance category:

• Data protection and location: Move from static infrastructure mapping to service-level residency and access constraints.
• Identity and access: Move from network trust assumptions to identity-first and policy-enforced authorization.
• Audit and evidence: Move from manual documentation to automated evidence pipelines.
• Resilience and recovery: Move from occasional testing to continuous monitoring and scheduled recovery validation.

Practical use of certifications and attestations

• Use C5 intentionally: Treat C5 reports as evidence inputs for core control domains and migration gap assessments.
• Differentiate Type 1 and Type 2: For ongoing operating assurance, Type 2 is typically stronger than point-in-time evidence.
• Map requirement to evidence: Link each internal compliance requirement to explicit evidence from audit logs, telemetry, or attestation artifacts.
• Plan customer responsibilities: Keep customer-side responsibilities explicit for secure configuration, access governance, and protective controls.

Migration recommendations

• Map control intent, redesign implementation: Keep requirements stable and modernize controls.
• Prioritize identity and policy governance: Reduce location-based trust assumptions.
• Use reusable secure templates: Standardize onboarding for projects and workloads.
• Define transition exit criteria: Avoid temporary hybrid exceptions becoming permanent.

STACKIT references

• Customer accounts and resource structure: Customer Accounts , Organizations Folders , and Projects
• Network and hybrid connectivity: Concepts and Product Overview

Anti-patterns to avoid

• Lift-and-shift security mindset: Existing control mechanics are copied without cloud adaptation.
• Unmanaged hybrid state: Transitional exceptions become permanent architecture.
• No ownership update: Teams keep old mandates without cloud operating responsibilities.