Skip to content
Beta

Overview

In 1 trail

Last updated on

Purpose

Section titled “Purpose”

Security and Compliance define the guardrails for migration decisions across design, landing zones, and migration delivery.

The goal is to translate policy intent into enforceable controls and verifiable evidence from day 1.

Security and compliance topic map

Section titled “Security and compliance topic map”

Use this semantic map as a structured entry point into all subtopics of this module.

Swipe sideways to see the whole diagram
Security and Compliance Choose an entry point by topic cluster and jump directly to the detailed module page. Security and ComplianceChoose an entry point by topic cluster and jump directly to the detailed module page.Governance and migration operating modelOperating model and governanceOperating model and governanceRoles, checkpoints, ownership, and decisionsOn-premises to cloud shiftOn-premises to cloud shiftControl translation and responsibility shiftsSecurity architecture and design baselineArchitecture patternsArchitecture patternsBoundary-centric and Zero Trust combinationsSecurity by design baselineSecurity by design baselineMandatory baseline controls by domainCompliance assurance and sovereigntyControls and evidence pipelineControls and evidence pipelinePreventive, detective controls and evidenceDigital sovereignty and CSFDigital sovereignty and CSFCSF alignment, ES3, and auditabilityZero Trust deep dive topicsFive focused domains for implementation and controls.Zero trust peopleZero trust peopleIdentity lifecycle, privileged access, and account hygieneZero trust devicesZero trust devicesDevice posture, endpoint hardening, and secure administrationZero trust networksZero trust networksSegmentation, traffic policy, and controlled connectivityZero trust workloadZero trust workloadRuntime hardening, least privilege, and workload isolationZero trust dataZero trust dataClassification, encryption, keys, and retention controls

Why this stream must start early

Section titled “Why this stream must start early”

Security and Compliance are not a final hardening step. They shape core platform decisions from the beginning:

  • Architecture first: Trust boundaries, network models, and identity controls are expensive to retrofit later.
  • Delivery continuity: Missing mandatory controls block approvals and delay migration waves.
  • Evidence by design: Compliance evidence must be generated continuously, not reconstructed late.
  • Shared accountability: Every design stream needs Security and Compliance review to avoid local optimization and enterprise risk.

How this module supports design and landing zones

Section titled “How this module supports design and landing zones”
  • Design perspective: Define architecture patterns, control principles, and governance model.
  • Landing-zone perspective: Apply these principles to platform and application landing-zone implementation.

This module provides the cross-cutting baseline that must be used in both contexts.

On-premises to cloud security shift

Section titled “On-premises to cloud security shift”

Cloud migration changes security assumptions:

  • From static boundaries to dynamic scopes: Projects and services change faster than classic zones.
  • From manual approvals to policy enforcement: Controls must be testable and automated.
  • From isolated logs to correlated telemetry: Audit, platform, and application signals must work together.
  • From infrastructure focus to shared capabilities: Identity, keys, observability, and governance are platform-level capabilities.

Architecture approaches to combine

Section titled “Architecture approaches to combine”
  • Boundary-centric architecture: Hub-and-spoke routing, centralized firewall controls, and segmentation.
  • Zero Trust-oriented architecture: Explicit identity, strong authentication, end-to-end encryption, and least-privilege enforcement.

Most enterprise target states need both approaches with clear selection criteria per workload class.

Digital sovereignty and compliance context

Section titled “Digital sovereignty and compliance context”

For many migration programs, compliance, and digital sovereignty are primary drivers.

  • Legal and residency requirements: Region and data-location decisions influence architecture and controls.
  • Operational sovereignty goals: Governance, portability, and transparency reduce dependency risks.
  • EU Cloud Sovereignty Framework (CSF): Use CSF-oriented control and evidence mapping to structure requirements and maturity.
  • European Sovereign Stack Standard (ES3): Use ES3 as a practical maturity extension to make sovereignty posture measurable.

Compliance in migration: what stays, what changes

Section titled “Compliance in migration: what stays, what changes”

During on-premises to cloud migration, enterprise compliance obligations remain unchanged in intent.

What changes is how controls are implemented, how evidence is produced, and how operating responsibilities are distributed.

  • What stays the same: Regulatory obligations, internal policies, audit readiness, and accountable ownership.
  • What changes: Controls become more automated, evidence becomes continuous, and ownership boundaries shift across platform and product teams.

Typical compliance categories to structure migration decisions:

  • Data protection and data location: Requirements for data classes, residency, and access boundaries.
  • Identity and access governance: Requirements for role models, separation of duties, and privileged access.
  • Logging and evidence: Requirements for completeness, retention, and evidence quality.
  • Operational resilience and recovery: Requirements for availability, recovery targets, and incident readiness.
  • Supplier and contract governance: Requirements for provider controls, contractual obligations, and verifiable assurances.

How STACKIT concretely supports compliance outcomes

Section titled “How STACKIT concretely supports compliance outcomes”
  • Assured security baseline: Certified data-center operations and established security standards provide a reliable baseline for regulated workloads.
  • C5 as auditable evidence: The C5 attestation provides structured evidence across key control domains such as risk, operations, access, encryption, and incident handling.
  • Audit transparency: Test reports and documented controls support internal audit, external assurance, and enterprise risk assessment.
  • Implementation guidance: Architecture, role model, and control-mapping guidance helps teams implement compliance requirements in cloud-native ways.
  • Shared-responsibility clarity: STACKIT provides platform controls and evidence; the customer remains accountable for configuration, access governance, and data classification.

Module structure

Section titled “Module structure”

Operating Model and Governance

Define roles, decision rights, ownership, and mandatory Security and Compliance checkpoints.

Open module

Architecture Patterns

Define where boundary-centric controls remain mandatory and where Zero Trust controls are primary.

Open module

Security by Design Baseline

Define baseline requirements and recommendations for identity, network, workload, and data protection.

Open module

Controls and Evidence Pipeline

Define preventive and detective controls and automated compliance evidence generation.

Open module

On-Premises to Cloud Shift

Clarify which security assumptions and operating practices must change in cloud migration.

Open module

Digital Sovereignty and CSF Alignment

Translate sovereignty, CSF, and ES3 requirements into architecture, controls, and evidence responsibilities.

Open module