diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md
new file mode 100644
index 00000000..6e5072f6
--- /dev/null
+++ b/software-engineering-policies/Lifecycle/DecommissionGuidance.md
@@ -0,0 +1,79 @@
+When decommissioning a service, consider the following aspects as part of your impact assessment.
+
+## Communication
+
+- Service owners and product owners are the key decision makers on when a service should be decommissioned.
+- Stakeholders should be informed of decommissioning activities well in advance.
+
+## Service
+
+### Data
+
+Consider any data that the service holds and whether this needs to be migrated to another system or archived before decommissioning.
+
+### Upstream/downstream
+
+Consider impacts to upstream and downstream systems and services. Notify relevant teams of decommissioning plans.
+Assess tests (functional, E2E, performance etc) that may be impacted by the decommissioning.
+
+### Monitoring
+
+SolarWinds alerts and dashboards should be removed once the service is decommissioned.
+
+- API pollers
+- Nodes
+- Credentials (and supporting Entra identities if applicable)
+- Panels in dashboards
+
+### Documentation
+
+Documentation should be archived or updated to reflect the decommissioning of the service. Consider that documentation in dependent services may also need to be updated.
+
+- Documentation in Github repositories
+- Documentation in Azure DevOps wiki
+- 'Green tiles'
+
+### Resources
+
+Resources that are no longer needed should be removed to avoid unnecessary costs. Consider the following which may need removing or updating.
+
+- Azure service subscriptions & resources
+- Resources outside of service subscription e.g. shared service key vaults.
+- Azure spoke configuration
+- Entra identities
+- Access packages
+- Elastic
+- DNS entries
+- Firewall rules
+- SSL certificates
+- Grafana dashboards and alerts
+
+### References
+
+We have a number of tools which will need to be updated. Consider the following.
+
+- App Register
+- PMP
+- Tech Radar
+
+## Azure DevOps
+
+What needs to be done in Azure DevOps will depend on the project. Some service owners might want to keep their Azure DevOps project for historical reference, while others might want to delete it entirely.
+
+If keeping the project:
+
+- Decommission pipelines, environments, variables, service connections.
+- Remove team members from the project.
+
+If deleting the project:
+
+- Ensure all necessary documentation and reports are saved elsewhere before deletion.
+
+## Final updates to Github repository
+
+- Add a decommission report to the Github repository and link to it from `readme.md`.
+- Archive the Github repository.
+
+## Examples
+
+[Content Delivery Service](https://github.com/UKHO/content-delivery-service?tab=readme-ov-file).
diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md
new file mode 100644
index 00000000..6e8425d4
--- /dev/null
+++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md
@@ -0,0 +1,56 @@
+# Software Lifecycle Management Policy
+
+## Purpose
+
+This policy ensures that all software systems are designed, developed, deployed, maintained, and retired in a consistent, secure, and efficient manner aligned with organizational standards.
+
+## Scope
+
+This policy applies to all software engineers, contractors, and teams involved in developing or maintaining internal or customer-facing software.
+
+## Policy Requirements
+
+### Planning & Design
+
+- All new software must include documented requirements, architecture diagrams, threat models and risk assessments.
+- Designs must consider security (ref. [POL201 - Secure by Design](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7BD068DDEC-D0A6-49A6-AA88-B16D4A3B6A30%7D&file=POL201.docx&action=default&mobileredirect=true&DefaultItemOpen=1)), scalability, observability, and maintainability.
+- Designs should be peer reviewed to identify any sharable components.
+- [Naming conventions](../NamingConventions/NamingConventions.md) must be defined and followed consistently.
+
+### Development
+
+- Code must be version-controlled using approved [source control](../SourceControl/SourceControlPolicy.md) solutions.
+- Code must follow established [coding standards](../CodingStandards/README.md).
+- Code must be peer reviewed in line with [code review policy](../CodeReview/CodeReviewPolicy.md).
+- [Secure Development](../SecureDevelopment/SecureDevelopmentPolicy.md) practices must be followed to mitigate vulnerabilities.
+- Automated testing (unit, integration, and security checks) must be implemented before merge.
+
+### Testing & Quality Assurance
+
+- Testing must include unit, integration, system, and security tests.
+- Testing should be automated where possible, following the [test strategy](../../quality-assurance/test-strategy.md).
+- Test coverage and results should be documented and reviewed.
+- Performance and load testing should be conducted for critical systems.
+
+### Deployment & Release Management
+
+- Deployment pipelines must comply with the [pipeline policy](../Pipelines/Baseline_Policy.md).
+- Rollback procedures must be defined and tested.
+- [IaC (Infrastructure as Code) practices](../InfrastructureAsCode/terraform.md) should be used for environment provisioning.
+
+### Operational Maintenance
+
+- Teams must monitor system performance, security alerts, and error logs as per the [observability policy](../Observability/observability_policy.md).
+- Critical vulnerabilities must be remediated within defined SLAs (ref. [POL218 - Patch Management Policy](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7B82EA818D-00AA-44EE-B9A1-E901879DE72E%7D&file=POL218.docx&action=default&mobileredirect=true&DefaultItemOpen=1)).
+- [Technical debt](../TechnicalDebt/TechnicalDebtPolicy.md) should be periodically reviewed and addressed.
+- Disaster recovery procedures must be defined and tested.
+
+### Documentation
+
+- Architecture, APIs, deployment steps, and dependencies must be kept up-to-date.
+- [System documentation](../SystemDocumentation/SystemDocumentationPolicy.md) must be comprehensive and accessible.
+
+### Decommissioning
+
+- Software approaching End-of-Life (EOL) must have a documented migration or decommission plan. For more information, refer to the [decommission guidance](../Lifecycle/DecommissionGuidance.md).
+- Data retention and disposal must comply with organizational and regulatory requirements.