diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md
new file mode 100644
index 00000000..858be5d9
--- /dev/null
+++ b/software-engineering-policies/Lifecycle/DecommissionGuidance.md
@@ -0,0 +1,68 @@
+## Things to consider when decommissioning a service
+
+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
+
+- Green tiles
+
+### Resources
+
+- Entra identities
+- Access packages
+- Elastic
+- Azure subscription & resources
+- DNS entries
+
+### References
+
+Think about references in external systems:
+
+- App Register
+- PMP
+- Tech Radar
+
+Add a decommission report to the Github repository and link to it from the readme.md file.
+Archive Github repository.
+
+## Azure DevOps
+
+Depends on 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:
+
+- Decommission pipelines, environments, variables.
+- Remove team members from the project.
+
+If deleting:
+
+- Ensure all necessary documentation and reports are saved elsewhere before deletion.
+
+## Examples
+
+[Content Delivery Service](https://github.com/UKHO/content-delivery-service?tab=readme-ov-file) - decommission report linked at the top of the README.
diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md
new file mode 100644
index 00000000..d145c37a
--- /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/SourceControl.md) solutions.
+- Code must follow established [coding standards](../CodingStandards/CodingStandards.md).
+- Code must be peer reviewed in line with [code review policy](../CodeReview/CodeReviewPolicy.md).
+- [Secure Development](../SecureDevelopment/SecureDevelopment.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](../QualityAssurance/TestStrategy.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/TechnicalDebt.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/SystemDocumentation.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.