diff --git a/docs/libraries-tools/gcp-terraform/index.md b/docs/libraries-tools/gcp-terraform/index.md
index e0133b61aa772e1ffb6eb970233fcce92004787b..a1b2bed88d7ed124f04c809be6441a3c0189d621 100644
--- a/docs/libraries-tools/gcp-terraform/index.md
+++ b/docs/libraries-tools/gcp-terraform/index.md
@@ -10,7 +10,7 @@ Our adopted & recommended tools & services for Google Cloud Platform (GCP) and T
| [Cloud Run](https://cloud.google.com/run) | Serverless container platform for stateless applications | [Reference](../../reference/cloud-platform/index.md), [Migration](../../explanations/gcp-cloud-run-app-module.md) |
| [Cloud SQL](https://cloud.google.com/sql) | Fully managed relational database service | [Backups](../../reference/cloud-platform/backups.md) |
| [Cloud Storage](https://cloud.google.com/storage) | Object storage service | [Reference](../../reference/cloud-platform/index.md) |
-| [Cloud Load Balancing](https://cloud.google.com/load-balancing) | Scalable load distribution service | [Architecture](../../reference/standard-architecture-diagrams.md) |
+| [Cloud Load Balancing](https://cloud.google.com/load-balancing) | Scalable load distribution service | [Architecture](../../standards-and-compliance/standard-architecture-diagrams.md) |
| [Cloud DNS](https://cloud.google.com/dns) | Managed DNS service | [DNS Guide](../../reference/cloud-platform/dns.md) |
| [Secret Manager](https://cloud.google.com/secret-manager) | Secure secret storage service | [CI Access](../../howtos/gke-gitlab-runners/access-secrets-in-ci-jobs-using-impersonation.md) |
| [Cloud Monitoring](https://cloud.google.com/monitoring) | Infrastructure and application monitoring service | [Reference](../../reference/cloud-platform/index.md) |
diff --git a/docs/reference/tech-lead-forum.md b/docs/reference/tech-lead-forum.md
index b0681cdc6d45fd01fe8e14462707dda6fbf275e3..598329b7403d90217fd4a7f76d63f9117125db51 100644
--- a/docs/reference/tech-lead-forum.md
+++ b/docs/reference/tech-lead-forum.md
@@ -10,7 +10,7 @@ title: The Tech Lead Forum
This page lists the purpose, the composition and the processes for the Tech Lead Forum. An
explanation of why the Tech Lead Forum exists and how it helps us is available on [a separate
-page](../explanations/tech-lead-forum.md).
+page](../standards-and-compliance/tech-lead-forum.md).
## Purpose
diff --git a/docs/standards-and-compliance/change-management.md b/docs/standards-and-compliance/change-management.md
new file mode 100644
index 0000000000000000000000000000000000000000..683317db7baa6dd8791f27bf5da4f0a3c9bc3be3
--- /dev/null
+++ b/docs/standards-and-compliance/change-management.md
@@ -0,0 +1,572 @@
+---
+title: Change Management
+---
+
+# DevOps standards for Change Management
+
+## Preface
+
+The following document has been co-created and/or reviewed by UIS DevOps tech leads, UIS DevOps
+Service Managers, and UIS Product Managers.
+
+The document requires some previous knowledge about what DevOps is, for this reason we have included
+the definition by the ISO standard ISO/IEC/IEEE 32675:2022(E) “Information technology — DevOps —
+Building reliable and secure systems including application build, package and deploymentâ€. We *
+*strongly encourage** reading the following citation before the rest of this document.
+
+*The term DevOps evolved from the availability of fully automated application build, package, and
+deployment tools, along with the recognition that information technology (IT) organizations were not
+prepared to use those tools effectively. \[...\] DevOps aims to satisfy a dynamic and competitive
+marketplace that favors products that balance the V requirements (volume, velocity, variety,
+veracity, value, and others). DevOps seeks to achieve a balance between velocity and system
+reliability and stability. DevOps was created to provide solutions to constantly changing complex
+problems, where reducing organizational risk and improving security and reliability are critical
+requirements.\[...\]*
+
+*DevOps focuses on business and organizational goals ahead of procedural and technical
+considerations. DevOps utilizes information-rich feedback loops to understand progress and threats
+to attaining business and mission goals. Taking a business or mission first view helps to balance
+the concerns of risk and the activities which provide the most value to the customer. \[...\] DevOps
+takes a customer-centric view, prioritizing and designing work to deliver value to the customer, as
+well as identifying and managing risk. In short, if it makes sense for the customer and meets a
+customer need, then it is likely to be the right approach from a DevOps perspective. \[...\]*
+
+*DevOps relies on keeping stakeholders informed and aware of changes that can impact them, by means
+of automation when practicable. \[...\]*
+
+### *Left-shift and continuous everything*
+
+*The normal DevOps practice is information-driven, risk-based, continuous everything. DevOps
+continuous everything means using the same practices in development as in operations and
+sustainment. DevOps practices are founded on automation for continuous integration, delivery and
+deployment, and operations and sustainment. The approach to DevOps in this document is to build
+systems to be secure and verifiable from the very beginning. \[...\]*
+
+*The continuous delivery, testing, and QA practices are shifted left (earlier in the workflow) to be
+planned and executed at the same time as design and development. For example, in DevOps, automated
+tests are built along with the product from inception. Most efforts begin with effective reviews of
+requirements, test strategies, and coding standards. Common methods include test-driven
+development (TDD), automatic code scanning (on build), automated regression testing, and functional
+and non-functional (e.g., performance) testing. Continuous QA and testing are essential in any
+DevOps-centric effort. Reducing rework and waste contributes to the achievement of improved
+velocities, a hallmark of well-implemented DevOps.*
+
+*Similarly, information security cannot be tacked on to the end of a development effort. The DevOps
+view of security is sometimes referred to as DevSecOps, but in reality, there is no DevOps without a
+continuous focus on security. This includes building systems to be secure from the very beginning of
+the systems and applications life cycle and continuing throughout their life cycle, including code
+that is deemed ready to be safely deprecated.*
+
+*Left-shift is particularly valuable for improving the reliability of methods for production
+software release and deployment.\[...\] In DevOps, “left-shifting†of deployment procedures means
+lower-risk deployment using the same methods for all environments in the continuous delivery
+pipeline.*
+
+*To accomplish continuous delivery more securely and reliably, many firms have turned away from
+traditional monolithic, sequential, and mostly manual development and operational approaches to one
+that integrates an ever-growing number of market-proven external solution components (i.e.,
+frameworks, libraries, application programming interfaces \[APIs\], and software as service
+solutions) with a more manageable set of targeted custom solution components. There has also been a
+significant shift to cloud- based hosting that can easily and efficiently scale up and down as
+needed to satisfy the dynamic load demands of users. To enable this, DevOps requires the use of
+tailored processes and specialized pipeline tools able to leverage automation wherever practicable,
+across the entire system’s life cycle.*
+
+### *Systems thinking*
+
+*Systems thinking counters a myopic approach of utilizing specialists—such as networking
+professionals, database administrators, and systems administrators—who rarely communicate with
+either the development or operations teams and lack understanding of the system as a whole. In
+DevOps, taking a comprehensive view encourages technology professionals to fully understand the
+system from end to end. Systems thinking can enable resolution of complex and emergent problems that
+are not easily traceable to a single flaw. Systems thinking should apply to a consistent
+architecture for the enterprise tools used for DevOps as well as to the system under development.*
+
+*\[...\]Consistent systems thinking among DevOps stakeholders can be challenging when there are
+differing or even incompatible philosophies, policies, procedures, activities, tasks, and
+tooling.\[...\]*
+
+### *Leadership*
+
+*While DevOps involves cooperation at all levels of an organization, it is most successful when
+leadership is viewed internally and externally as fully supporting the letter and the spirit of the
+DevOps policies, principles, and practices. When those in leadership roles exert their authority and
+influence, the entire DevOps team is better able to interact with stakeholders; uphold the power of
+organizational procedures; sustain a sophisticated, complex, and effective pipeline; and engage
+capable human resources.*
+
+*Addressing DevOps vulnerabilities requires commitment to investments to establish, sustain, and
+improve capabilities so that the ecosystem remains aligned with evolving policies, processes,
+mechanisms, practices, and tools. Without clear and lasting support from and continued active
+engagement of leadership, the benefits of investments in procedures and tools often fade and
+disappear. It takes time, the long-term leadership commitment of considerable resources, and a level
+of dedication to fully deploy and realize the continuous improvement of the DevOps principles,
+practices, and processes\[...\] To achieve velocity and other quality goals for DevOps, proper
+utilization of proven forms of automation depends on the involvement of humans receiving and acting
+on statistically valid information. These mechanisms and processes are particularly challenging to
+establish, utilize, sustain, and improve due to the differing baseline cultures of the stakeholders.
+Proactive and engaged leadership can set the example for stakeholders\[...\]*
+
+*Leadership benefits from clear and timely procedures for escalation and dynamic information-driven
+risk management and issue resolution. Decision-making at all levels empowers the team and the
+organizational leaders with the capability to handle emerging opportunities and risks inherent in
+the DevOps ecosystem. This approach helps avoid the overload and burnout of leadership and other
+personnel by involving, empowering, and authorizing the right people with the right capabilities at
+the right time with the right information to do the right thing. \[...\]*
+
+*DevOps values effective and collaborative communication and consequently thrives in organizations
+where transparency and collaboration are expected and enjoyed.\[...\]*
+
+*When dealing with new tools supporting “continuous everything,†unforeseen issues can arise. DevOps
+values communication and feedback loops, allowing the organization to experiment with varying
+approaches. A feedback loop is a virtuous cycle where action produces information which is used in
+future action to improve results. Team members regularly communicate what is going well and what
+needs to be improved. DevOps helps implement systems and software life cycle processes with regular
+checkpoints and rapid course correction when warranted.\[...\] Effective adaptation of DevOps
+continuously invests in transforming work into automated services that improve velocity, support
+sporadic acceleration, and enhance other quality attributes, thereby allowing leadership and
+stakeholders to be more strategic. \[...\]*
+
+### DevOps and life cycle processes
+
+*\[...\]DevOps is a full life cycle endeavor which gives equal consideration to each stage. DevOps
+is a set of principles and practices which enable better communication and collaboration between
+relevant stakeholders for the purpose of specifying, developing, continuously improving, and
+operating software and systems products and services. It is not just a matter of technical practices
+affecting other life cycle processes.*
+
+*Teams using DevOps typically start a systems or applications effort by creating a continuous
+delivery pipeline (set of tools and procedures) that takes the code from the source code management
+system and automates the complete application build, package, deployment (including transitions to
+other environments), operations, and sustainment workflow. Contributors often start with a simple
+program, write the pipeline, and then iteratively (and rapidly) develop their code. In development,
+multiple teams often integrate code continuously, automatically deliver the code to a test
+automation framework, and on to subsequent workflow participants. \[...\]*
+
+*DevOps is suitable for most life cycle process models, and particularly appropriate when teams
+adopt agile methodologies. DevOps can be just as valuable in an iterative waterfall approach.*
+
+## Introduction
+
+This document provides an implementation of the ISO standard ISO/IEC/IEEE 32675:2022(E) on change
+management and follows standard practice in DevOps software development.
+
+Not all of our services follow this model. Sometimes this is because they have been inherited from
+elsewhere with large amounts of technical debt or because they are just emerging from the Discovery
+process. Some products may be too small or too specialised in nature to fit this model.
+
+## What is “change�
+
+At its base, a “change†is any modification to the state of a product or service. We can group
+change as a whole into three categories:
+
+- **Change to the data held within a product.** This change may be administrator-led or
+ user-supplied. Ordinarily such change is seen as “Business as Usual†for our products. For
+ example, a user electing to select their preferred title from a configured in an identity system
+ is not seen as a “change†*per se*. There are exceptions. For example, the removal of a title from
+ this configured list may be classified as a “changeâ€.
+- **Change to the internal operation of a product.** This change may be far-reaching and profound
+ but if it is not user-visible, it is generally seen as a “change†from the point of view of
+ *internal* change-management processes but not from an *external* perspective.
+- **Change to the documented interface of a product.** This change may be minor but it is
+ user-visible. Consideration should be given to the effect of the change on our users and whether
+ this change requires advance communication.
+
+Any given change may further be classified by its nature. For example, a change may be a
+modification to a published Application Programmers’ Interface (API), a bug fix, a mitigation for a
+security issue or simply a change to functionality. In this document we’ll try to keep a high-level
+view of change and describe processes which apply across a range of change natures although,
+inevitably, some processes will have a greater affinity for changes of a particular nature.
+
+## Guiding principles
+
+We use the following principles when managing change:
+
+- Change is undramatic, frequent and regular.
+- Change of implementation need not be externally visible.
+- Communications with users should be proportionate, otherwise these will get ignored by the user.
+- Inputs and outputs are known and they are documented as contracts.
+- There is defence in depth.
+- Stakeholders are kept informed.
+- State is documented in code and is replicable.
+- Automate what can be automated and streamline the rest.
+
+We’ll reference these principles in the sections below.
+
+## Change cadence
+
+We assert that change should be undramatic, frequent and regular. Frequent change means that each
+change is likely to be well understood, limited in scope and consequently lower in risk. Having a
+regular cadence of change means that those delivering a service get into a rhythm which is
+appropriate to the particular service.
+
+While not directly related to change management *per se*, we hope that change is driven by a desire
+to deliver value for users of the service. By having small, frequent and regular improvements to
+value, we want to encourage users to view change as an exciting thing to look forward to, not
+something to dread.
+
+## Communicating change cadence
+
+As change is undramatic, frequent and regular, it follows that the number of changes are numerous. A
+typical week in November 2023 resulted in 94 changes being applied to our 10 most-updated products
+and services that week. In this diagram a “change†is an individual *Merge Request* (MR). A MR may
+consist of multiple sub-changes, known as *commits*. Multiple MRs may be combined together into a
+*release* and finally a release may be atomically and idempotently *deployed* to an environment.
+
+The deployment is the moment at which changes take effect, which will happen immediately after a MR
+is merged on those following Continuous Integration and Continuous Deployment (CI/CD) practices.
+Each MR represents a distinct “change†which is proposed, implemented, reviewed and tested (in
+multiple aspects).
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ A prototype dashboard showing code-changes proposed, rejected and merged in the course of one week
+in DevOps for the 10 most-updated products.
+ </figcaption>
+</figure>
+
+We are trialling this dashboard as a means for those interested to have a real-time view into which
+services have recently been changed. Each project will link to the repository where a more in-depth
+“Changelog†will link to the actual changes Merge Request / commit.
+
+## Delivery management
+
+The DevOps division has a strong focus on technology but not all roles within service management are
+engineering roles. Although this document focuses on technical approaches to change management, we
+also recognise the importance of stakeholder and relationship management, delivery management and
+governance as part of a coordinated set of practices.
+
+We use an Agile approach to development where features are proposed, refined, estimated, scheduled,
+implemented, reviewed, tested, merged and deployed. The management of our feature backlog is an
+essential part of our change management process. Our use of two-week sprints to schedule change is a
+keystone of our approach to continual improvement.
+
+The scheduling, implementation and release of changes over the course of a sprint help us ensure
+that change is undramatic, frequent and regular. We deploy our services using a high degree of
+automation. Changes naturally are designed to be *incremental* and not *revolutionary*. With
+reference to the ITIL Deployment Management practice, our choice is for the “Continuous Deliveryâ€
+model. Our delivery framework is incompatible with models such as “Big Bang†or “Phased Deliveryâ€.
+The “Pull Deployment†model is usually not applicable to our services.
+
+Change of implementation should not be externally visible. Although there is undoubtedly some
+concept of the “current version†of Office 365 within Microsoft, this is not visible to users. Word
+Online may be updated multiple times per day with bug fixes, additional features, A/B testing, etc.
+In the same way, we strive to design our services in such a way that the implementation may be
+changed with no external effect and that features may be added incrementally without breaking
+existing workflows.
+
+When features are deployed, communications should be proportionate, to avoid users ignoring too many
+communications which are not relevant for them. Returning to the example of Word Online, the
+appearance of a new menu option one day does not require months of communications work. On the other
+hand, a major feature change, does necessitate Microsoft communicating with Office 365
+administrators who then cascade information internally.
+
+## Deployment and release management
+
+Our deployment and release management strategy focuses on automated packaging, immutability of
+naming, strong versioning and automation.
+
+Server-side software is generally packaged as “container imagesâ€. These images contain the software
+packaged in such a way that they can be deployed “as is†to container-hosting infrastructure. For
+software we develop ourselves, we use immutable “version tags†for an image. As such if we deploy
+version “x.y.z†of our software, we know bit-for-bit the image which is deployed. It follows that a
+version of the software deployed to our staging environment will be bit-for-bit identical when
+subsequently deployed to production.
+
+Our release management process has recently been
+completely [automated](../explanations/gitlab-release-automation.md). Now, as changes are merged
+in GitLab, a “next release†Merge Request is maintained automatically. Once approved and merged,
+this will automatically generate a Changelog, build and test a packaged version of the software and
+upload it to Google Cloud ready for deployment.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ A Changelog generated by our release automation tooling for a recent release of
+the [Ballots of the Regent House](https://gitlab.developers.cam.ac.uk/uis/devops/regent-house-ballots/)
+application.
+ </figcaption>
+</figure>
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Container images uploaded by our release automation to Google Cloud ready for deployment. Note the
+rapid release cadence.
+ </figcaption>
+</figure>
+
+The packaging of software as container images is not an unusual practice and software which we do
+not develop ourselves, such as GitLab, is similarly packaged and versioned. The use of container
+images for software packaging and distribution is now well established within our profession.
+
+Using release version tags, we can deploy the *exact same* container image, first to a staging
+environment in order to run integration tests and then to production. Since the container images are
+identical and our staging and production environments are configured from the same underlying
+description, we have a high degree of confidence that code working in staging will work in
+production.
+
+For deployment, we are a heavy user of infrastructure as code tooling such as terraform. Our
+deployments are described in code and that code lives in GitLab. Changes to deployments are
+therefore planned, reviewed, tested and merged like any other code changes. Merging changes will
+automatically deploy the change to the staging environment and provide an interface in GitLab to
+trigger deployment to production once any manual integration or approval tests are performed in the
+staging environment. Wherever possible, service configuration also lives in GitLab and is
+automatically applied.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Code within GitLab describing the precise version of software deployed to each environment.
+ </figcaption>
+</figure>
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Code within GitLab specifying access control configuration which determines who may access the
+software and what roles they have.
+ </figcaption>
+</figure>
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Production, staging and development environments deployed automatically via GitLab CI pipelines.
+ </figcaption>
+</figure>
+
+As a technical measure, we are
+currently [developing our approach to “rolling releaseâ€](https://gitlab.developers.cam.ac.uk/uis/devops/iam/identity/infrastructure/-/issues/4)
+whereby a change is made available to a small set of users initially with that set growing over time
+to encompass all users. Such an approach naturally includes the ability to *reduce* the set of users
+exposed to a change, ultimately setting the proportion to be zero. This leads to the ability to have
+both gradual rollout and gradual rollback of changes.
+
+Our release and deployment management pipeline is an example of “automate what can be automated and
+streamline the restâ€. Making a new release of our software involves hitting “Approve†and “Mergeâ€
+buttons in GitLab. Re-deploying a service, or deploying an update to production involves hitting a
+“Play†button on a pipeline and the most recent deployment can be seen in the environments page in
+GitLab. Manual triggering of deployments allow teams to deploy at a cadence which suits their
+product’s needs.
+
+In conclusion, the current deployment process is heavily tested and documented and uses common
+reusable patterns and libraries, which reduces risks significantly, as all components are used
+several times a week by many applications.
+
+### Database schema migrations
+
+Usually schema migrations happen automatically as part of releases.
+The [DORA Core model](https://dora.dev/research/) recommends that schema changes be decoupled from
+application changes so that they may be rolled forward and backward over some number of releases
+without breaking compatibility. Although we have been using this model for schema changes, we are
+still working on formalising automated testing for schema migration and automation of snapshot
+before this is applied. All Google Cloud deployments have automated database snapshotting and
+backups.
+
+## Security and governance
+
+By using GitLab as the primary source of truth for change management and deployment, we naturally
+keep an audit log. For each change, the change itself is recorded along with the originator of the
+change, the discussion which preceded it, the discussion of the change itself, who approved the
+change, when it was merged, when it was released, which deployments contain that release, who added
+a release to a deployment, who approved the addition of the release, which environments it is
+deployed to and who approved that deployment.
+
+Our desire for automation is also motivated by the desire to keep all state related to a service
+recorded and hence have changes to that state audited. Aside from governance, this can also help
+with root cause analysis as we determine which of our risk management barriers described below
+failed and why.
+
+As part of a separate document, we will be describing DevOps’ approach to security and vulnerability
+management (DevSecOps) but it is worth mentioning here that the focus on strong naming for release
+versions and infrastructure-as-code for deployment means that we can automatically determine which
+versions of our software in which environments have known vulnerabilities.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Supply-chain vulnerability reporting and management tooling within GitLab.
+ </figcaption>
+</figure>
+
+GitLab provides a number of security-related policies which can be added to change management
+processes such as requiring approval from a narrower set of people if a security vulnerability is
+introduced or periodic scanning of deployed releases to alert about new vulnerabilities.
+
+## Risk management and software development
+
+[The Swiss Cheese model of accident causation](https://en.wikipedia.org/wiki/Swiss_cheese_model)
+notes that any one safety barrier will inevitably be permeable given a specific set of
+circumstances. “Defence in depth†is the concept of stacking *different* barriers together so that
+any one accident requires multiple barriers be penetrated. We prefer our processes to be stacked
+atop one another to ensure safety of change and to manage risk. We want these processes to be
+automated where possible so as not to needlessly impede agility or velocity while also increasing
+repeatability and reliability. No process is perfect and this is why all our processes are
+constantly being refined.
+
+A defining aspect of DevOps is the “shift leftâ€. This is the practice of moving things that used to
+happen at the end of the change process, like testing or quality early in the development process,
+often before any code is written. This also applies to other aspects of the change process, e.g.
+risk analysis is done at the time of planning, not at the time of release. The impact of the change
+on the service, whether the change warrants wider broadcasting is also done at the time of planning
+which allows comms to be done while the feature is being developed, not after it has been finished.
+
+As an example of defence in depth, consider the barriers a change to a typical back-end service must
+pass:
+
+- The change will have been discussed and refined prior to scheduling in a sprint. This is normally
+ led by a Product Manager in conjunction with a Technical Lead after work from Business Analysts
+ and/or User Experience Researchers and in consultation with stakeholders and/or the Service Owner.
+ That discussion will be stored in GitLab and is available to the person implementing the change.
+- Code being changed or added must be tested via an automated testing suite. This suite ordinarily
+ includes unit and regression testing.
+- Within the GitLab interface, changes to code are highlighted depending on whether they have been
+ covered by the automated testing. This aids reviewers in determining if changes which implement
+ new features are tested.
+- GitLab requires all tests to pass for changes to be merged.
+- The software is packaged into a “container imageâ€. Additional automated tests (including security
+ tests) are run against the container image so that the exact packaged version of code is tested.
+- The change is manually reviewed by another team member.
+- The change may not be merged in GitLab until approved by another team member.
+- We deploy changes into a staging environment which is a close analogue of the production
+ environment. This provides a final opportunity for full integration testing in advance of
+ deployment to production. For products where it is feasible to do so, we may run *automated*
+ integration tests against the staging environment alongside manual testing. Since we use
+ infrastructure-as-code, differences between production and staging are explicit and documented, as
+ well as tested. The deployment to staging happens automatically with each new release.
+
+Our focus on automated code review, testing and immutable naming for packaged code means that when a
+change is reviewed, we can have confidence that the basic safety checks have been completed. We can
+track that change from inception to deployment and have confidence in what changes are running in
+production.
+
+When we do have an incident, we take time to learn the root cause and reevaluate our barriers in the
+Swiss Cheese model to prevent that. This re-evaluation should ordinarily lead to the amendment of
+one or more barriers and/or the addition of a new one. An example of this would be additional
+technical “fail safe†protections added to our GitLab backup process in the wake
+of [an incident](https://gitlab.developers.cam.ac.uk/uis/devops/devhub/docs/-/wikis/reports/29th-March-2019-Incident-Report)
+early on with that service.
+
+## Communicating changes
+
+Although changes should be undramatic, frequent and regular, this is not always the case. For
+certain changes an announcement of the change is required. For the small number of services where
+UIS are our sole customers, we use media such as the CAB to broadcast change information. For the
+majority of our services, we will need to broadcast change wider.
+
+The communication channel will depend on the type of product. For a lot of our products, UIS is not
+seen as the department responsible for it. For example, communicating changes for our admissions
+process will be led by the relevant business unit, in this case, the Admissions Office. Equally,
+user support will also be led and owned by them, as they will be the ones receiving all user queries
+or facing the impact of any changes to these products.
+
+We often also include communication channels within our applications. For example, we use a GitLab
+functionality that displays messages to all users of it to advise users of maintenance.
+
+## Monitoring, event management
+
+Our standard Google Cloud deployment configurations include monitoring and alerting. Out of the box,
+we get:
+
+- worldwide availability checking, and
+- Transport Level Security (TLS) certificate validity checking.
+
+The majority of our products deployed to Google Cloud include an auto-scalability functionality that
+scales the application based on the load it is experiencing at every moment.
+
+Alerts are received and acted upon by the team managing and developing the service.
+
+Google Cloud allows additional alerting such as increased error rate, abnormal traffic spikes or
+impending exhaustion of storage, memory or processing resources. Alerts may be raised by email
+and/or Microsoft Teams message. The precise set of alerts is usually product-specific based on the
+needs of the management team.
+
+## Cloud Infrastructure updates
+
+Google Cloud, as well as other major cloud providers, provide a lot of components of our
+applications architectures as Platform as a Service (PaaS): SQL databases, Object storage,
+Kubernetes clusters, Serverless containers, Load Balancers, etc.
+
+A lot of these PaaS services are commonly used in all our cloud deployments. Upgrades to the
+Operating Systems (OS), system versions (e.g PostgreSQL version, or Kubernetes version), and other
+changes required to the underlying infrastructure of these PaaS services to be kept up to date is
+all managed by the cloud provider, in this case, Google Cloud. This means that we have very little
+control of when these updates/changes will happen. We can only specify maintenance windows (e.g.
+Sundays from 2 AM to 4 AM) that the cloud provider will use to decide when they want to apply those
+changes. We do not get notified of when these changes are going to happen.
+
+With the majority of our services deployed to the cloud and being run using a lot of PaaS services,
+changes to our application’s underlying infrastructure are happening all the time even if we do not
+make any changes to the application directly.
+
+## Suppliers and customers
+
+In this section we use “supplier†and “customer†in the [SIPOC](https://en.wikipedia.org/wiki/SIPOC)
+sense.
+
+When we design a service which is interacting with some other service, we document which contract we
+are assuming. For example, when we deploy applications, we use a hosting platform which publishes
+a [runtime contract](https://github.com/knative/specs/blob/main/specs/serving/runtime-contract.md).
+So long as we package our software in accordance with that contract, we can change the details of
+implementation at will. This is an *output* contract. Similarly, we publish a machine-readable
+specification for our *inputs*. An example of this would be
+the [University Card API contract](https://developer.api.apps.cam.ac.uk/docs/card/1/overview). So
+long as we continue to accept inputs according to that specification, we are free to change details
+of implementation.
+
+This approach does not guarantee inadvertent change in behaviour because of bugs or errors but it
+does delineate the interfaces we do not *intend* to change or interfaces where we would advise
+consumers of upcoming change. If an unannounced change is observed, we can be alerted and, if
+necessary, roll it back. Similarly, changes to the documented interfaces with supplier systems are
+changes we may need to be made aware of but we do not necessarily need to be aware of changes to
+internal implementation.
+
+Some intra-UIS systems are currently *ad hoc* and/or undocumented. We prefer to reduce the number of
+such interfaces over time and move to a model where our systems are based on *documented interfaces*
+and *runtime contracts*, whether the suppliers and/or customers of these are UIS or external.
+
+## Dealing with technical debt
+
+Although this document describes our best practices, some of our products do not align with this
+model yet because of technical debt. Technical debt is generated sometimes because applications have
+dependencies from other applications through *ad hoc* or undocumented interfaces. Some other times
+because the use of frameworks or technologies that the organisation never standardised into. Some
+other times because services have been manually deployed to infrastructure and no documentation
+exists.
+
+The use of automated testing at multiple points within the development lifecycle helps us have
+confidence that refactoring changes intended to pay off technical debt do not adversely affect
+functionality.
+
+By keeping our newer services and products cohesive, orthogonal, loosely coupled and relying on
+documented interfaces and contracts we hope to reduce technical debt wherever possible. This will
+not always be possible.
+
+## Conclusion
+
+This document outlined some of DevOps’ approach to change. We covered the guiding principles of
+design which we use and some of the processes we follow aligned against ITIL4 management
+practices. [Our guidebook](../index.md) provides more in-depth technical information.
+
+Our main challenges at the moment are dealing with technical debt within inherited services, being
+able to have a view of dependencies between these inherited services and other services, and the
+lack of documentation of the interface contracts between them. This currently stops us from applying
+DevOps change management best practices described in this document.
+
+## Bibliography
+
+Those interested in more details of our workflows, processes and use of technology may find the
+following pages from our guidebook useful.
+
+- [DevOps’ approach to release automation](../explanations/gitlab-release-automation.md).
+- [The use of GitLab labels for project management](../reference/gitlab-labels.md).
+- [DevOps’ culture and values](../environment/culture.md).
+- [How we encourage peer review of changes](../explanations/reviewing-issues.md).
+- [Day-to-day working in DevOps](../workflow/flows.md).
+- [The lifecycle of a feature in GitLab](../workflow/gitlab.md).
+- [Technical process for proposing and integrating changes](../workflow/merge-requests.md).
+- [The use in DevOps of terraform for deployment automation](../deployment/terraform.md).
+- [A tutorial on creating a Python package which demonstrates some of DevOps’ automated quality
+ assurance processes](https://gitlab.com/gitlab-org/gitlab/-/issues/31575).
diff --git a/docs/standards-and-compliance/devsecops-cd.md b/docs/standards-and-compliance/devsecops-cd.md
new file mode 100644
index 0000000000000000000000000000000000000000..0fe2d6d7ff4a8d2feac18083d058382da1cbee27
--- /dev/null
+++ b/docs/standards-and-compliance/devsecops-cd.md
@@ -0,0 +1,456 @@
+---
+title: Secure Continuous Deployment
+---
+
+# DevSecOps standards for Continuous Deployment
+
+## Introduction
+
+This document outlines a strategy for extending the principle of *DevSecOps* to the infrastructure
+and application deployment processes in the UIS DevOps division. It follows on from
+the [DevSecOps for Ongoing Development](https://docs.google.com/document/d/1C5_vV-dN-lt9WiZNCKJUvEz8T32xI3TuFkbcV-_2cHk)
+paper and focuses specifically on the deployment and operations aspects of DevSecOps.
+
+## Applicability
+
+This standard should be implemented for all services that the university develops, whether
+internally, or through third parties. It is particularly relevant to services that handle sensitive
+data or support important processes, where a security breach could have significant negative
+impacts.
+
+Exceptions can be submitted following the exemption process within the Systems Management Policy
+informing and seeking approval of the Tech Leads Forum first.
+
+## Standards
+
+### Infrastructure as code
+
+Infrastructure as code (IaC) is key to enabling many of the practices described in this document. By
+defining our deployments using IaC, we are able to create secure and compliant infrastructure
+configurations which can be stored in version control.
+
+#### Templates
+
+UIS DevOps uses Terraform as our standard IaC tool. We have developed internal templates around the
+standard Terraform workflow such as
+our [Terraform CI/CD template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/terraform-pipeline.yml?ref_type=heads)
+and
+our [Google Cloud Platform (GCP) Deployment project template](https://gitlab.developers.cam.ac.uk/uis/devops/gcp-deploy-boilerplate).
+These templates are configured in accordance with the standards defined in this document and should
+be the basis for all new and existing deployments. Where there is a need to extend these templates,
+care should be taken to ensure that standards continue to be adhered to.
+
+#### Reusable Terraform modules
+
+In addition to our IaC templates, we also maintain a number of
+shared [Terraform modules](https://gitlab.developers.cam.ac.uk/uis/devops/infra/terraform). These
+modules define our approved methods for deploying specific groups of resources. The modules are the
+building blocks of our GCP Deployment template and should be used when extending the template’s base
+configuration. The modules are primarily maintained by the Cloud Team, however, contributions are
+welcome from all teams. If a module is missing functionality, the ideal scenario is to add the
+functionality to the module instead of deviating from the standard path.
+
+### Configuration as code
+
+Configuration as code is the practice of defining application/service configuration as code. Much
+like with IaC, this code is centrally managed using our existing version control practices, helping
+us to ensure that our configurations are peer-reviewed and compliant with our security policies. We
+currently use this practice to manage our GitLab configuration, via
+the [gitlab-project-factory](https://gitlab.developers.cam.ac.uk/uis/devops/infra/gitlab-project-factory)
+repository, and our API Gateway configuration, via
+the [api/gateway-ops](https://gitlab.developers.cam.ac.uk/uis/devops/api/gateway-ops) repository. We
+aim to implement configuration as code for as many of our services as possible providing that the
+relevant APIs/Terraform providers exist.
+
+### Container security
+
+Many of our services involve the deployment of one or more container images. As such, ensuring the
+security of these images is critical to the overall security of our applications and services.
+
+#### Base images
+
+Every new container is built upon a pre-built, stable image called the base image. It is crucial to
+ensure that the base image used for creating any custom images is up to date and patched with the
+latest security updates. To help with this, we have
+a [Docker Images](https://gitlab.developers.cam.ac.uk/uis/devops/infra/dockerimages) repository
+which hosts many of our standard base images. This repository contains scheduled CI/CD jobs which
+automate the routine rebuilding of these images, pulling in the latest security updates and
+publishing new versions for projects to use. These base images should be used wherever possible. If
+a specific image doesn’t yet exist it should be added to the repository.
+
+#### Multi-stage builds
+
+A multi-stage build uses multiple base images in a single Dockerfile. Initial stages are used to
+perform the various different build tasks as required, with the final stage containing only the
+artefacts which are absolutely necessary for the production image. Using multi-stage builds not only
+reduces the resulting size of our images, but, more importantly, it reduces the potential attack
+surface of our deployed services.
+
+#### Run as a non-privileged user
+
+By default, Docker containers run as the root user, which can pose security risks if the container
+becomes compromised. To protect against this, our containers should configure a non-root user using
+the [USER](https://docs.docker.com/reference/dockerfile/##user) instruction in the Dockerfile unless
+there is absolutely no other alternative.
+
+#### Regular image builds and deployments
+
+In addition to the automated rebuilding of our base images, services should ensure that their
+customised images are regularly rebuilt and redeployed. This ensures that software libraries and
+dependencies are also kept up to date with latest security fixes. This goes hand-in-hand with the
+automated dependency update practice detailed in
+the [DevSecOps for Ongoing Development](https://docs.google.com/document/d/1C5_vV-dN-lt9WiZNCKJUvEz8T32xI3TuFkbcV-_2cHk)
+paper.
+
+As a minimum, services should aim to deploy updated images at least once a month. For services under
+active development this should be a relatively easy target to meet, however, for other services
+extra care should be taken to ensure that images are regularly updated. For newly discovered
+vulnerabilities services should use
+the [Vulnerability and Patch Management standard](https://help.uis.cam.ac.uk/system/files/vulnerability_and_patch_management_technical_standard_v1.4.pdf)
+schedule
+
+### IaC security
+
+As discussed in
+the [Continuous Integration & Continuous Delivery standards](https://docs.google.com/document/d/14Ob5uZVJ-l9Tb-JlU2ouxcTfSOqPA_gKeoCCZAyyPVE)
+paper, deployment automation is crucial to continuous delivery workflows. In terms of DevSecOps, we
+can build on the CI/CD deployment pipeline to include industry standard security checks, ultimately
+ensuring that each deployed environment is as secure as possible.
+
+#### trivy
+
+Our
+standard [terraform-pipeline CI template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/terraform-pipeline.yml?ref_type=heads)
+includes a [trivy](https://www.aquasec.com/products/trivy/) job by default. This is a static
+security analysis job which detects many different IaC misconfigurations and security risks. It
+comes pre-configured with hundreds of checks for multiple IaC tools and cloud providers, and must be
+included in our IaC deployment pipelines.
+
+#### KICS
+
+[KICS](https://github.com/Checkmarx/kics) is another static analysis tool for finding security
+vulnerabilities and misconfigurations in IaC projects. It is included in
+the [GitLab AutoDevOps templates](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/SAST-IaC.gitlab-ci.yml)
+and can be added to any GitLab pipeline using
+the [include](https://docs.gitlab.com/ee/ci/yaml/##include) keyword.
+
+Although there is some crossover between the trivy and KICS tools, between them they support a
+variety of different IaC products with many different rulesets. In general, both of these jobs must
+be enabled in our IaC repositories to give us maximum coverage.
+
+#### Identity and access management
+
+Identity and Access Management (IAM) is a crucial element of DevSecOps and the principles of least
+trust and zero trust should be at the forefront of our minds when designing and implementing
+services. For example, our Cloud Platform configuration for GCP lays the foundation for these
+principles by creating environment specific deployment service accounts with restricted permissions,
+and ensuring only the required team members have the ability to impersonate these accounts. The GCP
+deployment boilerplate then builds on this by ensuring that cloud services are configured to run in
+the context of dedicated, task-specific service accounts, again, with just the right permissions to
+perform the required tasks.
+
+#### Least privilege
+
+The principle of least privilege is a security concept that limits an IAM principal’s access to the
+minimum level required to perform its job. It allows a principal to access only the resources
+needed, thereby reducing the potential damage that can be caused by malicious attacks or accidental
+errors. The principle of least privilege mustz\` be followed as closely as possible for all of our
+services wherever possible.
+
+#### Zero trust
+
+Zero trust is a security model that assumes no trust between different entities and establishes
+strict access controls. It requires verification for every access request to ensure that only
+authorised users are granted access to resources. This is generally how most Google Cloud services
+communicate with each other. For example, Cloud SQL databases can
+use [IAM database authentication](https://cloud.google.com/sql/docs/postgres/iam-authentication##iam-db-auth)
+which allows the use of short-lived access tokens to authenticate database sessions, rather than
+using built-in username and password authentication.
+
+The principle of zero trust is currently being scaled up across the DevOps division and, as
+mentioned previously, it should certainly be a key consideration when designing and implementing our
+services.
+
+#### Google service accounts
+
+A Google service account represents a non-human user/identity. They are usually associated with a
+specific cloud resource and are granted permissions to allow the resource to access required
+services. Service accounts themselves should be managed *as a resource*, meaning that they should be
+created and destroyed in code, and with the same lifecycle as their associated resource.
+
+##### Create task-specific service accounts
+
+Service accounts should be created for a single, task-specific purpose. This allows us to grant a
+narrow set of permissions to each service account, ensuring that we adhere to the principle of least
+privilege. This usually means that a deployment will consist of multiple service accounts, each tied
+to a specific resource.
+
+##### Service account keys and impersonation
+
+Service accounts can have one or more key pairs associated with them. These keys are downloadable as
+JSON files and can pose a **significant security risk** if they are not managed appropriately. With
+this in mind, the creation of service account keys must not happen unless absolutely necessary.
+
+Instead, users (and other service accounts in some situations) should be granted permission to
+impersonate the required service account(s). This allows the user to generate a temporary token to
+be able to act on behalf of a service account to perform a particular task. This is the default
+method for authenticating as service accounts in our current deployments.
+
+##### Regularly review role recommendations
+
+Google provides a
+built-in [role recommendation](https://cloud.google.com/policy-intelligence/docs/role-recommendations-overview)
+feature to help identify which permissions a service account is actually using, and which
+permissions might be unused. Teams must regularly review these recommendations and adjust the roles
+granted to their service accounts as required. These recommendations are displayed in the Security
+Insights column of the default IAM table in the Google Cloud Console.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ IAM table in the Google Cloud Console showing the excess permissions recommendations.
+ </figcaption>
+</figure>
+
+### Secrets management
+
+One of the most difficult areas of DevOps deployments is secrets management. With so many
+interconnecting systems, most of our services require multiple pieces of sensitive information and
+keeping these secrets secure is paramount when thinking about DevSecOps.
+
+#### 1Password and Google Secret Manager
+
+The DevOps division primarily uses two secret managers, 1Password and Google Secret Manager (GSM).
+1Password is the canonical source of truth for any of our manually provided secrets. For secrets
+that are dynamically generated (for example via IaC) GSM should be considered the source of truth,
+with the full lifecycle of the secret resource being managed via automation.
+
+Our standard Terraform deployments cannot access 1Password securely at runtime. Therefore, for
+manually provided secret values we should use our in-house
+tool, [Sanctuary](https://gitlab.developers.cam.ac.uk/uis/devops/tools/logan/-/blob/master/docs/sanctuary.md?ref_type=heads),
+to synchronise the required 1Password secrets with environment-specific GSM secret objects prior to
+deployment.
+
+#### Providing secret values to Google Cloud resources
+
+As mentioned above, generally we synchronise a service's required secrets from 1Password to GSM
+secret objects *before* we initiate a deployment. This allows us to configure task-specific service
+accounts with the required secret accessor role to be able to read secret values at runtime. Many of
+Google Cloud’s resources support this workflow, for
+example [Cloud Run](https://cloud.google.com/run/docs/configuring/services/secrets##access-secret)
+and [Cloud Functions](https://cloud.google.com/functions/docs/configuring/secrets).
+
+##### Environment variables
+
+A common configuration pattern for services such as Cloud Run and Cloud Functions is to store secret
+values as environment variables. This can be made somewhat secure by the fact that the APIs for
+these services allow specifying a GSM secret object by ID, the value of which is then loaded into
+the environment at runtime, avoiding any hardcoding of secret information in IaC for example.
+However, as explained by Seth Vargo (Google engineer) in his blog
+post [Secrets in Serverless](https://www.sethvargo.com/secrets-in-serverless/):
+
+*While this approach is simple and straightforward, it comes with considerable security drawbacks \-
+the secrets exist in plaintext in the environment. Any other process, library, or dependency running
+inside the process has access to the environment which
+has [already been exploited multiple times](https://www.bleepingcomputer.com/news/security/javascript-packages-caught-stealing-environment-variables/).
+Unfortunately, it is trivial for a malicious library author to inject this type of vulnerability
+into an otherwise helpful utility package.*
+
+*To be absolutely, unequivocally
+clear, **you should not store secret or sensitive information in environment variables in plaintext
+**.*
+
+With this in mind you should either (a) Access secrets directly on runtime, or (b) Mount secrets as
+Volumes
+
+##### Access secrets directly on runtime
+
+Fetch the GSM secret object on runtime when they are needed. This approach may only be possible for
+webapps that can use a
+supported [Google Cloud library](https://cloud.google.com/apis/docs/cloud-client-libraries). Secrets
+can be fetched dynamically, ensuring that your application always uses the most up-to-date
+credentials without needing to restart or redeploy. Direct access allows us to better leverage
+Google Cloud's audit logging to monitor and track access to secrets.
+
+##### Mounting secrets as Volumes
+
+Sometimes, although rarely, we won’t be able to access secrets directly from runtime because of a
+requirement from a library or because the application we need to use doesn’t allow us to do this or
+doesn’t have support for the Google Cloud library. Mount GSM secret objects as volume mounts only
+accessible by the application user and configure the application code to read the mounted file(s)
+from disk to ingest the secret values. Mounted secrets are static and require container restarts to
+update, which can be less flexible. Managing secrets as volumes requires careful handling to ensure
+they are not exposed.
+
+#### Accessing secrets in GitLab pipelines
+
+The DevOps
+division’s [GKE GitLab runner platform](https://guidebook.devops.uis.cam.ac.uk/en/latest/explanations/gke-gitlab-runners/)
+configure’s GitLab pipeline jobs with a Google IAM identity. This gives us the ability to grant a
+job’s identity access to specific GSM secret objects allowing us to access the secret value at
+runtime. This removes the need to store secrets in GitLab’s CI/CD variables which is a potential
+security risk and something which we want to avoid. The guidebook has some useful guides
+on [how to run CI/CD jobs on a GKE-hosted runner](https://guidebook.devops.uis.cam.ac.uk/en/latest/howtos/gke-gitlab-runners/run-ci-jobs-on-a-gke-gitlab-runner/)
+and [how to access a GSM secret value using service account impersonation in a CI/CD job](https://guidebook.devops.uis.cam.ac.uk/en/latest/howtos/gke-gitlab-runners/access-secrets-in-ci-jobs-using-impersonation/).
+
+#### Secrets in Terraform
+
+Terraform configurations often need to configure resources with sensitive information, for example
+providing a secret value to a Cloud Run service. However, by default, Terraform state files are not
+encrypted. This means that actions such as generating secrets using
+the [random provider](https://registry.terraform.io/providers/hashicorp/random/latest/docs), or
+reading secrets from a GSM secret object using
+a [data source](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/secret_manager_secret_version)
+cause the secret value to be stored in plain text in the state file.
+
+In our standard deployments we protect against this by storing state files in Google Cloud Storage
+buckets which are encrypted at rest by default. We also apply restricted IAM permissions to the
+buckets to ensure that only a small number of users/service accounts are able to access the state
+files. However, even with these protections in place, our recommendation is to avoid generating
+secrets in Terraform configurations, or reading secrets into Terraform configurations using data
+sources wherever possible.
+
+### Continuous monitoring
+
+Continuous monitoring is the process of automating the collection and analysis of data and producing
+relevant reports and alerts. This helps to provide real-time insights into system performance and to
+identify and resolve potential security threats and vulnerabilities. For example, an increase in
+4xx \- as opposed to 5xx \- responses from an API, while not indicating an issue with the API itself
+may be indicative of an automated attack.
+
+The Google Cloud
+Platform [automatically collects and stores performance data](https://cloud.google.com/monitoring/docs/monitoring-overview)
+for most Google Cloud services by default. It is the responsibility of our product teams to
+configure the relevant reports and alerts depending on the requirements of each service. Our GCP
+deployment boilerplate includes our
+shared [Site Monitoring](https://gitlab.developers.cam.ac.uk/uis/devops/infra/terraform/gcp-site-monitoring)
+Terraform module which configures default SSL expiry and uptime checks for Cloud Run services. This
+is expanded to include all required elements from
+the [Security Logging Technical Standard](https://universityofcambridgecloud.sharepoint.com/sites/UIS_TechnicalDesignAuthority/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FUIS%5FTechnicalDesignAuthority%2FShared%20Documents%2FGeneral%2FTechnical%20Standard%20submissions%2FSecurity%20Logging%20v1%20%2Epdf&parent=%2Fsites%2FUIS%5FTechnicalDesignAuthority%2FShared%20Documents%2FGeneral%2FTechnical%20Standard%20submissions).
+
+### Backups and data retention
+
+Ransomware attacks, data leakages, and data loss are unfortunately becoming commonplace in the
+modern IT landscape. As such, we must ensure that our services and data are protected and have
+appropriate backups and data retention policies in place. It is impossible to detail in this
+document the exact strategy for each individual service, as this is dependent on what data each one
+of them treats, uses, how it stores this, etc. As a general rule, we need to have offline backups /
+ransomware resilient back ups, a plan to recover from disasters, and appropriate data retention
+following [University's master records retention schedule](https://www.information-compliance.admin.cam.ac.uk/records-management).
+
+We will discuss some processes which are common across our services.
+
+#### GitLab backups
+
+All our code and build artifacts are stored in
+the [University GitLab service](https://gitlab.developers.cam.ac.uk/)
+following [DevSecOps standards for Ongoing Development](https://docs.google.com/document/d/1C5_vV-dN-lt9WiZNCKJUvEz8T32xI3TuFkbcV-_2cHk).
+As such, we must ensure that this service is properly protected to ensure that the business impact
+of any potential outage is kept to a minimum.
+
+The [Cloud team](https://guidebook.devops.uis.cam.ac.uk/contact/teams/##cloud-team) configures and
+manages a nightly automated backup of the entire GitLab service which is based
+on [the documentation provided by GitLab](https://docs.gitlab.com/charts/backup-restore/). These
+automated backups include the main GitLab database, all repository data, CI build logs and
+artefacts, pages site data, and all container images and published package data. Backup data is
+retained for a minimum of 60 days and the restore process is tested at least once every 12 months.
+
+#### Database backups
+
+Many of our services rely on some form of database. For example, our GCP deployment boilerplate
+configures a standard PostgreSQL instance using the Google Cloud SQL service. Databases should be
+configured to perform automated backups at least once a day with backup data being retained for a
+minimum of 7 days.
+
+##### Google Cloud SQL
+
+With regards to Google Cloud SQL database instances,
+the [Cloud team](https://guidebook.devops.uis.cam.ac.uk/contact/teams/##cloud-team) manages
+an [automated process](https://gitlab.developers.cam.ac.uk/uis/devops/infra/sql-backup) to export
+all of our production Cloud SQL databases to Cloud Storage buckets in a central Google Cloud
+project. This process runs nightly and ensures that we have an “off-site†copy of our production
+databases in addition to the Cloud SQL automated backups/snapshots. This provides us with the
+ability to recover from potential major issues such as a Cloud SQL instance being completely deleted
+or a Google project becoming compromised or deleted.
+
+#### Bucket and object storage backup and retention
+
+Google Cloud Storage buckets are a common place for our services to store business critical data. As
+such, we must ensure that buckets are configured with the appropriate backups and retention
+policies.
+
+##### Object versioning
+
+Cloud Storage [object versioning](https://cloud.google.com/storage/docs/object-versioning) can be
+enabled on a bucket in order to retain older versions of objects. This allows you to retain previous
+versions of an object and to restore objects from accidental deletion. This is simple to configure
+and must be used in all situations where a bucket contains important data as a first line of
+defence. However, it should be noted that this does not protect against bucket deletion.
+
+##### Bucket and object retention locks
+
+The Cloud Storage service provides
+a [number of different options](https://cloud.google.com/storage/docs/control-data-lifecycles) to
+configure retention period *locks* for both buckets and bucket objects. These locks ensure that
+buckets and/or bucket objects have a “retain-until†date and time configured which cannot be
+modified once set. During this time the targeted data *cannot* be deleted or replaced/modified.
+
+Bucket and object retention locks can provide protection against threats such as ransomware attacks
+and must be configured for any business critical data. Retention periods will vary between services
+depending which data they handle, these must
+follow [University's master records retention schedule](https://www.information-compliance.admin.cam.ac.uk/records-management).
+
+##### Bucket data exports
+
+In some situations, object versioning and bucket locks still do not provide enough protection for
+our business critical data. If this is the case, you must configure an automated export/sync of the
+bucket data to “air-gapped†buckets in a secondary Google project.
+
+## Networking
+
+### Load Balancing
+
+Many of our deployments make use of one or more Google Cloud Load Balancers. The following sections
+detail some of the changes to the defaults that we must be applied when configuring these load
+balancers
+
+#### SSL Policies
+
+By default, Cloud Load Balancers are configured with
+an [“COMPATIBLE†SSL policy](https://cloud.google.com/load-balancing/docs/ssl-policies-concepts)
+which supports legacy versions of TLS and RSA signatures to provide wide compatibility with many
+different clients. However, you must use the more
+restrictive [MODERN](https://cloud.google.com/load-balancing/docs/ssl-policies-concepts##defining_an_ssl_policy)
+SSL unless a requirement to support old clients is justified. This configuration is the default in
+our templates and can be seen in
+our [Cloud Run App](https://gitlab.developers.cam.ac.uk/uis/devops/infra/terraform/gcp-cloud-run-app/-/blob/master/load_balancer.tf?ref_type=heads##L17)
+shared Terraform module.
+
+#### Cloud Armour
+
+[Google Cloud Armour](https://cloud.google.com/armor/docs/cloud-armor-overview) helps to protect our
+deployments from multiple types of threats, including distributed denial-of-service (DDoS) attacks.
+By default, all Google Cloud projects that include an external Cloud Load Balancer are automatically
+enrolled
+into [Cloud Armour Standard protection](https://cloud.google.com/armor/docs/managed-protection-overview##standard_versus_plus).
+This includes always-on DDoS protection and access to the Cloud Armour web application firewall (
+WAF) rules capabilities,
+including [preconfigured WAF rules for OWASP Top 10 protection](https://cloud.google.com/armor/docs/waf-rules).
+
+This default protection is very useful and is often enough for our standard deployments. However, we
+should continually review our services as they are developed to determine if additional WAF rules
+are required to improve our security position.
+
+### DNSSEC
+
+The Domain Name System Security Extensions (DNSSEC) is a DNS feature that protects against DNS
+record spoofing by authenticating responses to domain name lookups. DNSSEC must be enabled on all
+services. All DNS zones that are created and managed by
+the [gcp-product-factory](https://gitlab.developers.cam.ac.uk/uis/devops/infra/gcp-product-factory/-/blob/master/modules/workspace/dns.tf?ref_type=heads##L28)
+have DNSSEC configured by default.
+
+## Related standards
+
+[DevSecOps standards for Ongoing Development](https://docs.google.com/document/d/1C5_vV-dN-lt9WiZNCKJUvEz8T32xI3TuFkbcV-_2cHk/edit?tab=t.0##heading=h.87tmfwt308vo)
+
+[DevOps Continuous Integration and Continuous Delivery (CI/CD) standards](https://docs.google.com/document/d/14Ob5uZVJ-l9Tb-JlU2ouxcTfSOqPA_gKeoCCZAyyPVE/edit?tab=t.0)
diff --git a/docs/standards-and-compliance/devsecops-cicd.md b/docs/standards-and-compliance/devsecops-cicd.md
new file mode 100644
index 0000000000000000000000000000000000000000..b02784029bd463c18b9ba63d7dfa9a48d3d42b5b
--- /dev/null
+++ b/docs/standards-and-compliance/devsecops-cicd.md
@@ -0,0 +1,333 @@
+---
+title: Continuous Integration and Continuous Delivery (CI/CD)
+---
+
+# DevOps standards for Continuous Integration and Continuous Delivery (CI/CD)
+
+## Introduction
+
+This document provides an overview of the University of Cambridge Information Services’ (UIS’)
+Development and Operations (DevOps) Division approach to implementing Continuous Integration and
+Continuous Delivery (CI/CD) as per ISO standard ISO/IEC/IEEE 32675:2022(E) “Information technology —
+DevOps — Building reliable and secure systems including application build, package and deploymentâ€.
+
+CI/CD is the automation of most or all of the manual processes traditionally required to get new
+code deployed to production. It encompasses the build, review, test and deployment processes. Since
+we provision infrastructure as code, this extends to infrastructure provisioning. With a CI/CD
+pipeline, development teams can make changes to code that are then automatically tested and pushed
+out for delivery and deployment. Automation makes processes predictable, reviewable, and repeatable
+so that there is less opportunity for error from human intervention.
+
+In this document we consider CI/CD broadly to encompass processes which a) are automated, b) have
+outputs which relate to the DevOps development lifecycle and c) are triggered by actions by
+engineers or on a schedule. Notably absent from this are scheduled processes which run as part of
+services themselves such as scheduled data imports, syncs or other batch processes.
+
+Where CI/CD processes are programming language specific, the provision of standard CI/CD templates
+may not be the same between languages. It is desirable to close feature gaps between languages where
+they exist, for example, by generating templates that are compatible with multiple languages.
+
+This document describes CI/CD standards at a high-level. Specifics and implementation details may be
+found elsewhere. For
+example, [our guidebook has a page on how to add CI/CD to a Python project](../howtos/add-common-pipeline-to-python.md)
+and [a page on configuring release automation via CI/CD](../howtos/enable-automated-gitlab-releases.md).
+Our existing [web application](https://gitlab.developers.cam.ac.uk/uis/devops/webapp-boilerplate/)
+and [terraform deployment](https://gitlab.developers.cam.ac.uk/uis/devops/gcp-deploy-boilerplate)
+boilerplates already include the standards described below.
+
+CI/CD automation is performed via GitLab pipelines. These standards are either implemented in the
+shared
+DevOps [CI template configurations](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/)
+or use out of the box solutions.
+
+## Applicability
+
+This standard should be implemented for all services that the university develops, whether
+internally, or through third parties. It is particularly relevant to services that handle sensitive
+data or support important processes, where a security breach could have significant negative
+impacts.
+
+Exceptions can be submitted following the exemption process within the Systems Management Policy
+informing and seeking approval of the Tech Leads Forum first
+
+## Terminology
+
+A **job** is an automated process which usually takes as its input a specific commit of the code and
+some configuration variables. Jobs may generate **artefacts** which are either files shared
+subsequently with other jobs or files which are published to some external registry. Jobs may have
+[**intended side-effects**](https://en.wikipedia.org/wiki/Side_effect_\(computer_science\)) such as
+releasing a new version of some software or provisioning some infrastructure.
+
+Jobs are collected into **pipelines**. Within a pipeline, jobs may depend on one another for
+artefacts or side-effects. The configuration of jobs and pipelines lives within the git repository
+of a project, usually in a `.gitlab-ci.yml` file.
+
+Pipelines are **triggered** from multiple sources. Most commonly we use **push**\-triggered
+pipelines which trigger when new commits are pushed to a repository, **tag**\-triggered pipelines
+which trigger when commits are tagged and **scheduled** pipelines which run according to a defined
+schedule.
+
+Jobs within pipelines may indicate that they deploy to **environments**. The most recent jobs which
+have deployed to an environment can be seen in the “Environments†tab in GitLab.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Figure taken from our
+Guidebook [tutorial on creating a Python package](../tutorials/creating-a-python-package/).
+ </figcaption>
+</figure>
+
+## Cloud Platform-as-a-Service
+
+The following sections detail our standard CI pipeline workflows. While the concepts are generic,
+the implementation of our custom CI templates is specifically designed for use with our standard
+Platform-as-a-Service (PaaS) based on Google Cloud and follows our published standards on
+Development and Deployment. This is so that we can ensure certain tasks which may require additional
+thought, such as authentication to external systems, are implemented in a consistent, approved and
+secure way. As such, there are some core cloud platform prerequisites which must be in place before
+using many of the workflows below, they are:
+
+- A folder/product needs to be created first on Google Cloud using
+ the [gcp-product-factory](https://gitlab.developers.cam.ac.uk/uis/devops/infra/gcp-product-factory).
+ This will create the space in our PaaS to host your service and will ensure that all the required
+ pre-configuration is securely deployed following our standards.
+- The GitLab projects which will store source code and run the CI/CD pipelines must be deployed via
+ the [gitlab-project-factory](https://gitlab.developers.cam.ac.uk/uis/devops/infra/gitlab-project-factory).
+ Existing projects can be imported.
+- A GitLab Runner must have been deployed for the GitLab projects in question via
+ the [gitlab-runner-infrastructure](https://gitlab.developers.cam.ac.uk/uis/devops/devhub/gitlab-runner-infrastructure)
+ Terraform configuration. This ensures that the GitLab runner required to execute CI and CD jobs
+ has the correct configuration and is secure.
+
+For a more detailed explanation on our Google Cloud standards see
+the [Cloud Platform](https://guidebook.devops.uis.cam.ac.uk/en/latest/reference/cloud-platform/)
+section in the Guidebook.
+
+## GitLab Auto-DevOps
+
+Pipelines should use [GitLab’s Auto-DevOps feature](https://docs.gitlab.com/ee/topics/autodevops/).
+This provides a number of standard jobs for tasks such as container image builds, dependency
+scanning, secret detection, and code quality.
+
+Enabling Auto-DevOps can be as simple
+as [including the Auto-DevOps template](https://docs.gitlab.com/ee/topics/autodevops/customize.html#customize-gitlab-ciyml)
+in a project’s .gitlab-ci.yml file. However, in practice we have embedded the Auto-DevOps template
+into our own CI templates to allow us to extend the Auto-DevOps pipeline, adding additional
+functionality where required. For example, our
+standard [web application boilerplate](https://gitlab.developers.cam.ac.uk/uis/devops/webapp-boilerplate/-/blob/master/%7B%7B%20cookiecutter.project_slug%20%7D%7D/.gitlab/webapp.gitlab-ci.yml?ref_type=heads#L3)
+uses
+our [common-pipeline.yml](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/common-pipeline.yml?ref_type=heads),
+which should be the default template used in any of our Python projects.
+
+Our CI templates can be found in the
+dedicated [ci-templates GitLab project](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/).
+
+## Stages
+
+CI/CD pipelines have multiple stages corresponding to different classes of work. The following are
+jobs you should employ in CI/CD pipelines, grouped by stage. As mentioned above, some of the jobs
+described below ship
+with [GitLab’s Auto DevOps feature](https://docs.gitlab.com/ee/topics/autodevops/) and some have
+been created by UIS DevOps.
+
+### Build and package
+
+For web application or library code, we build appropriate *build artefacts*. For web applications,
+this will be a container image built using the Auto-DevOps Build job. For libraries this is
+generally some language-specific package intended for upload to package registries such as maven,
+PyPI or npm. In this case we have to implement our own build job. For PyPI, this is implemented
+using our
+standard [python-publish template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/python-publish.yml?ref_type=heads#L11).
+
+### Analyse
+
+We employ a number of static analysis jobs which generate *report artefacts*. As a baseline, we must
+include all the Auto-DevOps Dependency Scanning as well as the other Auto-DevOps analysis jobs such
+as Container Scanning, Code Quality, Secret Detection, and Static Application Security Testing (
+SAST).
+
+The output from these analysis jobs is provided back to GitLab which allows us to rapidly scan for
+projects using out-of-date dependencies or ones whose container images contain libraries with known
+vulnerabilities.
+
+GitLab security policies run this analysis step for the `main` branch regularly so that we may scan
+for new vulnerabilities as they arise.
+
+### Test and lint
+
+“[Linting](https://en.wikipedia.org/wiki/Lint_\(software\))†is a term of art used in Software
+Development to refer to automated code formatting checks. These checks do not check functional
+correctness *per se* but rather look for common patterns which, although still allowing the code to
+function correctly, are considered detrimental to readability or maintainability. Recently it has
+become common to enforce an opinionated code formatting style for reasons of consistency and for
+that code formatting style to be amenable for automatic application. Below we’ll use “code format
+checking†to mean the use of both linting and more opinionated code style tooling.
+
+In the test and lint stage there will be some form of automated testing and code style review. It is
+outside this paper’s scope to cover test standards, which is covered in a separate paper. For our
+Python projects, use
+our [python-tox template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/python-tox.yml?ref_type=heads)
+to run tests using [tox](https://tox.wiki/en/4.11.4/), and for our Terraform repositories use the
+jobs in the test stage of
+the [terraform-pipeline template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/terraform-pipeline.yml?ref_type=heads).
+
+For projects with unit-tests it will generate a *code-coverage artefact* which indicates which code
+the unit-tests actually tested. This is used later in the review section.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Testing jobs usually comprise the majority of pipelines triggered by commits to the code.
+ </figcaption>
+</figure>
+
+For pipelines which are triggered by tags, we will also perform some basic correctness checks such
+as ensuring that the version of the software in the packaging metadata matches the name of the tag.
+This is to enforce that a tag named 1.2.3 does actually correspond with version 1.2.3 of the
+software.
+
+We also use [pre-commit hooks](https://pre-commit.com/index.html) to specify which code formatting
+tools, and configuration, to use. Use
+our [pre-commit template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/pre-commit.yml?ref_type=heads)
+to enforce pre-commit checks in CI/CD. The use of pre-commit allows developers to configure tools to
+run locally as well when committing changes. This helps lower the latency of the feedback loop for
+what may be viewed as “trivial†code formatting changes. This also helps ensure that reviewers stay
+focused on content rather than style.
+
+### Review
+
+GitLab Merge Requests (MRs) aggregate a number of reports generated by CI/CD jobs. Exactly which
+jobs are run depends on the nature of the repository. For web application and library code, the code
+coverage artefact will be used to highlight the changed portions of code depending on whether the
+tests exercised them or not. Similarly, a test report will be attached to the MR indicating which
+tests ran and which passed. MRs cannot ordinarily be merged unless all tests pass. When a container
+image is built, tests are run *within* the container to provide some confidence that the packaging
+is successful.
+
+Code format checking is treated as a test in its own right and so formatting issues will need to be
+addressed or manually skipped for MRs to be merged.
+
+While we currently perform dependency and security vulnerability analysis for MRs, we do not prevent
+merging if new vulnerabilities are determined. GitLab provides mechanisms to define security
+policies surrounding vulnerability triaging and reviewing which we are in the process of adopting
+and will be covered in another paper.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Bill-of-materials analysis for a project in GitLab. The analysis for this page is performed as a
+CI/CD job.
+ </figcaption>
+</figure>
+
+### Release and publish
+
+Jobs in this stage are performed only on commits which have been merged into the default branch.
+Even so, we run the test and lint jobs once more and do not proceed until they pass.
+
+Use our standard release automation workflow for creating and tagging new releases. Details of this
+workflow
+are [available in the guidebook](https://guidebook.devops.uis.cam.ac.uk/en/latest/explanations/gitlab-release-automation/)
+but in brief, we have two forms of release automation:
+
+Variant A involves jobs triggered when new commits land in the default branch. These jobs curate a
+`CHANGELOG.md` file and increment the version number specified in the packaging configuration.
+Version numbers are incremented in line with semantic versioning informed
+by [conventional commit messages](https://guidebook.devops.uis.cam.ac.uk/en/latest/explanations/git/#commits).
+In this case, use of
+the [commitlint job](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/commitlint.yml?ref_type=heads)
+which will enforce conventional commit naming schemes. Once the `CHANGELOG.md` file and versioning
+metadata are updated, a new tag and GitLab release is created named after the version.
+
+Variant B similarly involves jobs triggered when new commits land in the default branch. This time
+changes to the version number and `CHANGELOG.md` file are kept in a separate MR. Merging this MR
+effectively causes a new tag and GitLab release to be created. This variant is suitable for products
+where new releases should not be created for each change which lands in the default branch.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Example MR managed by variant B of the automated release process.
+ </figcaption>
+</figure>
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The GitLab release and automated changelog generated when merged.
+ </figcaption>
+</figure>
+
+No matter how the git tag corresponding to a release is made, once created a pipeline is triggered
+to publish the build artefact for that release. For libraries this will involve publishing the
+artefact to a package registry appropriate for the language. This will be a public registry for Open
+Source libraries or the private GitLab registry for private or internal libraries.
+
+For web applications, publication involves pushing the container image to the Google Cloud Artifact
+Registry tagged with the version, ready for deployment. Use
+our [artifact-registry template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/artifact-registry.yml?ref_type=heads)
+for this task. This template handles authentication to both the GitLab Container Registry and the
+Google Cloud Artifact Registry in a secure and approved manner.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ CI/CD pipeline triggered by a new git tag which builds, tests and publishes a container image to
+the Google Artifact Registry.
+ </figcaption>
+</figure>
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The container images pushed to the Google Artifact Registrty ready for deployment.
+ </figcaption>
+</figure>
+
+### Deploy
+
+Deployment of services and provision of infrastructure is done via an infrastructure as code using
+Terraform. Terraform code is code like any other and so many of the CI/CD jobs described above are
+equally applicable.
+
+Use
+our [terraform-pipeline CI template](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/terraform-pipeline.yml?ref_type=heads)
+for Terraform deployments. This template is designed explicitly for Terraform and runs test and
+code-format checking jobs as well as “plan†and “apply†jobs for our standard development, staging
+and production environments.
+
+These jobs are triggered when new commits are pushed to the repository. The “plan†jobs allow manual
+review of infrastructure changes in advance of “applyâ€. Any commit may be deployed to the
+development environment but, ordinarily, only commits which land in the default branch should
+trigger deployments to staging or production environments.
+
+For commits which are merged into the default branch, the staging environment is, unless configured
+otherwise, deployed automatically. This lets us treat the staging environment as the most
+“up-to-date†infrastructure and ensure that the default branch is always deployable. Jobs are
+created for deployment to the development and production environments but they require manual
+approval to proceed. Manual approval for deployment to the production and development environments
+can be performed in the Pipelines view by pressing the “play button†next to the appropriate
+environment to trigger the deployment.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The container images pushed to the Google Artifact Registrty ready for deployment.
+ </figcaption>
+</figure>
+
+GitLab also has an Environments view, which can be very useful to see at a glance which version is
+currently deployed to each environment. However, the “play†and “stop†buttons in this view should
+not be used as our Terraform pipeline jobs have not yet been configured with the required
+logic/functions and, therefore, jobs triggered from the Environments view can perform unintended or
+confusing actions. Triggering manual pipeline jobs must be done via the Pipelines view, as described
+above until support has been added.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The “Environments†page for a product in GitLab showing which version is currently deployed to the
+staging environment.
+ </figcaption>
+</figure>
diff --git a/docs/standards-and-compliance/devsecops-dev.md b/docs/standards-and-compliance/devsecops-dev.md
new file mode 100644
index 0000000000000000000000000000000000000000..48602cc1dcdd86a71194f3458b9a166f33db1ea7
--- /dev/null
+++ b/docs/standards-and-compliance/devsecops-dev.md
@@ -0,0 +1,527 @@
+---
+title: Secure Development
+---
+
+# DevSecOps standards for Ongoing Development
+
+## Introduction
+
+This document outlines a strategy for extending the principle of *DevSecOps* to ongoing software
+development. DevSecOps refers to a software development philosophy which has two principal tenets:
+
+* Good security practice applies to *all* parts of software development, including ongoing “business
+ as usual†development, rather than being something solely to be layered on after the fact at
+ deployment time or before the fact at design time.
+* Security practices which are amenable to automation should be automated in order to increase
+ developer productivity and ensure consistency of approach.
+
+The holistic approach to security embodied in DevSecOps means that each stage of development should
+have processes and practices added to contribute to the overall security of a system.
+
+## Applicability
+
+This standard should be implemented for all services that the university develops, whether
+internally, or through third parties. It is particularly relevant to services that handle sensitive
+data or support important processes, where a security breach could have significant negative
+impacts.
+
+Exceptions can be submitted following the exemption process within the Systems Management Policy
+informing and seeking approval of the Tech Leads Forum first.
+
+## Scope
+
+This document focuses specifically on DevSecOps practices applicable to ongoing software development
+that can be automated or semi-automated. It doesn't cover:
+
+* Security-first architectural design decisions (e.g., zero-trust communication).
+* Practical security measures for deployments (e.g., principle of least privilege, strong audit
+ records).
+* Non-automated DevSecOps practices (e.g., ongoing engineer training).
+
+These topics are left for a separate document.
+
+## Terminology
+
+Within DevOps we manage a number of ***services*** which are formed of software ***components***
+along with ***deployment configurations*** which connect these components together using Cloud
+resources. Software components have ***dependencies*** which are other software components which a
+given software component uses to implement functionality.
+
+A specific example of a ***service/product*** is the Postgraduate Funding Portal. An example of a
+software component within that service is the Postgraduate Funding Portal Frontend user interface.
+The frontend, in turn, makes use of the PDFBox ***software library*** which is maintained by the
+Apache Software Foundation. As of writing, the specific ***version*** of PDFBox in use is “2.0.24â€.
+PDFBox is a ***dependency*** of the Postgraduate Funding Portal Frontend. The PDFBox library may
+itself make use of other components. These components are ***indirect dependencies*** of the
+Postgraduate Funding Portal.
+
+The full list of indirect and direct dependencies along with their versions is colloquially termed a
+***bill of materials*** (BoM) and the locations where those components were downloaded from is
+similarly referred to as the ***supply chain*****.** Both of these terms are borrowed from physical
+manufacturing.
+
+A bug in a software component which may have security implications is termed a ***vulnerability***.
+
+For software, a ***release*** will have an associated ***version number*** and ***build artefact***.
+The build artefact is generally speaking a container image or a programming language specific
+package. In either case the build artefacts are uploaded to an appropriate ***artefact registry***
+where they may be retrieved given the package name and version number.
+
+For deployments, the code which specifies the deployments will contain the exact version numbers of
+each software component. In this case, we tend to use a version identifier assigned by git itself
+called the commit SHA. For the purposes of this document, the commit SHA is considered to act like a
+version number. The version number of a deployment uniquely identifies both the way that the
+components are deployed and the components themselves. For deployments which
+use [GitLab’s inbuilt automation to deploy](../explanations/gitlab-release-automation.md), once
+changes from a MR are merged track which version is deployed to each of the production, staging and
+development environments. This information is available from a dedicated “environments†page in
+GitLab.
+
+## Standards
+
+This section contains the standard practices to be adopted.
+
+### Protected Branches
+
+A protected branch is a special branch in a code project that's locked down to keep it safe. This is
+important because it often contains the final, working version of the code, also known as production
+code.
+
+What happens when a branch is protected?
+
+* No accidental changes: No one can accidentally delete or change the code in this branch by pushing
+ to it.
+* Review needed: In order to make changes to this branch a Merge Requests needs to be opened. This
+ ensures that other people, with rights to approve and merge, have to look over and approve any
+ changes before they're added to the protected branch. More on this later.
+* Extra checks: Before any changes can be made, the code has to pass special tests that are executed
+ when the Merge Request is opened. More on this later.
+
+This helps make sure that the code is always working correctly and doesn't get broken by mistakes.
+
+### Merge Requests and the review process
+
+Software, [documentation on our practices and processes](https://gitlab.developers.cam.ac.uk/uis/devops/docs/guidebook/)
+and [Infrastructure as Code](https://en.wikipedia.org/wiki/Infrastructure_as_code) (IaC) used to
+deploy services must be version controlled and reviewable. Manual deployments and manual
+configuration of services must be avoided so that we retain confidence that the machine-readable
+description of how services are deployed and configured continue to reflect reality.
+
+Use git source code management (SCM)
+and [the university’s GitLab instance](https://gitlab.developers.cam.ac.uk/) to manage versions of
+code over time. Code committed to our Gitlab instance allows other members to see, propose and
+review changes. When a team member wishes to propose a change to some code, they open a Merge
+Request (MR) which should contains the following information:
+
+* the changes they wish to make, split into separately reviewable chunks known as *commits*,
+* a description of each commit which [focuses on the *why* rather than the
+ *what* of the change](../explanations/git.md#commits), and
+* an overall description of the change which may make reference to existing *issues* which describe
+ the agreed objectives of the change.
+
+The team member who created the MR is termed the *author*. Other(s) team member(s), the *reviewer(
+s)*, will look over the proposed change. As part of that process, the reviewer(s) may ask questions
+or suggest changes. Once the reviewer(s) is/are satisfied that they understand the change and that
+it meets the objectives in the related issue, they mark the MR as *approved*. Once approved, the MR
+is “merged†into the main body of the code. Teams differ on whether they prefer the reviewer or
+author to instigate the merge once approved but for the purposes of this document there is little
+difference between the two approaches.
+
+The GitLab project where the code is hosted will be configured to require a reviewer(s) approval of
+a MR before it can be merged. “Branch protection†will also be enabled so that changes to the code
+may only be made via MRs
+
+### Common Continuous Integration pipeline configurations
+
+GitLab allows automated tasks to be triggered when changes are merged or proposed for merging. These
+are called *continuous integration (CI) pipelines*. We have a common pipeline configuration which
+runs a number of security-related tasks, most of them inherited from GitLab’s AutoDevOps.
+
+Some processes below require the [common CI pipeline](../howtos/add-common-pipeline-to-python.md)
+be enabled for repositories and to
+follow [Continuous Integration and Continuous Delivery (CI/CD) standards](./devsecops-cicd.md).
+
+### Dependency pinning
+
+Historically we’ve tolerated, but not recommended, software dependencies being specified with loose
+version requirements. E.g. “anything later than 2.3â€, etc. This has meant that it was not always
+possible to determine uniquely which version of each dependency was deployed alongside a particular
+version of our software components.
+
+We’ve tightened up our policy recently and now require not only that exact language-specific
+dependency versions be “pinned†but also, where packaging frameworks allow, that cryptographic
+hashes of dependency packages be recorded in repositories so that we may verify at build time that
+the supply chain has provided us the version of the dependency we expect.
+
+For imports in HTML files, make sure that hashes are included when possible.
+
+### Dependency and container scanning
+
+The [common CI pipeline](https://docs.google.com/document/d/14Ob5uZVJ-l9Tb-JlU2ouxcTfSOqPA_gKeoCCZAyyPVE/)
+includes a task which examines dependency versions which are included in the build artefacts. For
+artefacts which are containers, this scanning extends to Operating System packages. The use of
+dependency pinning now means that build artefacts for a given version will have identical
+dependencies installed, even if they are re-built at a later date.
+
+When a MR introduces new dependencies with known vulnerabilities, this is reported in the MR UI for
+the reviewer to review.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Dependency scanning results presented in the MR UI.
+ </figcaption>
+</figure>
+
+The full report links each vulnerability to a corresponding CVE and provides means for reviewers to
+get more information, to open issues so that fixes can be applied at a later date when available or
+to manually dismiss issues which they deem to be irrelevant.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The full security report for a real MR.
+ </figcaption>
+</figure>
+
+New Critical or High vulnerability reports should never be ignored. A solution for them, if these
+exist, should be applied as soon as possible, unless there is a strong reason not to. If after
+reviewing these a false positive is detected, it should be noted in GitLab when dismissing the
+vulnerability report.
+
+### Automated dependency updates
+
+Vulnerabilities may be found in existing dependencies. A common DevSecOps practice is to have an
+automated process which periodically compares dependencies in software components to vulnerability
+databases and propose updates to dependency versions when appropriate. UIS DevOps
+use [Renovate Bot](https://github.com/renovatebot/renovate). This automatically opens MRs to update
+dependency versions when appropriate.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ A real MR generated by Renovate Bot.
+ </figcaption>
+</figure>
+
+Renovate Bot is enabled for all DevOps repositories. Renovate Bot merge requests need to be reviewed
+and applied, if deemed necessary, periodically.
+
+### Automated release and versioning
+
+Our goal of being able to state with confidence whether a given deployed environment of a service
+contains a given vulnerability requires that we be consistent in how we release, version and package
+our software. UIS DevOps has developed
+a [release automation](../tutorials/automating-gitlab-releases.md) process which takes away much
+of the manual process of versioning new releases. This removes opportunities for human error. All
+services must adopt this practice.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ A real MR generated by our release automation process.
+ </figcaption>
+</figure>
+
+### Automated deployments
+
+In order to be able to tie versions of dependencies to deployed environments, UIS DevOps has
+developed [automation around deployments](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/terraform-pipeline.yml).
+Currently, staging environments automatically track the current version of service and automated
+deployment of a selected version of a service to production may be manually triggered by a
+sufficiently privileged team member.
+
+When deployed to an environment, the MR corresponding to the version deployed shows which
+environments it has been deployed to and when.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ UI within a real MR showing the deployment history of a version.
+ </figcaption>
+</figure>
+
+The currently deployed version can be seen on a dashboard. Thus if we know that a particular version
+contains a critical vulnerability, we can check that it is not currently deployed.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Dashboard showing current deployments of a real service.
+ </figcaption>
+</figure>
+
+All services must adopt this practice.
+
+### Security Scanning
+
+In addition to container and dependency scanning, GitLab supports proactive scanning for *new*
+vulnerabilities.
+
+#### Static
+
+Use
+our [common CI pipeline](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/common-pipeline.yml?ref_type=heads)
+to
+enable [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
+within GitLab. This is a process which analyses the code for common vulnerability patterns. For
+example, it is easy to detect when one calls a SQL database API passing a non-constant string value
+and this can be indicative of a potential SQL injection vulnerability.
+
+Because we are using Infrastructure as Code, this means we can also apply static security scanning
+to this code. Use
+our [common CI pipeline](https://gitlab.developers.cam.ac.uk/uis/devops/continuous-delivery/ci-templates/-/blob/master/auto-devops/common-pipeline.yml?ref_type=heads)
+to
+enable [Infrastructure as Code Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)
+which currently uses [KICS](https://github.com/Checkmarx/kics) to identify vulnerabilities in
+Ansible, Terraform, Docker, or Kubernetes configuration files.
+
+As part of our common pipeline, SAST and IaCS are commonplace in DevOps and SAST and IaCS reports
+are present in the MR UI.
+
+New Critical or High vulnerability reports should never be ignored. A solution for them, if these
+exist, should be applied as soon as possible, unless there is a strong reason not to. If after
+reviewing these a false positive is detected, it should be noted in GitLab when dismissing the
+vulnerability report.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ An example of a SAST report in the MR UI taken from the GitLab documentation.
+ </figcaption>
+</figure>
+
+#### Dynamic
+
+GitLab
+supports [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/)
+which runs common automated attacks against a deployed environment.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ Example configuration of DAST for a service.
+ </figcaption>
+</figure>
+
+You should enable DAST scans on deployed instances.
+
+GitLab supports the concept of [review apps](https://docs.gitlab.com/ee/ci/review_apps/) which are
+instances of an application which exist for the lifetime of a MR which have the proposed changes
+incorporated. DAST can be configured to run against review apps in order to provide additional
+security reporting within MRs.
+
+Review apps are not yet supported by our common pipeline and they are under investigation.
+
+### Secret detection
+
+GitLab
+supports [detecting leaked secrets in MRs and git branches](https://docs.gitlab.com/ee/user/application_security/secret_detection/).
+This is enabled as part of our common pipeline by using GitLab’s AutoDevOps. While GitLab supports
+auto revocation of secrets by triggering some action, the wide variety of secrets which *could* be
+inadvertently added to a repository means that a “one size fits all†approach is not yet feasible.
+Instead, you must use secret detection in pre-commit checks as well as adopting a security policy
+which alerts MR reviewers of leaked secrets in a timely manner.
+
+### Secret
+
+Local developer machines should not have copies of secrets. While this is not always possible,
+whenever possible secrets should be “fetch-on-need†where the secret is fetched from 1Password on
+need using our 1Password CLI module and does not persist on disk.
+
+### Proactive triage of vulnerabilities
+
+GitLab generates a vulnerability report for groups and projects. The data from this report comes
+from SAST, dependency and container scanning CI tasks. As such these must be enabled and have
+periodic scheduled scans for the dashboards to reflect all new vulnerabilities and those who have
+been resolved. Within this report, vulnerabilities may be triaged and thence classified into one of
+the following statuses provided by GitLab:
+
+* **Confirm**. The vulnerability is a true positive and requires a fix. This includes opening an
+ issue.
+* **Resolve.** The vulnerability has been mitigated.
+* **Acceptable risk.** The vulnerability has not been mitigated but is deemed an acceptable business
+ risk.
+* **False positive.** Upon examination, the vulnerability is not present.
+* **Mitigating control.** The vulnerability has not been directly mitigated but controls surrounding
+ the service ensure that the circumstances of the vulnerability cannot occur. For example, a
+ vulnerability may relate to non-signed in users but a service which mandates sign-in would not be
+ vulnerable.
+* **Used in tests.** Usually for SAST vulnerabilities, this marks a potential vulnerability in code
+ as being intentionally used as part of automated testing.
+* **Not applicable.** The vulnerability is known and not mitigated but relates to an unused part of
+ the dependency.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ The vulnerability triage board for a UIS DevOps service.
+ </figcaption>
+</figure>
+
+Security policies must be enabled which mandate the triage of new vulnerabilities.
+
+The dashboard should be reviewed in every work iteration (e.g. sprint) to make sure that any
+potential Critical or High vulnerability is resolved in a timely manner. This needs to be embedded
+in all teams' cultures, including non-technical members of staff.
+
+#### Security metrics dashboard / reporting
+
+GitLab provides group- and project-level security dashboards which allow one to gain a sense of how
+a particular service is doing in terms of dealing with vulnerabilities.
+
+<figure markdown>
+ 
+ <figcaption markdown>
+ A real example of a security dashboard from a UIS DevOps service
+ </figcaption>
+</figure>
+
+### Common configuration policies for GitLab projects
+
+Some of the practices in this document involve automation surrounding MR approval policies. These
+practices have no teeth unless it is mandatory that a) all MRs must be approved and b) the only way
+changes can be merged is through MRs.
+
+Although this has long been the recommended configuration for GitLab projects in UIS DevOps, until
+recently we have had no way of enforcing it; GitLab project creation and configuration was a manual
+process.
+
+We have
+now [automated the provisioning of GitLab projects](../howtos/bootstrap-a-product.md#create-the-gitlab-projects)
+and have begun importing existing projects into this automation. This allows us to centralise and
+standardise the configuration of GitLab projects. **At a minimum GitLab projects are now created
+with mandatory MR approval and branch protection.** Deviations from this policy are detected and
+corrected by our IaC tooling. As of writing, detection and correction of deviations is performed
+automatically but triggered manually. As we gain confidence in the robustness of our automation, we
+plan to run this process automatically and frequently as a scheduled job.
+
+Having laid the groundwork to be able to specify and automatically apply Division-wide policies on
+GitLab project configuration, we are now in a position to roll out additional DevSecOps practices
+surrounding security policies as detailed below.
+
+### Security policies
+
+GitLab supports configuring projects
+with [security policies](https://docs.gitlab.com/ee/user/application_security/policies/) which
+enable enforcement of DevSecOps policies. The common configuration policy described above allows us
+to do so.
+
+#### Scheduled scan execution policies
+
+Dependency, container and SAST, and IaCS scanning are by default only being performed for MRs so
+that security reports can be generated in the UI. A further scan is run once when the change is
+merged. If no changes are made to a software component, scans will not be repeated meaning that new
+vulnerabilities may not be detected.
+
+GitLab security policies allow scheduled scans to be performed which keep the vulnerability
+information up-to-date in the security
+dashboard. [Dependency and container scanning will run at least once a week](https://gitlab.developers.cam.ac.uk/groups/uis/devops/-/security/policies).
+
+#### Merge Request approval policies
+
+Security policies will enforce the following practice:
+
+* MRs which have newly detected vulnerabilities which are classed as “medium†or “low†risk require
+ *additional* approval, possibly from a small group of trusted approvers.
+* MRs which have newly detected vulnerabilities which are classed as “high†or “critical†risk
+ require that the vulnerabilities be examined by a trusted approver and must be explicitly marked
+ as not-relevant before a MR can be merged.
+
+## Discussion
+
+### Vulnerability databases
+
+Not all bugs are vulnerabilities.
+The [Common Vulnerabilities and Exposures](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)
+(CVE) database is one effort to collect and categorise security-related bugs and to provide stable
+identifiers for them. Said identifiers, or *CVE numbers*, are issued by a family of CVE Numbering
+Authorities (CNAs). It is possible, in principle, to use a complete BoM for a service along with the
+CVE database to enumerate all CVE bugs which are outstanding for that service.
+
+Not all vulnerabilities are equal in severity or applicability. Determining the effect that a given
+vulnerability has on a service often requires in-depth knowledge of that service. Although
+the [Common Vulnerability Scoring System](https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System)
+(CVSS) may help in that determination, there is still some nuance of understanding required.
+
+CVEs and their associated CVSS scores provide quantifiable *metrics* for services which can be used
+to track the waxing and waning of vulnerabilities in a service over time. In accordance
+with [Goodhart’s Law](https://en.wikipedia.org/wiki/Goodhart%27s_law) it is important that any
+DevSecOps strategy recognises the distinction between a metric and a target.
+
+As a specific example of the above, it is tempting but ultimately counterproductive to have a
+*target* that zero CVEs be present in a service. Three reasons why this is not desirable are as
+follows:
+
+* **A CVE may not yet have mitigations which involve simply updating dependency versions.** In such
+ cases, the CVEs will remain “present†in a service but may have been mitigated by disabling some
+ functionality or introducing additional configuration.
+* **A CVE may be bogus.** There is some controversy about the quality of entries in the CVE database
+ and many vendors have sought to become CNAs for their product simply to retain control over the
+ quality of CVEs issued. As a recent example, the curl
+ project [became a CNA](https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/) in January 2024 in
+ order
+ to [deal with bogus CVEs](https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/).
+ Even as a CNA, the curl
+ project [cannot remove a bogus CVE from the database](https://daniel.haxx.se/blog/2024/02/21/disputed-not-rejected/).
+ Early career security engineers have started including “number of CVEs reported†on their CVs
+ which has led to a notable increase in poor-quality CVEs or
+ even [ones which have been fabricated by Large Language Models](https://mastodon.social/@bagder/111245232072475867).
+* **A CVE may affect only a non-applicable use case or relate to part of a dependency which is not
+ in use.** As a recent example, the bulk of our software makes use of the Linux kernel and in
+ February
+ 2024 [the Linux kernel project became a CNA](http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/).
+ This is notable because of how the Linux kernel developers intend to issue CVEs. Their opinion is
+ that, due to the low-level nature of the kernel, virtually all bugs *may* have a security impact
+ and so
+ they [intend to be extremely inclusive in what bugs will be assigned CVEs](https://lwn.net/SubscriberLink/961978/1fec3e8a4a8356f7/).
+ A consequence of this decision is that each stable version of the Linux kernel will likely be
+ released with several thousand new CVEs. It is not appropriate to use engineering resources
+ reviewing each and every one of those CVEs for potential mitigation steps since the vast majority
+ of them will not apply to our use cases. Even if we were to be able to review several thousand
+ CVEs for each new release, we are limited to indirect mitigation rather than update. This is
+ because for the majority of our deployments we do not control the exact version of the kernel as
+ it forms part of the hosting platform provided by our Cloud vendor. Vulnerabilities may not
+ directly affect us due to the nature of deployment. For example, denial of service or resource
+ exhaustion vulnerabilities in JavaScript libraries can have limited scope; if the JavaScript is
+ purely frontend an individual user’s session may be affected but no service-wide disruption is
+ likely as no server-side JavaScript code is present.
+
+Counts of CVEs and severity scoring systems such as CVSS *are* useful when used as metrics. For
+example, it is an appropriate use of CVEs to flag MRs if they significantly increase the number of
+CVEs present and to require additional review and triage of the new CVEs. Similarly it is a
+reasonable use of resources to triage newly issued CVEs which have been assigned a “high†impact at
+time of detection but to leave triaging of CVEs which are “low†impact to a process performed once
+per sprint.
+
+## Summary
+
+Practices to be implemented:
+
+* Enable dependency scanning.
+* Enable container scanning for projects which build container images.
+* Enable SAST security scanning for software and IaCS for infrastructure as code projects.
+* Enable secret detection.
+* Pin all dependency versions via “lock†files. When possible these should include cryptographic
+ hashes of the dependency packages.
+* Ensure all components have stable version numbers and automate version numbering.
+* Automate release and changelog generation.
+* Automate deployment via GitLab so that a record is kept of which versions are deployed to what
+ environments.
+* Bring all GitLab projects under the control of our GitLab project automation so that consistent
+ configuration can be enforced.
+* Enable security policies for all GitLab projects to ensure scheduled security scans are run.
+* Enable security policies for all GitLab projects to place additional approval and triage
+ requirements on MRs which introduce newly detected vulnerabilities.
+* Configure Renovate Bot to open MRs for all projects when vulnerabilities are found in existing
+ dependencies and those vulnerabilities can be mitigated by updating the dependency.
+* Enable proactive *dynamic* security scanning against staging instances of services.
+* Newly detected vulnerabilities for MRs must be triaged and categorised.
+* Project Managers should factor the security dashboard output into project management decisions.
+* Existing vulnerabilities should be triaged as a background process.
+
+## Related standards
+
+[DevOps Continuous Integration and Continuous Delivery (CI/CD) standards](./devsecops-cicd.md)
+
+[DevSecOps standards for Continuous Deployment](./devsecops-cd.md)
diff --git a/docs/standards-and-compliance/images/changemanagement-1.png b/docs/standards-and-compliance/images/changemanagement-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..d88bc8c442c3adb3bd356c406c3806867bd2d3e8
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-1.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-2.png b/docs/standards-and-compliance/images/changemanagement-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..f621b00e9b6d7e7aa7ff941dc823a0b45f6d2a77
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-2.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-3.png b/docs/standards-and-compliance/images/changemanagement-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d9154d36dfc673129341e47ff8dc9e77217c9d2
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-3.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-4.png b/docs/standards-and-compliance/images/changemanagement-4.png
new file mode 100644
index 0000000000000000000000000000000000000000..17ec198d5d0f67205d90ced3f2547af09514396b
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-4.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-5.png b/docs/standards-and-compliance/images/changemanagement-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..54f0f78424801a0df560236ecec5b951e6a3908f
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-5.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-6.png b/docs/standards-and-compliance/images/changemanagement-6.png
new file mode 100644
index 0000000000000000000000000000000000000000..755e4a5f8547afbeced4c19b47bec6179f1c1113
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-6.png differ
diff --git a/docs/standards-and-compliance/images/changemanagement-7.png b/docs/standards-and-compliance/images/changemanagement-7.png
new file mode 100644
index 0000000000000000000000000000000000000000..983fb67d0b8e5b44b798503cef4b8eccf27752cf
Binary files /dev/null and b/docs/standards-and-compliance/images/changemanagement-7.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cd-1.png b/docs/standards-and-compliance/images/devsecops-cd-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..b127d1eaf99096936f96e0b09be1b80f546e4c22
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cd-1.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-1.png b/docs/standards-and-compliance/images/devsecops-cicd-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..2e83028faa24dd4c6d9526321067e4bbd74b93c0
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-1.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-2.png b/docs/standards-and-compliance/images/devsecops-cicd-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..b3c314f7c89ebdfcaa549775259d266fdeb539fc
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-2.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-3.png b/docs/standards-and-compliance/images/devsecops-cicd-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..391ed43c01b0b72ad5d67f8a51a19682bbd0837f
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-3.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-4.png b/docs/standards-and-compliance/images/devsecops-cicd-4.png
new file mode 100644
index 0000000000000000000000000000000000000000..9a5eed55575a5b248852f538f4d45da5b08d09ee
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-4.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-5.png b/docs/standards-and-compliance/images/devsecops-cicd-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..17ec198d5d0f67205d90ced3f2547af09514396b
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-5.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-6.png b/docs/standards-and-compliance/images/devsecops-cicd-6.png
new file mode 100644
index 0000000000000000000000000000000000000000..2437bd22e1df91037f895804bd6ac1fd2ceefdf5
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-6.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-7.png b/docs/standards-and-compliance/images/devsecops-cicd-7.png
new file mode 100644
index 0000000000000000000000000000000000000000..19844efb36c6b3bb2c3f6c5e2b5508a207431d83
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-7.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-8.png b/docs/standards-and-compliance/images/devsecops-cicd-8.png
new file mode 100644
index 0000000000000000000000000000000000000000..f621b00e9b6d7e7aa7ff941dc823a0b45f6d2a77
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-8.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-cicd-9.png b/docs/standards-and-compliance/images/devsecops-cicd-9.png
new file mode 100644
index 0000000000000000000000000000000000000000..c4c151752b577dbd379b2e2ee8870895d1f4bded
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-cicd-9.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-1.png b/docs/standards-and-compliance/images/devsecops-dev-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..8f485a98650e43cb76fc02b295138fa4e12eaa63
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-1.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-10.png b/docs/standards-and-compliance/images/devsecops-dev-10.png
new file mode 100644
index 0000000000000000000000000000000000000000..112caee8fc4e575ddf3f62b06abdd44f05469436
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-10.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-2.png b/docs/standards-and-compliance/images/devsecops-dev-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..01029027e7eca31f8ba2ead4eecdc9beb8e515d3
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-2.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-3.png b/docs/standards-and-compliance/images/devsecops-dev-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..36955196fb1bd90a426aa4a748a8a9256ff29c60
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-3.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-4.png b/docs/standards-and-compliance/images/devsecops-dev-4.png
new file mode 100644
index 0000000000000000000000000000000000000000..f70f08fadc2dac07459994f73454c3e24ae09752
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-4.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-5.png b/docs/standards-and-compliance/images/devsecops-dev-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..d7661990551ca2cbffbb297fd18b98dcfb36bc4f
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-5.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-6.png b/docs/standards-and-compliance/images/devsecops-dev-6.png
new file mode 100644
index 0000000000000000000000000000000000000000..3953767ab4ea3db8730e54c0a8f56ed2920e91e3
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-6.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-7.png b/docs/standards-and-compliance/images/devsecops-dev-7.png
new file mode 100644
index 0000000000000000000000000000000000000000..91b830fa1826ac16e3fe5e2464ef0aacec3ba777
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-7.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-8.png b/docs/standards-and-compliance/images/devsecops-dev-8.png
new file mode 100644
index 0000000000000000000000000000000000000000..c5371e31af1a1af3076d09c3c3deac0872197e01
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-8.png differ
diff --git a/docs/standards-and-compliance/images/devsecops-dev-9.png b/docs/standards-and-compliance/images/devsecops-dev-9.png
new file mode 100644
index 0000000000000000000000000000000000000000..4497e7ee51d0a0caac6416393bc22ba005a5dfca
Binary files /dev/null and b/docs/standards-and-compliance/images/devsecops-dev-9.png differ
diff --git a/docs/standards-and-compliance/index.md b/docs/standards-and-compliance/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..f09f402a239b6584a56b057d64cdb3b72cc0868d
--- /dev/null
+++ b/docs/standards-and-compliance/index.md
@@ -0,0 +1,7 @@
+---
+title: Standards
+---
+
+# Standards and compliance
+
+This section of the guidebook contains information on our standards and compliance requirements.
diff --git a/docs/reference/standards-and-compliance/apis.md b/docs/standards-and-compliance/non-functional-requirements/apis.md
similarity index 100%
rename from docs/reference/standards-and-compliance/apis.md
rename to docs/standards-and-compliance/non-functional-requirements/apis.md
diff --git a/docs/reference/standards-and-compliance/availability.md b/docs/standards-and-compliance/non-functional-requirements/availability.md
similarity index 100%
rename from docs/reference/standards-and-compliance/availability.md
rename to docs/standards-and-compliance/non-functional-requirements/availability.md
diff --git a/docs/reference/standards-and-compliance/gcp.md b/docs/standards-and-compliance/non-functional-requirements/gcp.md
similarity index 100%
rename from docs/reference/standards-and-compliance/gcp.md
rename to docs/standards-and-compliance/non-functional-requirements/gcp.md
diff --git a/docs/reference/standards-and-compliance/index.md b/docs/standards-and-compliance/non-functional-requirements/index.md
similarity index 89%
rename from docs/reference/standards-and-compliance/index.md
rename to docs/standards-and-compliance/non-functional-requirements/index.md
index 3b378593ab164b67dfa365b766bfa6ad5b9bd6de..cbd97ea794186067315b3759f52fc924445b9703 100644
--- a/docs/reference/standards-and-compliance/index.md
+++ b/docs/standards-and-compliance/non-functional-requirements/index.md
@@ -1,15 +1,14 @@
-# Standards and Compliance
-## NFRs
+# Non-functional requirements (NFRs)
-This sections includes information that relates to UIS published NFRs and
-documents potential means to complete some of the NFRs.
+This sections includes information that relates to UIS published Non-functional requirements
+(NFRs) and documents potential means to complete some of the NFRs.
It is hoped this effort will improve the degree of NFR compliance in a scalable
manner, including helping to drive decisions on tooling and practices to
support this.
-### Completing NFRs
+## Completing NFRs
These documents are not intended as a means to skip the NFR process. Those
completing NFRs need to read each NFR question and all the information in each
diff --git a/docs/reference/standards-and-compliance/ownership.md b/docs/standards-and-compliance/non-functional-requirements/ownership.md
similarity index 100%
rename from docs/reference/standards-and-compliance/ownership.md
rename to docs/standards-and-compliance/non-functional-requirements/ownership.md
diff --git a/docs/reference/standards-and-compliance/security.md b/docs/standards-and-compliance/non-functional-requirements/security.md
similarity index 100%
rename from docs/reference/standards-and-compliance/security.md
rename to docs/standards-and-compliance/non-functional-requirements/security.md
diff --git a/docs/reference/standards-and-compliance/template.md b/docs/standards-and-compliance/non-functional-requirements/template.md
similarity index 100%
rename from docs/reference/standards-and-compliance/template.md
rename to docs/standards-and-compliance/non-functional-requirements/template.md
diff --git a/docs/reference/standards-and-compliance/user-concurrency.md b/docs/standards-and-compliance/non-functional-requirements/user-concurrency.md
similarity index 100%
rename from docs/reference/standards-and-compliance/user-concurrency.md
rename to docs/standards-and-compliance/non-functional-requirements/user-concurrency.md
diff --git a/docs/reference/standard-architecture-diagrams.md b/docs/standards-and-compliance/standard-architecture-diagrams.md
similarity index 100%
rename from docs/reference/standard-architecture-diagrams.md
rename to docs/standards-and-compliance/standard-architecture-diagrams.md
diff --git a/docs/explanations/tech-lead-forum.md b/docs/standards-and-compliance/tech-lead-forum.md
similarity index 100%
rename from docs/explanations/tech-lead-forum.md
rename to docs/standards-and-compliance/tech-lead-forum.md
diff --git a/mkdocs.yml b/mkdocs.yml
index 5e88389af0f4be8d2b82aa5bf918a9b0cf1cc869..2bb604e7995052c8a9d4ba111bdbb9f44f789bb7 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -12,6 +12,119 @@ nav:
- contact/public-keys.md
- guidebook.md
- contact/teams.md
+ - "Standards":
+ - standards-and-compliance/devsecops-dev.md
+ - standards-and-compliance/devsecops-cicd.md
+ - standards-and-compliance/devsecops-cd.md
+ - standards-and-compliance/change-management.md
+ - standards-and-compliance/tech-lead-forum.md
+ - standards-and-compliance/standard-architecture-diagrams.md
+ - "Non-Functional Requirements":
+ - standards-and-compliance/non-functional-requirements/index.md
+ - "Our Services":
+ - services/index.md
+ - "Education":
+ - services/camdata.md
+ - services/gates-trust-selection-module.md
+ - "Digital Admissions":
+ - services/digital-pooling.md
+ - services/my-cambridge-application.md
+ - services/essm-sync.md
+ - services/events.md
+ - services/examoffice.md
+ - "Laboratory Allocation":
+ - services/lab-allocator.md
+ - services/legacy-nst-ia-labs.md
+ - "Lecture Capture":
+ - services/panopto-deployment.md
+ - services/panel.md
+ - services/streaming-media.md
+ - services/utbs.md
+ - services/yuja.md
+ - "HR Systems":
+ - services/caias.md
+ - services/hr-integration-app.md
+ - services/integrated-reward-system.md
+ - services/job-opportunities.md
+ - services/postbox.md
+ - services/recruitment-administration-system.md
+ - services/web-recruitment-system.md
+ - services/ada.md
+ - services/acp-12-submission-portal.md
+ - "Infrastructure and Generic Services":
+ - services/api-gateway.md
+ - services/design-system.md
+ - services/data-backup.md
+ - services/equipshare.md
+ - services/gaobase.md
+ - services/gitlab.md
+ - "Governance":
+ - services/governance.md
+ - services/reporter.md
+ - services/statutes-and-ordinances.md
+ - "Identity and Access Management":
+ - services/activate-account.md
+ - "Card Management":
+ - services/card-management-system.md
+ - services/legacy-card-db.md
+ - services/eduroam-tokens.md
+ - services/gsuite.md
+ - services/gsuite-preferences.md
+ - services/iam-overview.md
+ - services/jackdaw.md
+ - services/lookup.md
+ - "Raven":
+ - services/passwords.md
+ - services/raven-metadata.md
+ - services/raven-oauth.md
+ - services/raven-saml2-shim.md
+ - services/raven-shibboleth.md
+ - services/raven-stats.md
+ - services/raven-ucamwebauth.md
+ - services/university-human-resources-api.md
+ - services/university-student-api.md
+ - services/information-asset-register.md
+ - services/lookup-gitlab-sync.md
+ - services/malware-and-virus-scanner.md
+ - services/nursery-waiting-list.md
+ - services/regent-house-ballots.md
+ - services/scribe.md
+ - services/self-service-gateway.md
+ - services/symphony.md
+ - services/talks-cam.md
+ - services/ups-service-definition.md
+ - "Research":
+ - services/ref-portals.md
+ - services/budget-calculator.md
+ - services/claims-management-system.md
+ - services/gates-trust.md
+ - services/hta.md
+ - services/interfacer.md
+ - services/rco-database.md
+ - services/rgea.md
+ - services/research-dashboard.md
+ - services/ronin.md
+ - services/roo-intranet.md
+ - services/sissp.md
+ - services/staff-information-system.md
+ - services/time-allocation-survey.md
+ - services/TOAST.md
+ - "Internal":
+ - services/renovatebot.md
+ - services/user-notify.md
+ - "Retired Services":
+ - services/covid-pooled-testing.md
+ - services/lecture-capture-preferences.md
+ - services/software-sales.md
+ - services/tls-certificates.md
+ - "Libraries & Tools":
+ - libraries-tools/index.md
+ - "Git, CI & Docker":
+ - libraries-tools/git-ci-docker/index.md
+ - "GCP & Terraform":
+ - libraries-tools/gcp-terraform/index.md
+ - "Python":
+ - libraries-tools/python/index.md
- "How-to":
- howtos/index.md
- "Products":
@@ -96,7 +209,7 @@ nav:
- explanations/service-infrastructure.md
- explanations/identifiers.md
- explanations/webapp-boilerplate.md
- - explanations/tech-lead-forum.md
+ - standards-and-compliance/tech-lead-forum.md
- explanations/renovatebot.md
- "Cloud Platform":
- explanations/gcp-budgets-alerts.md
@@ -117,9 +230,6 @@ nav:
- external-docs.md
- reference/identifiers.md
- reference/webapp-developer-environment.md
- - reference/tech-lead-forum.md
- - reference/standards-and-compliance/index.md
- - reference/standard-architecture-diagrams.md
- reference/vulnerability-triage-process.md
- reference/openapi-client-generation.md
- "Git/GitLab":
@@ -178,110 +288,6 @@ nav:
- notes/internal-ca.md
- notes/raven-test-sites.md
- notes/faq.md
- - "Our Services":
- - services/index.md
- - "Education":
- - services/camdata.md
- - services/gates-trust-selection-module.md
- - "Digital Admissions":
- - services/digital-pooling.md
- - services/my-cambridge-application.md
- - services/essm-sync.md
- - services/events.md
- - services/examoffice.md
- - "Laboratory Allocation":
- - services/lab-allocator.md
- - services/legacy-nst-ia-labs.md
- - "Lecture Capture":
- - services/panopto-deployment.md
- - services/panel.md
- - services/streaming-media.md
- - services/utbs.md
- - services/yuja.md
- - "HR Systems":
- - services/caias.md
- - services/hr-integration-app.md
- - services/integrated-reward-system.md
- - services/job-opportunities.md
- - services/postbox.md
- - services/recruitment-administration-system.md
- - services/web-recruitment-system.md
- - services/ada.md
- - services/acp-12-submission-portal.md
- - "Infrastructure and Generic Services":
- - services/api-gateway.md
- - services/design-system.md
- - services/data-backup.md
- - services/equipshare.md
- - services/gaobase.md
- - services/gitlab.md
- - "Governance":
- - services/governance.md
- - services/reporter.md
- - services/statutes-and-ordinances.md
- - "Identity and Access Management":
- - services/activate-account.md
- - "Card Management":
- - services/card-management-system.md
- - services/legacy-card-db.md
- - services/eduroam-tokens.md
- - services/gsuite.md
- - services/gsuite-preferences.md
- - services/iam-overview.md
- - services/jackdaw.md
- - services/lookup.md
- - "Raven":
- - services/passwords.md
- - services/raven-metadata.md
- - services/raven-oauth.md
- - services/raven-saml2-shim.md
- - services/raven-shibboleth.md
- - services/raven-stats.md
- - services/raven-ucamwebauth.md
- - services/university-human-resources-api.md
- - services/university-student-api.md
- - services/information-asset-register.md
- - services/lookup-gitlab-sync.md
- - services/malware-and-virus-scanner.md
- - services/nursery-waiting-list.md
- - services/regent-house-ballots.md
- - services/scribe.md
- - services/self-service-gateway.md
- - services/symphony.md
- - services/talks-cam.md
- - services/ups-service-definition.md
- - "Research":
- - services/ref-portals.md
- - services/budget-calculator.md
- - services/claims-management-system.md
- - services/gates-trust.md
- - services/hta.md
- - services/interfacer.md
- - services/rco-database.md
- - services/rgea.md
- - services/research-dashboard.md
- - services/ronin.md
- - services/roo-intranet.md
- - services/sissp.md
- - services/staff-information-system.md
- - services/time-allocation-survey.md
- - services/TOAST.md
- - "Internal":
- - services/renovatebot.md
- - services/user-notify.md
- - "Retired Services":
- - services/covid-pooled-testing.md
- - services/lecture-capture-preferences.md
- - services/software-sales.md
- - services/tls-certificates.md
- - "Libraries & Tools":
- - libraries-tools/index.md
- - "Git, CI & Docker":
- - libraries-tools/git-ci-docker/index.md
- - "GCP & Terraform":
- - libraries-tools/gcp-terraform/index.md
- - "Python":
- - libraries-tools/python/index.md
# Links for sufficiently with it people to submit changes.
repo_url: "https://gitlab.developers.cam.ac.uk/uis/devops/docs/guidebook/"
@@ -393,6 +399,7 @@ plugins:
"deployment/permissions-and-roles.md": "reference/cloud-platform/permissions-and-roles.md"
"deployment/backups.md": "reference/cloud-platform/backups.md"
"deployment/dns.md": "reference/cloud-platform/dns.md"
+ "explanations/tech-lead-forum.md": "standards-and-compliance/tech-lead-forum.md"
- build_plantuml:
allow_multiple_roots: false # in case your codebase contains more locations for diagrams (all ending in diagram_root)
diagram_root: "docs/plantuml-diagrams" # should reside under docs_dir