diff --git a/README.md b/README.md
index 58853d1d..dc808549 100644
--- a/README.md
+++ b/README.md
@@ -40,7 +40,7 @@ The framework is a companion to:
 
 The framework consists of:
 
-* [Engineering principles](principles.md) and [blueprints](blueprints.md)
+* [Engineering principles](principles.md), [blueprints](blueprints.md) and [red lines](red-lines.md)
 * [Engineering quality review tool](insights/review.md)
 * [Communities of practice guidelines](communities/communities-of-practice.md) and active communities:
   * [Product Development Test Automation Working Group](communities/pd-test-automation-working-group.md)
diff --git a/patterns/outsource-bottom-up.md b/patterns/outsource-bottom-up.md
index 4b93ddb8..02a90112 100644
--- a/patterns/outsource-bottom-up.md
+++ b/patterns/outsource-bottom-up.md
@@ -15,6 +15,10 @@
   - [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first)
   - [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build)
 
+## Red lines
+
+This pattern relates to [**RED-LINE**](red-lines.md): All new services must be developed on public cloud
+
 ## The pattern
 
 Use managed services where available and appropriate. The aim is to reduce operational burden by handing responsibility to the cloud provider. They have made a business from doing this better than most organisations can.
diff --git a/practices/cloud-services.md b/practices/cloud-services.md
index d35a5213..75a62a31 100644
--- a/practices/cloud-services.md
+++ b/practices/cloud-services.md
@@ -48,6 +48,7 @@
   - Understand how rapidly demand can spike and ensure scaling can meet these requirements. Balance scaling needs with the desire to avoid over provisioning and use [pre-warming](https://petrutandrei.wordpress.com/2016/03/18/pre-warming-the-load-balancer-in-aws/) of judiciously where required. Discuss this with the cloud provider well before go live they can assist with pre-warming processes ([AWS](https://aws.amazon.com/premiumsupport/programs/iem/)).
 - Infrastructure should always be fully utilised (if it isn't, it's generating waste).
   - Though balance this with potential need to run with some overhead to accommodate failed instance replacement times without overloading remaining instances.
+  - [**RED-LINE**](../red-lines.md): Development and test environments must not be run 24 by 7
 - Keep up to date.
   - Services/components need prompt updates to dependencies where security vulnerabilities are found — even if they are not under active development.
   - Services which use deprecated or unsupported technologies should be migrated onto alternatives as a priority.
diff --git a/principles.md b/principles.md
index 4767a589..0ba5ec38 100644
--- a/principles.md
+++ b/principles.md
@@ -14,6 +14,8 @@
 
 Our principles guide the way we work and interact with each other. They are based on the seven Lean principles as expressed in Lean Software Development: An Agile Toolkit by Mary Poppendieck and Tom Poppendieck.
 
+A subset of these principles relate to our [red lines](red-lines.md) - these are identified by links like this: [**RED-LINE**](red-lines.md)
+
 ### 1. Eliminate waste
 
 Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value. Here are some examples, listed against the seven types of waste identified by Lean.
@@ -21,6 +23,7 @@ Waste is anything that interferes with giving customers what they really value a
 **Inventory — partially done work**, e.g. plans and designs, code. Limit work in progress (WIP) and use a pull-based approach.
 
 **[Inventory — unnecessary resources](practices/cloud-services.md)** [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
+  * [**RED-LINE**](red-lines.md): Development and test environments must not be run 24 by 7
 
 **Overproduction — building unnecessary features.** Start simple and basic, get feedback and iterate.
 
@@ -31,6 +34,7 @@ Waste is anything that interferes with giving customers what they really value a
 **Overproduction — reinventing the wheel.** Solving the same problem repeatedly in an organisation. Make sure there are effective ways to share knowledge between teams to avoid this.
 
 **[Overproduction — building when you could instead reuse or buy](practices/cloud-services.md).** [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build) Remember to consider all these alternatives.
+  * [**RED-LINE**](red-lines.md): All new services must be developed on public cloud
 
 **Overproduction — premature optimisation for reusability.** Before making something reusable, first make it usable. Prefer explicit logic to implicit. Excessively generic systems create accidental complexity. [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and the caveats in [structured code](practices/structured-code.md) again.
 
diff --git a/red-lines.md b/red-lines.md
new file mode 100644
index 00000000..29c48e65
--- /dev/null
+++ b/red-lines.md
@@ -0,0 +1,20 @@
+# Engineering red lines
+
+The engineering principles, practices and patterns in this framework provide guidance around best-practice engineering.
+
+There is a lot of this guidance - it's all important, but we consider some of these principles, and some specific practices related to them, to be especially significant and therefore mandatory requirements for the services we build: these are our engineering "red lines".
+
+We have chosen to put in place a formal governance process for any exceptions to these red lines (including how frequently any exceptions need to be re-assessed), and any changes to this central list of red lines.
+
+You will find references to the red lines throughout this framework (the references look like this: [**RED-LINE**](red-lines.md)) - and for convenience this list is the complete set of red lines.
+
+## Cloud / Infrastructure
+
+1. All new services must be developed on public cloud
+    * Red line for the principle [overproduction — building when you could instead reuse or buy](principles.md#1-eliminate-waste) and the pattern [outsource from the bottom up](patterns/outsource-bottom-up.md)
+    * Relates to the architecture principles [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first) and [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build)
+    * For further details please see [cloud services](practices/cloud-services.md)
+2. Development and test environments must not be run 24 by 7 and either need to be serverless so incur minimal charges when not being run or on demand and shutdown daily or run for less than 8 hours a day
+    * Red line for the principle [inventory — unnecessary resources](principles.md#1-eliminate-waste)
+    * Relates to the architecture principle [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services)
+    * For further details please see [cloud services](practices/cloud-services.md) ("services should scale automatically up and down", "infrastructure should always be fully utilised", etc)