Policy enforcement (guardrails)
Why important?
Technical enforcement of rules (ex ante) prevents non-compliant states and reduces misconfiguration.
How measured?
Scale 0–5 + N/A:
- 0 = No central guardrails / no policy enforcement mechanisms
- 1 = Manual/best effort, no enforceable policy
- 2 = Basic policies, but with gaps / without central enforcement
- 3 = Central policy enforcement (e.g. org policies/SCPs, baselines) for the core scope
- 4 = Strong guardrails + templates + integrated monitoring/remediation
- 5 = Guardrails throughout (policy as code) + continuous compliance/evidence
- N/A = no reliable evidence
Sources / Evidence
Validation questions (RFP)
- Which policies can be technically enforced (e.g. mandatory encryption, region restriction, network/egress rules)? Are there organisation-wide guardrails and exceptions?
Scores comparison
| Providers | Score | |
|---|---|---|
| AWS European Sovereign Cloud | 4.0 | |
| Oracle EU Sovereign Cloud | 4.0 | |
| Microsoft Sovereign Cloud | 4.0 | |
| STACKIT | 3.0 | |
| T Cloud Public | 3.0 | |
| Delos Cloud | 3.0 | |
| Cloud Temple Trusted Cloud | 3.0 | Console (Shiva) with IAM/RBAC. SecNumCloud requires access control. Policies configurable via the console. Guardrails implicit through SecNumCloud requirements. |
| IONOS Cloud | 2.0 | |
| OVHcloud Public Cloud (inkl. SecNumCloud) | 2.0 | |
| pluscloud open | 2.0 | |
| UpCloud | 2.0 | |
| Exoscale | 2.0 | |
| Scaleway | 2.0 | |
| noris Sovereign Cloud | 2.0 | |
| SysEleven OpenStack Cloud | 2.0 | |
| Infomaniak Public Cloud | 2.0 | OpenStack RBAC/IAM (Keystone). Project-based quotas/limits. Infomaniak Manager for user management. No organisation-wide policy guardrails (OPA/Config) documented. |
| Hetzner Cloud | 1.0 |