Secure Development and Change Policy
| Classification | PUBLIC |
|---|---|
| Owner and approver | Paul Gardner |
| Standard | ISO/IEC 27001:2022, Annex A controls 8.4 and 8.25 to 8.33 |
Purpose
This policy sets out how we build, change and release our software so that security is part of every change, from the first idea to production.
Scope
This policy applies to every application medDigital develops and runs, to the configuration of the servers that host them, and to everyone who writes or changes that code. We do not outsource development.
Security from the start
Every piece of work starts as an issue, and its security needs are considered when the issue is written: confidentiality, data protection, availability, logging and legal requirements, alongside what the change must do. A significant change is checked against our risk register before work begins.
We design and write code to current good practice, including the OWASP Top 10, and we use the security features of our frameworks rather than building our own.
How a change reaches production
- The change is made on its own branch, named after its issue.
- It is proposed as a pull request.
- Automated checks run on every pull request:
- The application's test suite
- Code style
- Static analysis
- Security scanning for common vulnerabilities and for passwords or keys left in the code
- An audit of every third-party package for known vulnerabilities
- A person reviews the pull request and merges it only when every check has passed.
- Releases are made by one named person, through a release process that refuses any code whose checks did not pass.
Our development branch is protected, so these steps cannot be skipped, including by administrators. A pull request must also be up to date with the development branch, so the code that was tested is exactly the code that is released.
Third-party packages
Updates to the packages our applications depend on are proposed automatically as pull requests and go through the same checks. The packages in our released and development code are also audited every day, and any known vulnerability is reported to us the same morning.
Security testing
Besides the checks on every change, our public websites are scanned regularly for web vulnerabilities. Every medium or high finding is raised as an issue, then fixed or accepted with a recorded reason.
Server changes
Server configuration is kept under version control and applied by automation. Every change is previewed before it is applied, and nothing is changed on a production server by hand.
Environments
Development and production run on separate systems with separate databases. Automated tests run against a temporary database that is rebuilt for every run.
Test data
The use of production data in a non-production system is prohibited, with one exception. A copy of our internal billing data may be used in development to check the monthly billing run before it runs in production. Only the ISMS owner makes this copy. Each copy is recorded automatically and removed automatically on the 5th of each month.
No other production data is ever copied to a non-production system. This is enforced technically.
Access to source code
Our source code is kept in private repositories. Access is limited to the people who develop our software.
How we check
Every change leaves a record: the issue, the pull request, the results of its checks and the person who merged it. The yearly internal audit samples these records.
Exceptions, breaches and review follow the Information Security Policy.
History
| Date | Change |
|---|---|
| 29th October 2026 | Rewritten for ISO/IEC 27001:2022 as Secure Development and Change, replacing the System Acquisition, Development and Maintenance Policy, and moved to www.meddigital.com. Test data allows one exception for checking the monthly billing run |
| 10th June 2025 | Periodic review |
| 19th June 2023 | Periodic review |
| 6th June 2022 | Periodic review |
| 16th February 2021 | Periodic review |
| 12th February 2020 | Periodic review |
| 15th May 2018 | Periodic review |
| 15th November 2016 | Moved to the web |
| 17th May 2016 | Change of location. Development life cycle added |
| 30th July 2015 | Periodic review |
| 8th September 2014 | Rebranding |
| 2nd July 2014 | Initial version |