LEAP -- Software Development Lifecycle (SDLC) Policy

Cover page layout

Contents

• 1. Purpose
• 2. Scope
• 3. Definitions
• 4. Roles and Responsibilities
• 5. Policy Principles
• 5.1. Governance Principles
• 5.2. Planning and requirements
• 5.3. Design and architecture
• 5.4. Build and secure development
• 5.5. Testing and Acceptance
• 5.6. Release and Deployment
• 5.7. Maintenance
• 6. Any References
• 7. Related documents (optional)
• 8. Policy Exceptions
• 9. Policy Enforcement
• 10. Policy Monitoring
• 11. Awareness & Communication
• 12. Version History

Purpose

This policy defines LEAP's minimum requirements for managing software and infrastructure changes through a controlled Software Development Life Cycle (SDLC). It establishes consistent practices for planning, design, build, testing, release, and maintenance so changes are secure, traceable, tested, and appropriately approved before production use.

Scope

This policy applies to:

• customer-facing applications and APIs
• internal applications and supporting services
• cloud infrastructure, CI/CD pipelines, scripts, and infrastructure-as-code
• third-party integrations and supplier-developed components where LEAP retains implementation or operational responsibility
• emergency changes, patches, and hotfixes

The SDLC must be applied proportionate to risk, data sensitivity, business impact, and production exposure. Higher-risk changes require greater review, testing, security assurance, and approval.

Definitions

Roles and Responsibilities

Policy Principles

Governance Principles

• All development and system changes must follow a documented and repeatable SDLC.
• Information security must be integrated into planning, design, development, testing, deployment, and maintenance activities.
• All changes must be traceable to an approved business, operational, compliance, defect, or security need.
• Roles and responsibilities across Product, Engineering, QE, DevOps, and Information Security must be defined and understood.
• Production changes must not be made outside approved change and release processes, except under an authorised emergency change process.
• Development, test, and production environments must be segregated and secured.
• Production access, source code access, and deployment rights must be restricted to authorised personnel on a least-privilege basis.

Planning and requirements

• Feature requests and changes must be raised through approved planning and work management processes.
• Requirements must be documented before development begins, including functional, operational, and security requirements where applicable.
• For new systems, major features, material architectural changes, or higher-risk changes, security requirements must be identified and reviewed before build commencement.
• Changes involving confidential data, personal information, authentication, authorisation, encryption, external exposure, or third-party integrations must include explicit security consideration.
• High-risk initiatives may be subject to security review before approval to proceed.

Design and architecture

• Systems must be designed using secure engineering principles including least privilege, defence in depth, secure defaults, segregation of duties, and fail-secure design.
• Designs must consider confidentiality, integrity, availability, logging, monitoring, resilience, privacy, and recovery requirements.
• New applications, major changes, and significant integrations should undergo documented design review. Information Security may require design changes where material security risk is identified.
• Dependencies on third-party services, open-source components, and supplier technologies must be assessed in line with LEAP's security and supplier requirements.

Build and secure development

• Direct commits to protected production branches must be prohibited unless explicitly controlled and approved.
• Changes must be made through branches and reviewed through pull requests or equivalent peer review controls.
• Peer review is required for code, scripts, and infrastructure-as-code before merge to protected branches.
• Code reviews must consider security impact, not only functionality.
• Static analysis, dependency analysis, and other relevant automated checks should be integrated into CI/CD pipelines where supported.
• Build and deployment pipelines must include appropriate security gates for the risk of the system or change.
• Secrets, keys, and credentials must not be hard-coded into source code, scripts, or repository history.

Testing and Acceptance

• All changes must be tested before production deployment.
• Testing must be proportionate to the nature of the change and may include unit, integration, regression, functional, user acceptance, performance, and security testing.
• QE must be engaged for changes requiring independent validation under team or release processes.
• Security testing processes must be defined and implemented in the development lifecycle for applicable systems.
• Test evidence must be retained in the approved systems of record.
• Where testing identifies defects or security issues, deployment may be blocked until issues are remediated, accepted through formal risk treatment, or otherwise approved by the appropriate authority.
• Production data must not be used in development or test environments unless explicitly authorised and protected through masking, anonymisation, or equivalent controls.

Release and Deployment

• Changes must be documented sufficiently to support implementation, support, auditability, and rollback.
• Release documentation should include scope, impacted services, dependencies, risks, approvals, test status, rollback considerations, and implementation instructions where appropriate.
• Deployments to production must occur through approved release or change processes.
• Access to deploy to production must be restricted to authorised personnel and controlled tooling.
• Bigger releases, regional deployments, and service-affecting changes must include planned deployment windows, validation steps, and communication as required.
• Emergency changes must be documented, tested to the extent practicable, approved through the emergency path, and reviewed after implementation.

Maintenance

• Post-release issues, bugs, incidents, and vulnerabilities must be logged, tracked, and remediated through approved processes.
• Security-impacting defects and vulnerabilities must be prioritised according to risk and remediated within defined service levels.
• Hotfixes must follow an expedited but controlled process, including traceability, review, testing, and post-deployment validation.
• Monitoring, logging, and incident feedback must be used to improve development and release practices.
• Lessons learned from defects, incidents, penetration tests, audits, and retrospectives must be used to strengthen the SDLC.

Training and Awareness

• Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.

Any References

NIST SP 800-218 (Secure Software Development Framework)

Related documents (optional)

• LEAP Information Security Policy
• LEAP Change Management Policy
• LEAP Access Control Policy
• LEAP Incident Response Plan.

Policy Exceptions

Exceptions in this policy will be risk-assessed CISO with valid business justification and Policy Owner's approval. Exceptions will be time bound

Policy Enforcement

Any LEAP employee, contractor, third-party found to have violated any part of this policy may be subject to HR disciplinary action, up to and including termination of employment

Policy Monitoring

Compliance with this policy will be monitored through periodic reviews, audits, and management oversight.

Awareness & Communication

This policy is an organisational record. A copy of LEAP security policies is made available to all staff/business units currently employed, or when they join LEAP. Employees requiring further information on any aspects of this Policy should discuss their needs with Trust at LEAP Legal Software trust@leaplegalsoftware.com. Any changes or updates to the policy are immediately communicated to Team Governance, Risk and Compliance (GRC).

Version History