Organisation, Roles and Risk Policy
| Classification | PUBLIC |
|---|---|
| Owner and approver | Paul Gardner |
| Standard | ISO/IEC 27001:2022, Annex A controls 5.2, 5.3, 5.5, 5.6 and 5.8, clauses 5.3, 6.1 to 6.3, 8.2 and 8.3 |
Purpose
This policy sets out how information security is organised at medDigital. It covers who is responsible for what, how the work is checked, who we contact outside the company, how security is built into our work, and how we assess and treat risk.
The directors
medDigital's two directors lead the ISMS together:
- Paul Gardner, responsible for IT
- Felix Jackson-McGill, responsible for Medical
The directors set the information security policy and objectives, provide the resources the ISMS needs and review it every year. They decide together whether to accept a high risk, and whether to notify clients or authorities after an incident.
Day-to-day roles
Day-to-day information security sits with Paul Gardner, who is responsible for IT. He owns the ISMS, writes and approves the policies, manages information security and incidents, carries out the internal audit and owns every risk unless another owner is named.
Every role has a named deputy, recorded in the ISMS, who acts when the holder is unavailable.
Segregation of duties
Several security roles are held by one person, so we rely on controls that check the work independently of any one person's judgement:
- No change reaches production without a pull request that has passed automated tests and security checks.
- Our development branch is protected, so this cannot be bypassed, including by administrators.
- There is one release route, and it refuses any code that has not passed those checks.
- Servers have integrity monitoring. Alerts go in real time to a mailbox that is reviewed every morning.
- The evidence for these controls is produced automatically, not written by hand.
Contact with authorities
The incident manager contacts these authorities when an incident requires it:
| Authority | When | How |
|---|---|---|
| Information Commission (ICO) | A personal data breach that must be reported, within 72 hours | ico.org.uk |
| Report Fraud (City of London Police) | Fraud or cyber crime against medDigital | reportfraud.police.uk |
| National Cyber Security Centre | A significant cyber incident | ncsc.gov.uk |
| US Department of Health and Human Services, Office for Civil Rights | A breach of health information affecting US users of medCrowd | hhs.gov |
Keeping informed
We follow these sources for threats and vulnerabilities that affect what we use:
- National Cyber Security Centre advisories
- Security advisories for the software our applications depend on, checked automatically every day
- Security bulletins from our hosting and productivity suppliers
Security in our work
When we agree a piece of client work, we identify its security and confidentiality needs, including any terms in the client's contract, and record them with the project. Client materials are then handled as set out in the Asset Management and Information Handling Policy.
Software work starts as an issue, and its security needs are considered when the issue is written. It is delivered through a pull request and the same automated security checks as every other change.
Before a significant change to our systems, suppliers or the organisation, we check it against the risk register and decide what needs to change.
How we assess risk
We keep a risk register. Each risk has an owner and is scored by likelihood and impact, each from 1 to 5, with the controls already in place:
| Score | Level | What happens |
|---|---|---|
| 1 to 4 | Low | Accepted and reviewed every year |
| 5 to 9 | Medium | Treated, or accepted with a recorded reason |
| 10 to 15 | High | Treated. Only the directors can accept it, for at most six months at a time |
| 16 to 25 | Critical | Treated at once. Never accepted |
A risk is treated by adding or strengthening controls, by stopping the activity, by sharing it with a supplier or insurer under contract, or by accepting it with a reason and a review date.
The register is reviewed every year at the management review, after any security incident, and before any significant change. It is kept internally, because it describes our weaknesses.
How we check
The yearly internal audit confirms that every role and deputy is named, that the risk register has been reviewed on time, and that every High risk accepted has a current review date.
Exceptions, breaches and review follow the Information Security Policy.
History
| Date | Change |
|---|---|
| 29th October 2026 | Rewritten for ISO/IEC 27001:2022 as Organisation, Roles and Risk, replacing the Internal Organisation Policy, and moved to www.meddigital.com |
| 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 |
| 2nd May 2018 | Periodic review |
| 2nd December 2016 | Initial version |