Merge pull request #85 from cabinetoffice/DH-83

nav change and TOC change

Author: kayrog

…inistration-min-requirements.html.md.erb …inistration-min-requirements.html.md.erbsource/docs/guidance/software/aws-administration-min-requirements.html.md.erb renamed to source/docs/cloud/aws-administration-min-requirements.html.md.erb source/docs/guidance/software/aws-administration-min-requirements.html.md.erb renamed to source/docs/cloud/aws-administration-min-requirements.html.md.erb

@@ -5,21 +5,21 @@ review_in: 6 months
 ---
 # <%= current_page.data.title %>
 
-## **1.0 Purpose**
+## Purpose
 
 This policy governs the use of cloud sandbox environments. It ensures that innovation and experimentation can happen safely, securely, and cost-effectively. It provides a clear process for managing sandboxes from creation to deletion, and for moving successful experiments towards production.
 
 This applies to both AWS and Azure accounts.
 
-## **2.0 Scope**
+## Scope
 
 This policy applies to all technical staff using or managing cloud sandbox environments on AWS, Azure and other hosting environments. This includes developers, engineers, data scientists, and architects. It also applies to anyone responsible for approving or reviewing sandbox activity, including the Head of Engineering and the Technical Design Authority (TDA).
 
 This policy covers all cloud environments designated as a 'sandbox'. A sandbox is a temporary, isolated environment for prototyping, training, or experimentation. It is not intended for hosting live services.
 
-## **3.0 Key Policies**
+## Key Policies
 
-### **3.1 Data Usage**
+### Data Usage
 
 You must not use live, production-level, sensitive data or personally identifiable information (PII) in any sandbox environment.
 
@@ -29,15 +29,15 @@ You must not use live, production-level, sensitive data or personally identifiab
 
 You must use synthetic or anonymised data for testing and development in a sandbox. 
 
-### **3.2 System Integration**
+### System Integration
 
 You must not connect a sandbox to any live production system, service, or network.
 
 All sandbox environments must be completely isolated. This prevents experimental code from affecting the stability and security of live services. It also protects production systems from potential vulnerabilities in test environments.
 
-## **4.0 Governance Process**
+## Governance Process
 
-### **4.1 Requesting a Sandbox**
+### Requesting a Sandbox
 
 To get a sandbox, you must submit a request to the Head of Engineering for approval.
 
@@ -48,13 +48,13 @@ Your request must include:
 * A justification for the experiment  
 * Estimated sandbox duration
 
-### **4.2 Budget and Timeline**
+### Budget and Timeline
 
 Your request must define a maximum budget (spend cap) and a fixed timeline (expiry date) for the sandbox.
 
 The platform team will monitor spending against your approved budget. The sandbox and all its resources will be decommissioned on the agreed expiry date. You must request a formal extension from the Head of Engineering if you need more time.
 
-### **4.3 Path to Production (TDA Approval)**
+### Path to Production (TDA Approval)
 
 You must get formal approval from the Technical Design Authority (TDA) before a project developed in a sandbox can move into production-level development.
 
@@ -65,7 +65,7 @@ To get approval, you must present the outcomes of your experiment to the TDA. Th
 * Full cost analysis for production, including running and support costs  
 * Alignment with departmental technology strategy
 
-## **5.0 Roles and Responsibilities**
+## Roles and Responsibilities
 
 **You (the sandbox user)** are responsible for:
 
@@ -90,7 +90,7 @@ The **Platform Team** is responsible for:
 * Monitoring sandbox costs and security compliance  
 * Decommissioning sandboxes on their expiry date
 
-## **6.0 Policy Violations**
+## Policy Violations
 
 Failure to comply with this policy will result in the immediate suspension or deletion of your sandbox environment.