Cloud & Infrastructure Security Policy¶

Purpose. Define how Soon secures its cloud infrastructure. Soon has no offices, no corporate network, and no on-premise servers: all production infrastructure runs in AWS eu-west-1, so this policy addresses cloud network and infrastructure security only.

1. Scope¶

All Soon production and non-production infrastructure in AWS (eu-west-1) and supporting platform services (Netlify). Applies to everyone who administers this infrastructure. Out of scope: employee home networks (see the Remote Working Policy) and endpoint devices (see the Device Management Policy).

2. Policy¶

2.1 Network segmentation¶

Production workloads must run inside an AWS VPC, segmented into subnets by function. Databases and other data stores must sit in private subnets with no direct public access.
Security groups must follow least privilege: only the ports and sources a service needs, no default allow-all rules. 0.0.0.0/0 ingress is permitted only for public HTTPS endpoints (443).
Production and non-production environments must be separated (separate accounts or VPCs). Current structure (confirmed 2026-08-22): an AWS Organization with a management account, the production account, and a dedicated log-archive account 404379474355 (Soon-LogArchive) in a Security OU carrying the evidence store, the organisation CloudTrail destination and the isolated backup vault, protected by the ProtectSecurityLogs service control policy. Development runs in its own environment (rds-soon-soon-dev); the legacy Azure development environment is being decommissioned.

2.2 Tenant isolation¶

Customer data in the multi-tenant SaaS must be logically isolated per tenant at the application and database layer. Tenant isolation controls must be covered by code review and testing (see the Secure Development Policy).

2.3 Encryption in transit¶

All traffic — customer-facing, internal service-to-service where supported, and administrative — must use TLS 1.2 or higher. Plaintext protocols must not be exposed publicly.

2.4 Administrative access¶

Access to the AWS console and APIs requires MFA; SSO is used where supported. Access follows the Access Control Policy (least privilege, role-based, reviewed periodically).
There is no VPN or corporate network: administrative access is direct to cloud provider consoles/APIs over TLS from managed endpoints.

2.5 Change and monitoring¶

Infrastructure changes must follow the Change Management Process and, where codified, be made through version-controlled infrastructure-as-code with PR review. Current IaC coverage (SoonHQ/soon-terraform, verified 2026-08-22): VPC, subnets and routing; security groups; ECS/Fargate clusters, services and task definitions; ALB and listeners; ECR with lifecycle policies; Lambda; Redis; SQS; scheduled tasks; secrets; GitHub OIDC roles; S3 buckets; CloudWatch log groups, alarms and event rules; and autoscaling. IAM is role-based throughout — no aws_iam_user resources. The production MySQL instance is being imported into envs/prod/stateful. Not yet codified: CloudTrail and organisation/account-level configuration, which remain console-managed and are therefore covered by the change process rather than by code review.
CloudWatch must alert on-call engineers on availability and security-relevant infrastructure events (see the Logging & Monitoring Policy).
Suspected infrastructure security incidents must be reported per the Information Security Event Reporting Procedure.

3. Roles & responsibilities¶

Engineering team: implements and maintains VPC, security group, and TLS configuration; reviews infrastructure changes.
Security responsible: approves exceptions, reviews security group rules periodically.
AWS (shared responsibility): physical and hypervisor-level network security of the underlying cloud.

Change log¶

Version	Date	Author	Comments
0.1	2023-10-23	Olaf Jacobson	First draft document
0.2	2026-07-18	Andrea Cardinali	Rewritten lean and Soon-specific (ISMS overhaul)