Skip to content

Publication Summary

Title Cloud Architecture Policy
Author(s)
Issued by CEO

Version doc.

Review freq.

0.1

Yearly
Date of issue November 13, 2023
Owner Alessandro Cardinali
Document status Draft – Final Draft - Final
Approval Date n/a
Classification Internal

Change Log

Version Date Author Comments
0.1 November 13, 2023 First draft Information Security Policy

Table of Contents

1 Publication Summary 2

  • 5.2 Policy

  • A.5 Organizational controls

  • A.5.1 Policies for information security

0. Introduction

This policy supports the following ISMS controls:

  • A.nr.nr.nr (Change management)

  • A.nr.nr.nr (Secure development policy)

  • A.nr.nr.nr (Supplier/vendor risk management)

  • A.nr.nr.nr (Privacy and data protection)

It is maintained as part of the ISMS documentation set and reviewed annually during the ISMS cycle.

Security Objectives Addressed:

  • Maintain availability and recoverability of systems through portable, reproducible architecture.

  • Reduce supplier lock-in risk by preferring open standards and vendor-neutral designs.

  • Enable secure transitions between cloud platforms as part of our continuity strategy.

0.1 Purpose

This document defines our strategic approach to cloud architecture, guiding the selection and usage of cloud services across different providers. It supports our flexible, cost-conscious operating model while aiming to minimize vendor lock-in and ensure long-term portability and security compliance.

1.0 Guiding Principle: Portability-First

We default to open standards and portable technologies to preserve our ability to migrate services across cloud platforms with minimal effort.

1.1 Preferred Technologies

  • Open-source databases

  • Containerized workloads

  • Platform-agnostic APIs (e.g., REST/gRPC)

  • Infrastructure-as-Code (e.g., Terraform or equivalent)

1.2 Vendor-Specific Usage Criteria

Cloud-native services specific to a single provider may be used only when:

  • They offer a clear, measurable advantage over portable alternatives.

  • The service is non-core and can be isolated (e.g., caches, queues, batch jobs).

  • The service is encapsulated within an abstraction layer or service boundary.

All uses of provider-specific services must include documented justification and migration considerations.

3. Multi-Cloud Continuity

The architecture should support service portability and continuity across providers where practical.

3.1 Requirements

  • Infrastructure must be reproducible via declarative tooling.

  • Workloads should be deployable across compliant environments.

  • Equivalent services must be identified or mapped to allow for future migration.

4. Shared vs. Isolated Services

  • Centralized resources may be used for multi-tenant or core infrastructure.

  • Supporting services or microservices should be independently deployable and self-contained.

5. Cost-Driven Flexibility

Temporary use of provider-specific services for development, testing, or prototyping is acceptable under these conditions:

  • It does not introduce long-term dependencies without review.

  • A clear migration or decommissioning plan is documented.

6. Decision Governance

All significant cloud architecture decisions must address:

  1. Does this create dependency on a specific provider?

  2. What open or portable alternatives exist?

  3. What is the business or technical justification?

  4. Can the dependency be isolated?

  5. Is there an exit or migration strategy documented?

All such decisions must be recorded using an appropriate decision record framework.

7. Review and Compliance

  • This policy is reviewed quarterly.

  • Exceptions must be documented and approved by the architecture lead or ISMS authority.