compliance/tech-file
4
0
Fork 0
Code Pull Requests Packages Projects Releases Wiki Activity

Compare commits

merge into: compliance:main
Branches Tags
compliance:main
compliance:draft
compliance:pre-move
...
pull from: compliance:draft
Branches Tags
compliance:main
compliance:draft
compliance:pre-move

9 Commits
main ... draft

Author SHA1 Message Date
René Herzer
a860d7c972 changed directory structure 2023-02-27 11:31:21 +01:00
René Herzer
4c84e719c1 moved/renamed some docs 2023-02-17 17:56:29 +01:00
René Herzer
134a0ac15f merge 2023-02-17 17:51:15 +01:00
René Herzer
385f6ff946 added 81001 table 2023-02-17 16:09:24 +01:00
René Herzer
c194b45ad4 „IEC 81001“ hinzufügen 2023-02-17 15:06:35 +00:00
René Herzer
3138ea821c „General documents/intended-use.md“ ändern 2023-02-17 09:25:34 +00:00
Markus Thielen
8f1f1d29d8 drafts started 2023-01-31 22:57:05 +01:00
René Herzer
3bd08fcdf0 added MDS2 form for 81001 2023-01-30 13:44:28 +01:00
Markus Thielen
1357c110d0 README formatting 2023-01-26 09:08:05 +01:00
19 changed files with 472 additions and 134 deletions
Show Stats Expand all files Collapse all files

123
DIN EN 62304/instructions-for-use.md
View File

@ -1,123 +0,0 @@
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 4.2.3 | (All) |
# User Manual [enter Product Name]
Version: [enter content]
Date: [enter content]
[Placeholder Company Address]
Email: [enter content]
Website: [enter content]
[Placeholder CE Sign]
[Placeholder UDI]
[enter Product Name] is a class [enter content] medical device in accordance with 93/42/EEC (for MDD) // Regulation (EU) 2017/745 (for MDR).
UMDNS Code: [enter content]
Symbols:
Safety Information:
[Placeholder Symbol]
This symbol indicates important safety-related information.
Additional Information:
[Placeholder Symbol]
This symbol indicates supplementary information.
> On your introductory pages, explain the symbols that you use in the following sections. Take into account standards like ISO 15223.
> **General Provisions:** Instructions for use are regulated in Section 13 of the Essential Requirements (MDD) and Chapter 3, Section 23 of the General Safety and Performance Requirements (MDR). You may be able to make a case for why your users must not be provided with instructions for use, based on the exception stated in Section 13.1 (MDD) or Section 23.1.d (MDR):
>
> "By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions."
>
> **Language Requirements:** Language requirements are regulated on the national level. German Medical Device Law (Medizinprodukte-Durchführungsgesetz (MPDG), Art. 8) typically requires German, but also gives leeway to argue that English may be a language that is easily understood by your users if those are trained professionals. If you follow this route, as a minimum requirement, all safety-related information has to be provided in German nevertheless:
>
> "In begründeten Fällen dürfen die Informationen auch in englischer Sprache oder einer anderen für den Anwender des Medizinproduktes leicht verständlichen Sprache zur Verfügung gestellt werden, wenn diese Informationen ausschließlich für professionelle Anwender bestimmt sind und die sicherheitsbezogenen Informationen auch in deutscher Sprache oder in der Sprache des Anwenders zur Verfügung gestellt werden."
>
> https://www.gesetze-im-internet.de/mpdg/MPDG.pdf
## Product Description
### Intended Medical Indication
> You can basically copy/paste your intended use document here and in the sections below. This paragraph should include high-level information required to get an idea of how your product works.
> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software.
> Take into account: clinical benefits to be expected, types of processed data, types of data processing (or machine learning based devices: information about algorithm accuracy).
### Characterization of User Profile
> Describe your users: what level of education can be assumed for your users group? Any pre-existing knowledge of the field that your device is used in?
> What technical proficiency can be assumed, how much time is typically spent using the software?
> If you plan on providing user training prior to product use, make sure to also add a description of that here.
### Characterization of Patient Population
> Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile above, but not necessarily.
> Your software could be used by physicians to diagnose diseases in patients, so in that case, they don’t overlap. Some ideas for characteristics to describe: Age group, weight range, health, condition(s).
### Characterization of Use Environment Including Software / Hardware
> Describe the typical use environment. What sort of devices is this running on? Does the software only run on one device or on multiple devices? Is it loud and chaotic like in an emergency ward? How’s the lighting?
> Also, add other software or hardware which is required by your device. Most commonly, apps require users to have a smartphone with a compatible operating system (iOS / Android).
### Exclusions
> This is an important section for your company liability: make clear the environment your device should NOT be used in, by whom should your device NOT be used?
## Safety Information
### Contraindications
> More exclusions, more specific to safety risks and clinical implications. For example, does your device automate medical diagnoses? If not, you may want to point out that all results must be checked thoroughly by a qualified physician.
### Warning and Remaining Risks
> You can use this section to point out user information as required for risk mitigation measures. For example, specific information that must be checked for accuracy or completeness to operate the device.
## Language
> Self-explanatory: what languages, what language settings are offered for your product?
## System Requirements
### Hardware
> What hardware configuration is required to run your device (e.g. minimum requirements for processor, display, network bandwidth)?
### Software
> What software configuration is required (e.g. latest browser version)?
### IT-security Measures
> What is required to prevent unauthorized access? How do users prevent data loss? Describe for example firewall settings, VPN setup, etc.
## Installation
> Describe: Is any IT integration required prior to use? How is a successful installation verified? How are login credentials dealt with?
## Safety and Maintenance
> Consider multiple sub-sections here: how do you plan to deploy frontend / backend updates? How can users report malfunctions, clinical incidents, lost passwords or a potential security breach?
Other aspects you may want to consider for the section as part of your instructions for use:
* Using the software: walkthrough guide to explain functionalities including screenshots and links to helpful websites
* Description of the algorithm for machine-learning based medical devices
* Description of alternative devices or services
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

2
DIN EN 62304/teschd.md
View File

@ -1,2 +0,0 @@
# Regulation

343
MDS2/mds2.md Normal file
View File

@ -0,0 +1,343 @@
| Manufacturer Disclosure Statement for Medical Device Security -- MDS2 | | | | | | |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------------------------- | -------- | ---------------------- | ---------------------- | ------------------------------------------------------------ |
| ______ | ______ | ______ | ______ | | | |
| | | | | | | |
| Question ID | Question | | See note | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| DOC-1 | Manufacturer Name | ______ | __ | | | |
| DOC-2 | Device Description | ______ | __ | | | |
| DOC-3 | Device Model | ______ | __ | | | |
| DOC-4 | Document ID | ______ | __ | | | |
| DOC-5 | Manufacturer Contact Information | ______ | __ | | | |
| DOC-6 | Intended use of device in network-connected environment: | ______ | __ | | | |
| DOC-7 | Document Release Date | ______ | __ | | | |
| DOC-8 | Coordinated Vulnerability Disclosure: Does the manufacturer have a vulnerability disclosure program for this device? | ______ | __ | | | |
| DOC-9 | ISAO: Is the manufacturer part of an Information Sharing and Analysis Organization? | ______ | __ | | | |
| DOC-10 | Diagram: Is a network or data flow diagram available that indicates connections to other system components or expected external resources? | | __ | | | |
| DOC-11 | SaMD: Is the device Software as a Medical Device (i.e. software-only, no hardware)? | ______ | __ | | | |
| DOC-11.1 | Does the SaMD contain an operating system? | ______ | __ | | | |
| DOC-11.2 | Does the SaMD rely on an owner/operator provided operating system? | ______ | __ | | | |
| DOC-11.3 | Is the SaMD hosted by the manufacturer? | ______ | | | | |
| DOC-11.4 | Is the SaMD hosted by the customer? | ______ | __ | | | |
| | | | | | | |
| | | Yes, No, N/A, or See Note | Note # | | | |
| | MANAGEMENT OF PERSONALLY IDENTIFIABLE INFORMATION | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| MPII-1 | Can this device display, transmit, store, or modify personally identifiable information (e.g. electronic Protected Health Information (ePHI))? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2 | Does the device maintain personally identifiable information? | ______ | | | AR-2 | A.15.1.4 |
| MPII-2.1 | Does the device maintain personally identifiable information temporarily in volatile memory (i.e., until cleared by power-off or reset)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.2 | Does the device store personally identifiable information persistently on internal media? | ______ | __ | | | |
| MPII-2.3 | Is personally identifiable information preserved in the device’s non-volatile memory until explicitly erased? | ______ | __ | | | |
| MPII-2.4 | Does the device store personally identifiable information in a database? | ______ | __ | | | |
| MPII-2.5 | Does the device allow configuration to automatically delete local personally identifiable information after it is stored to a long term solution? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.6 | Does the device import/export personally identifiable information with other systems (e.g., a wearable monitoring device might export personally identifiable information to a server)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.7 | Does the device maintain personally identifiable information when powered off, or during power service interruptions? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.8 | Does the device allow the internal media to be removed by a service technician (e.g., for separate destruction or customer retention)? | ______ | __ | | | |
| MPII-2.9 | Does the device allow personally identifiable information records be stored in a separate location from the device’s operating system (i.e. secondary internal drive, alternate drive partition, or remote storage location)? | ______ | | | AR-2 | A.15.1.4 |
| MPII-3 | Does the device have mechanisms used for the transmitting, importing/exporting of personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.1 | Does the device display personally identifiable information (e.g., video display, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.2 | Does the device generate hardcopy reports or images containing personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.3 | Does the device retrieve personally identifiable information from or record personally identifiable information to removable media (e.g., removable-HDD, USB memory, DVD-R/RW,CD-R/RW, tape, CF/SD card, memory stick, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.4 | Does the device transmit/receive or import/export personally identifiable information via dedicated cable connection (e.g., RS-232, RS-423, USB, FireWire, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.5 | Does the device transmit/receive personally identifiable information via a wired network connection (e.g., RJ45, fiber optic, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.6 | Does the device transmit/receive personally identifiable information via a wireless network connection (e.g., WiFi, Bluetooth, NFC, infrared, cellular, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.7 | Does the device transmit/receive personally identifiable information over an external network (e.g., Internet)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.8 | Does the device import personally identifiable information via scanning a document? | ______ | | | | |
| MPII-3.9 | Does the device transmit/receive personally identifiable information via a proprietary protocol? | ______ | | | | |
| MPII-3.10 | Does the device use any other mechanism to transmit, import or export personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| Management of Private Data notes: | | | | AR-2 | A.15.1.4 | |
| | | | | | | |
| | | | | | | |
| | AUTOMATIC LOGOFF (ALOF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The device's ability to prevent access and misuse by unauthorized users if device is left idle for a period of time. | | | | | |
| ALOF-1 | Can the device be configured to force reauthorization of logged-in user(s) after a predetermined length of inactivity (e.g., auto-logoff, session lock, password protected screen saver)? | ______ | __ | Section 5.1, ALOF | AC-12 | None |
| ALOF-2 | Is the length of inactivity time before auto-logoff/screen lock user or administrator configurable? | ______ | __ | Section 5.1, ALOF | AC-11 | A.11.2.8, A.11.2.9 |
| | | | | | | |
| | | | | | | |
| | AUDIT CONTROLS (AUDT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to reliably audit activity on the device. | | | | | |
| AUDT-1 | Can the medical device create additional audit logs or reports beyond standard operating system logs? | ______ | __ | Section 5.2, AUDT | AU-1 | A.5.1.1, A.5.1.2, A.6.1.1, A.12.1.1, A.18.1.1, A.18.2.2 |
| AUDT-1.1 | Does the audit log record a USER ID? | ______ | __ | | | |
| AUDT-1.2 | Does other personally identifiable information exist in the audit trail? | | | Section 5.2, AUDT | AU-2 | None |
| AUDT-2 | Are events recorded in an audit log? If yes, indicate which of the following events are recorded in the audit log: | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.1 | Successful login/logout attempts? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.2 | Unsuccessful login/logout attempts? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.3 | Modification of user privileges? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.4 | Creation/modification/deletion of users? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.5 | Presentation of clinical or PII data (e.g. display, print)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.6 | Creation/modification/deletion of data? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.7 | Import/export of data from removable media (e.g. USB drive, external hard drive, DVD)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8 | Receipt/transmission of data or commands over a network or point-to-point connection? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8.1 | Remote or on-site support? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8.2 | Application Programming Interface (API) and similar activity? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.9 | Emergency access? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.10 | Other events (e.g., software updates)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.11 | Is the audit capability documented in more detail? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-3 | Can the owner/operator define or select which events are recorded in the audit log? | | | Section 5.2, AUDT | AU-2 | None |
| AUDT-4 | Is a list of data attributes that are captured in the audit log for an event available? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-4.1 | Does the audit log record date/time? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-4.1.1 | Can date and time be synchronized by Network Time Protocol (NTP) or equivalent time source? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-5 | Can audit log content be exported? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-5.1 | Via physical media? | ______ | __ | | | |
| AUDT-5.2 | Via IHE Audit Trail and Node Authentication (ATNA) profile to SIEM? | ______ | __ | | | |
| AUDT-5.3 | Via Other communications (e.g., external service device, mobile applications)? | ______ | __ | | | |
| AUDT-5.4 | Are audit logs encrypted in transit or on storage media? | ______ | __ | | | |
| AUDT-6 | Can audit logs be monitored/reviewed by owner/operator? | ______ | __ | | | |
| AUDT-7 | Are audit logs protected from modification? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-7.1 | Are audit logs protected from access? | | | | | |
| AUDT-8 | Can audit logs be analyzed by the device? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| | | | | | | |
| | | | | | | |
| | AUTHORIZATION (AUTH) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to determine the authorization of users. | | | | | |
| AUTH-1 | Does the device prevent access to unauthorized users through user login requirements or other mechanism? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.1 | Can the device be configured to use federated credentials management of users for authorization (e.g., LDAP, OAuth)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.2 | Can the customer push group policies to the device (e.g., Active Directory)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.3 | Are any special groups, organizational units, or group policies required? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-2 | Can users be assigned different privilege levels based on 'role' (e.g., user, administrator, and/or service, etc.)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-3 | Can the device owner/operator grant themselves unrestricted administrative privileges (e.g., access operating system or application via local root or administrator account)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-4 | Does the device authorize or control all API access requests? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-5 | Does the device run in a restricted access mode, or ‘kiosk mode’, by default? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | CYBER SECURITY PRODUCT UPGRADES (CSUP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of on-site service staff, remote service staff, or authorized customer staff to install/upgrade device's security patches. | | | | | |
| CSUP-1 | Does the device contain any software or firmware which may require security updates during its operational life, either from the device manufacturer or from a third-party manufacturer of the software/firmware? If no, answer “N/A” to questions in this section. | ______ | __ | | | |
| CSUP-2 | Does the device contain an Operating System? If yes, complete 2.1-2.4. | ______ | __ | | | |
| CSUP-2.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-2.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-2.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-2.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-3 | Does the device contain Drivers and Firmware? If yes, complete 3.1-3.4. | ______ | __ | | | |
| CSUP-3.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-3.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-3.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-3.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-4 | Does the device contain Anti-Malware Software? If yes, complete 4.1-4.4. | ______ | __ | | | |
| CSUP-4.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-4.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-4.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-4.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-5 | Does the device contain Non-Operating System commercial off-the-shelf components? If yes, complete 5.1-5.4. | ______ | __ | | | |
| CSUP-5.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-5.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-5.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-5.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-6 | Does the device contain other software components (e.g., asset management software, license management)? If yes, please provide details or refernce in notes and complete 6.1-6.4. | ______ | __ | | | |
| CSUP-6.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-6.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-6.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-6.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-7 | Does the manufacturer notify the customer when updates are approved for installation? | ______ | __ | | | |
| CSUP-8 | Does the device perform automatic installation of software updates? | ______ | __ | | | |
| CSUP-9 | Does the manufacturer have an approved list of third-party software that can be installed on the device? | ______ | __ | | | |
| CSUP-10 | Can the owner/operator install manufacturer-approved third-party software on the device themselves? | ______ | __ | | | |
| CSUP-10.1 | Does the system have mechanism in place to prevent installation of unapproved software? | ______ | __ | | | |
| CSUP-11 | Does the manufacturer have a process in place to assess device vulnerabilities and updates? | ______ | __ | | | |
| CSUP-11.1 | Does the manufacturer provide customers with review and approval status of updates? | ______ | __ | | | |
| CSUP-11.2 | Is there an update review cycle for the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA DE-IDENTIFICATION (DIDT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to directly remove information that allows identification of a person. | | | | | |
| DIDT-1 | Does the device provide an integral capability to de-identify personally identifiable information? | ______ | __ | Section 5.6, DIDT | None | ISO 27038 |
| DIDT-1.1 | Does the device support de-identification profiles that comply with the DICOM standard for de-identification? | ______ | __ | Section 5.6, DIDT | None | ISO 27038 |
| | | | | | | |
| | | | | | | |
| | DATA BACKUP AND DISASTER RECOVERY (DTBK) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to recover after damage or destruction of device data, hardware, software, or site configuration information. | | | | | |
| DTBK-1 | Does the device maintain long term primary storage of personally identifiable information / patient information (e.g. PACS)? | ______ | __ | | | |
| DTBK-2 | Does the device have a “factory reset” function to restore the original device settings as provided by the manufacturer? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| DTBK-3 | Does the device have an integral data backup capability to removable media? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| DTBK-4 | Does the device have an integral data backup capability to remote storage? | | | | | |
| DTBK-5 | Does the device have a backup capability for system configuration information, patch restoration, and software restoration? | | | | | |
| DTBK-6 | Does the device provide the capability to check the integrity and authenticity of a backup? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| | | | | | | |
| | | | | | | |
| | EMERGENCY ACCESS (EMRG) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device user to access personally identifiable information in case of a medical emergency situation that requires immediate access to stored personally identifiable information. | | | | | |
| EMRG-1 | Does the device incorporate an emergency access (i.e. “break-glass”) feature? | ______ | __ | Section 5.8, EMRG | SI-17 | None |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA INTEGRITY AND AUTHENTICITY (IGAU) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | How the device ensures that the stored data on the device has not been altered or destroyed in a non-authorized manner and is from the originator. | | | | | |
| IGAU-1 | Does the device provide data integrity checking mechanisms of stored health data (e.g., hash or digital signature)? | ______ | __ | Section 5.9, IGAU | SC-28 | A.18.1.3 |
| IGAU-2 | Does the device provide error/failure protection and recovery mechanisms for stored health data (e.g., RAID-5)? | ______ | __ | Section 5.9, IGAU | SC-28 | A.18.1.3 |
| | | | | | | |
| | | | | | | |
| | MALWARE DETECTION/PROTECTION (MLDP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to effectively prevent, detect and remove malicious software (malware). | | | | | |
| MLDP-1 | Is the device capable of hosting executable software? | ______ | __ | Section 5.10, MLDP | | |
| MLDP-2 | Does the device support the use of anti-malware software (or other anti-malware mechanism)? Provide details or reference in notes. | ______ | __ | Section 5.10, MLDP | SI-3 | A.12.2.1 |
| MLDP-2.1 | Does the device include anti-malware software by default? | ______ | __ | Section 5.10, MLDP | CM-5 | A.9.2.3, A.9.4.5, A.12.1.2, A.12.1.4, A.12.5.1 |
| MLDP-2.2 | Does the device have anti-malware software available as an option? | ______ | __ | Section 5.10, MLDP | AU-6 | A.12.4.1, A.16.1.2, A.16.1.4 |
| MLDP-2.3 | Does the device documentation allow the owner/operator to install or update anti-malware software? | ______ | __ | Section 5.10, MLDP | CP-10 | A.17.1.2 |
| MLDP-2.4 | Can the device owner/operator independently (re-)configure anti-malware settings? | ______ | __ | Section 5.10, MLDP | AU-2 | None |
| MLDP-2.5 | Does notification of malware detection occur in the device user interface? | ______ | | | | |
| MLDP-2.6 | Can only manufacturer-authorized persons repair systems when malware has been detected? | ______ | | | | |
| MLDP-2.7 | Are malware notifications written to a log? | ______ | | | | |
| MLDP-2.8 | Are there any restrictions on anti-malware (e.g., purchase, installation, configuration, scheduling)? | ______ | | | | |
| MLDP-3 | If the answer to MLDP-2 is NO, and anti-malware cannot be installed on the device, are other compensating controls in place or available? | ______ | __ | Section 5.10, MLDP | SI-2 | A.12.6.1, A.14.2.2, A.14.2.3, A.16.1.3 |
| MLDP-4 | Does the device employ application whitelisting that restricts the software and services that are permitted to be run on the device? | ______ | __ | Section 5.10, MLDP | SI-3 | A.12.2.1 |
| MLDP-5 | Does the device employ a host-based intrusion detection/prevention system? | ______ | __ | Section 5.10, MLDP | SI-4 | None |
| MLDP-5.1 | Can the host-based intrusion detection/prevention system be configured by the customer? | ______ | __ | Section 5.10, MLDP | CM-7 | A.12.5.1 |
| MLDP-5.2 | Can a host-based intrusion detection/prevention system be installed by the customer? | ______ | __ | Section 5.10, MLDP | | |
| | | | | | | |
| | | | | | | |
| | NODE AUTHENTICATION (NAUT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to authenticate communication partners/nodes. | | | | | |
| NAUT-1 | Does the device provide/support any means of node authentication that assures both the sender and the recipient of data are known to each other and are authorized to receive transferred information (e.g. Web APIs, SMTP, SNMP)? | ______ | __ | Section 5.11, NAUT | SC-23 | None |
| NAUT-2 | Are network access control mechanisms supported (E.g., does the device have an internal firewall, or use a network connection white list)? | ______ | __ | Section 5.11, NAUT | SC-7 | A.13.1.1, A.13.1.3, A.13.2.1,A.14.1.3 |
| NAUT-2.1 | Is the firewall ruleset documented and available for review? | ______ | __ | | | |
| NAUT-3 | Does the device use certificate-based network connection authentication? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | CONNECTIVITY CAPABILITIES (CONN) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | All network and removable media connections must be considered in determining appropriate security controls. This section lists connectivity capabilities that may be present on the device. | | | | | |
| CONN-1 | Does the device have hardware connectivity capabilities? | ______ | __ | | | |
| CONN-1.1 | Does the device support wireless connections? | ______ | __ | | | |
| CONN-1.1.1 | Does the device support Wi-Fi? | ______ | __ | | | |
| CONN-1.1.2 | Does the device support Bluetooth? | ______ | __ | | | |
| CONN-1.1.3 | Does the device support other wireless network connectivity (e.g. LTE, Zigbee, proprietary)? | ______ | __ | | | |
| CONN-1.1.4 | Does the device support other wireless connections (e.g., custom RF controls, wireless detectors)? | ______ | __ | | | |
| CONN-1.2 | Does the device support physical connections? | ______ | __ | | | |
| CONN-1.2.1 | Does the device have available RJ45 Ethernet ports? | ______ | __ | | | |
| CONN-1.2.2 | Does the device have available USB ports? | ______ | __ | | | |
| CONN-1.2.3 | Does the device require, use, or support removable memory devices? | ______ | __ | | | |
| CONN-1.2.4 | Does the device support other physical connectivity? | ______ | __ | | | |
| CONN-2 | Does the manufacturer provide a list of network ports and protocols that are used or may be used on the device? | ______ | __ | | | |
| CONN-3 | Can the device communicate with other systems within the customer environment? | ______ | __ | | | |
| CONN-4 | Can the device communicate with other systems external to the customer environment (e.g., a service host)? | ______ | __ | | | |
| CONN-5 | Does the device make or receive API calls? | ______ | __ | | | |
| CONN-6 | Does the device require an internet connection for its intended use? | ______ | __ | | | |
| CONN-7 | Does the device support Transport Layer Security (TLS)? | ______ | __ | | | |
| CONN-7.1 | Is TLS configurable? | | | | | |
| CONN-8 | Does the device provide operator control functionality from a separate device (e.g., telemedicine)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | PERSON AUTHENTICATION (PAUT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to configure the device to authenticate users. | | | | | |
| PAUT-1 | Does the device support and enforce unique IDs and passwords for all users and roles (including service accounts)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-1.1 | Does the device enforce authentication of unique IDs and passwords for all users and roles (including service accounts)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-2 | Is the device configurable to authenticate users through an external authentication service (e.g., MS Active Directory, NDS, LDAP, OAuth, etc.)? | ______ | __ | Section 5.12, PAUT | IA-5 | A.9.2.1 |
| PAUT-3 | Is the device configurable to lock out a user after a certain number of unsuccessful logon attempts? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-4 | Are all default accounts (e.g., technician service accounts, administrator accounts) listed in the documentation? | ______ | __ | Section 5.12, PAUT | SA-4(5) | A.14.1.1, A.14.2.7, A.14.2.9, A.15.1.2 |
| PAUT-5 | Can all passwords be changed? | ______ | __ | Section 5.12, PAUT | | |
| PAUT-6 | Is the device configurable to enforce creation of user account passwords that meet established (organization specific) complexity rules? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-7 | Does the device support account passwords that expire periodically? | ______ | __ | | | |
| PAUT-8 | Does the device support multi-factor authentication? | ______ | __ | | | |
| PAUT-9 | Does the device support single sign-on (SSO)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-10 | Can user accounts be disabled/locked on the device? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-11 | Does the device support biometric controls? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-12 | Does the device support physical tokens (e.g. badge access)? | ______ | __ | | | |
| PAUT-13 | Does the device support group authentication (e.g. hospital teams)? | ______ | __ | | | |
| PAUT-14 | Does the application or device store or manage authentication credentials? | ______ | __ | | | |
| PAUT-14.1 | Are credentials stored using a secure method? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | PHYSICAL LOCKS (PLOK) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Physical locks can prevent unauthorized users with physical access to the device from compromising the integrity and confidentiality of personally identifiable information stored on the device or on removable media | | | | | |
| PLOK-1 | Is the device software only? If yes, answer “N/A” to remaining questions in this section. | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-2 | Are all device components maintaining personally identifiable information (other than removable media) physically secure (i.e., cannot remove without tools)? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-3 | Are all device components maintaining personally identifiable information (other than removable media) physically secured behind an individually keyed locking device? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-4 | Does the device have an option for the customer to attach a physical lock to restrict access to removable media? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| | | | | | | |
| | | | | | | |
| | ROADMAP FOR THIRD PARTY COMPONENTS IN DEVICE LIFE CYCLE (RDMP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Manufacturer’s plans for security support of third-party components within the device’s life cycle. | | | | | |
| RDMP-1 | Was a secure software development process, such as ISO/IEC 27034 or IEC 62304, followed during product development? | ______ | __ | Section 5.14, RDMP | CM-2 | None |
| RDMP-2 | Does the manufacturer evaluate third-party applications and software components included in the device for secure development practices? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| RDMP-3 | Does the manufacturer maintain a web page or other source of information on software support dates and updates? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| RDMP-4 | Does the manufacturer have a plan for managing third-party component end-of-life? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| | | | | | | |
| | | | | | | |
| | SOFTWARE BILL OF MATERIALS (SBoM) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | A Software Bill of Material (SBoM) lists all the software components that are incorporated into the device being described for the purpose of operational security planning by the healthcare delivery organization. This section supports controls in the RDMP section. | | | | | |
| SBOM-1 | Is the SBoM for this product available? | ______ | __ | | | |
| SBOM-2 | Does the SBoM follow a standard or common method in describing software components? | ______ | __ | | | |
| SBOM-2.1 | Are the software components identified? | ______ | __ | | | |
| SBOM-2.2 | Are the developers/manufacturers of the software components identified? | ______ | __ | | | |
| SBOM-2.3 | Are the major version numbers of the software components identified? | ______ | __ | | | |
| SBOM-2.4 | Are any additional descriptive elements identified? | ______ | __ | | | |
| SBOM-3 | Does the device include a command or process method available to generate a list of software components installed on the device? | ______ | __ | | | |
| SBOM-4 | Is there an update process for the SBoM? | ______ | __ | | | |
| | | | | | | |
| | SYSTEM AND APPLICATION HARDENING (SAHD) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The device's inherent resistance to cyber attacks and malware. | | | | CM-7 | A.12.5.1* |
| SAHD-1 | Is the device hardened in accordance with any industry standards? | ______ | __ | Section 5.15, SAHD | AC-17(2)/IA-3 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2/None |
| SAHD-2 | Has the device received any cybersecurity certifications? | ______ | __ | Section 5.15, SAHD | SA-12(10) | A.14.2.7, A.15.1.1, A.15.1.2, A.15.1.3 |
| SAHD-3 | Does the device employ any mechanisms for software integrity checking | ______ | __ | | | |
| SAHD-3.1 | Does the device employ any mechanism (e.g., release-specific hash key, checksums, digital signature, etc.) to ensure the installed software is manufacturer-authorized? | ______ | __ | | | |
| SAHD-3.2 | Does the device employ any mechanism (e.g., release-specific hash key, checksums, digital signature, etc.) to ensure the software updates are the manufacturer-authorized updates? | ______ | __ | Section 5.15, SAHD | CM-8 | A.8.1.1, A.8.1.2 |
| SAHD-4 | Can the owner/operator perform software integrity checks (i.e., verify that the system has not been modified or tampered with)? | ______ | __ | Section 5.15, SAHD | AC-3 | A.6.2.2, A.9.1.2, A.9.4.1, A.9.4.4, A.9.4.5, A.13.1.1, A.14.1.2, A.14.1.3, A.18.1.3 |
| SAHD-5 | Is the system configurable to allow the implementation of file-level, patient level, or other types of access controls? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-5.1 | Does the device provide role-based access controls? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-6 | Are any system or user accounts restricted or disabled by the manufacturer at system delivery? | ______ | __ | Section 5.15, SAHD | CM-8 | A.8.1.1, A.8.1.2 |
| SAHD-6.1 | Are any system or user accounts configurable by the end user after initial configuration? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-6.2 | Does this include restricting certain system or user accounts, such as service technicians, to least privileged access? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-7 | Are all shared resources (e.g., file shares) which are not required for the intended use of the device disabled? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-8 | Are all communication ports and protocols that are not required for the intended use of the device disabled? | ______ | __ | Section 5.15, SAHD | SA-18 | None |
| SAHD-9 | Are all services (e.g., telnet, file transfer protocol [FTP], internet information server [IIS], etc.), which are not required for the intended use of the device deleted/disabled? | ______ | __ | Section 5.15, SAHD | CM-6 | None |
| SAHD-10 | Are all applications (COTS applications as well as OS-included applications, e.g., MS Internet Explorer, etc.) which are not required for the intended use of the device deleted/disabled? | ______ | __ | Section 5.15, SAHD | SI-2 | A.12.6.1, A.14.2.2, A.14.2.3, A.16.1.3 |
| SAHD-11 | Can the device prohibit boot from uncontrolled or removable media (i.e., a source other than an internal drive or memory component)? | ______ | __ | | | |
| SAHD-12 | Can unauthorized software or hardware be installed on the device without the use of physical tools? | ______ | __ | | | |
| SAHD-13 | Does the product documentation include information on operational network security scanning by users? | ______ | __ | | | |
| SAHD-14 | Can the device be hardened beyond the default provided state? | ______ | __ | | | |
| SAHD-14.1 | Are instructions available from vendor for increased hardening? | | | | | |
| SHAD-15 | Can the system prevent access to BIOS or other bootloaders during boot? | | | | | |
| SAHD-16 | Have additional hardening methods not included in 2.3.19 been used to harden the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | SECURITY GUIDANCE (SGUD) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Availability of security guidance for operator and administrator of the device and manufacturer sales and service. | | | | | |
| SGUD-1 | Does the device include security documentation for the owner/operator? | ______ | __ | Section 5.16, SGUD | AT-2/PL-2 | A.7.2.2, A.12.2.1/A.14.1.1 |
| SGUD-2 | Does the device have the capability, and provide instructions, for the permanent deletion of data from the device or media? | ______ | __ | Section 5.16, SGUD | MP-6 | A.8.2.3, A.8.3.1, A.8.3.2, A.11.2.7 |
| SGUD-3 | Are all access accounts documented? | ______ | __ | Section 5.16, SGUD | AC-6,IA-2 | A.9.1.2, A.9.2.3, A.9.4.4, A.9.4.5/A.9.2.1 |
| SGUD-3.1 | Can the owner/operator manage password control for all accounts? | ______ | __ | | | |
| SGUD-4 | Does the product include documentation on recommended compensating controls for the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA STORAGE CONFIDENTIALITY (STCF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure unauthorized access does not compromise the integrity and confidentiality of personally identifiable information stored on the device or removable media. | | | | | |
| STCF-1 | Can the device encrypt data at rest? | ______ | __ | Section 5.17, STCF | SC-28 | A.8.2.3 |
| STCF-1.1 | Is all data encrypted or otherwise protected? | | | | | |
| STCF-1.2 | Is the data encryption capability configured by default? | | | | | |
| STCF-1.3 | Are instructions available to the customer to configure encryption? | | | | | |
| STCF-2 | Can the encryption keys be changed or configured? | ______ | __ | Section 5.17, STCF | SC-28 | A.8.2.3 |
| STCF-3 | Is the data stored in a database located on the device? | ______ | __ | | | |
| STCF-4 | Is the data stored in a database external to the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | TRANSMISSION CONFIDENTIALITY (TXCF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure the confidentiality of transmitted personally identifiable information. | | | | | |
| TXCF-1 | Can personally identifiable information be transmitted only via a point-to-point dedicated cable? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-2 | Is personally identifiable information encrypted prior to transmission via a network or removable media? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-2.1 | If data is not encrypted by default, can the customer configure encryption options? | ______ | __ | | | |
| TXCF-3 | Is personally identifiable information transmission restricted to a fixed list of network destinations? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-4 | Are connections limited to authenticated systems? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-5 | Are secure transmission methods supported/implemented (DICOM, HL7, IEEE 11073)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | TRANSMISSION INTEGRITY (TXIG) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure the integrity of transmitted data. | | | | | |
| TXIG-1 | Does the device support any mechanism (e.g., digital signatures) intended to ensure data is not modified during transmission? | ______ | __ | Section 5.19, TXIG | SC-8 | A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 |
| TXIG-2 | Does the device include multiple sub-components connected by external cables? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | REMOTE SERVICE (RMOT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Remote service refers to all kinds of device maintenance activities performed by a service person via network or other remote connection. | | | | | |
| RMOT-1 | Does the device permit remote service connections for device analysis or repair? | ______ | __ | | AC-17 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2 |
| RMOT-1.1 | Does the device allow the owner/operator to initiative remote service sessions for device analysis or repair? | ______ | __ | | | |
| RMOT-1.2 | Is there an indicator for an enabled and active remote session? | ______ | __ | | | |
| RMOT-1.3 | Can patient data be accessed or viewed from the device during the remote session? | ______ | __ | | AC-17 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2 |
| RMOT-2 | Does the device permit or use remote service connections for predictive maintenance data? | ______ | __ | | | |
| RMOT-3 | Does the device have any other remotely accessible functionality (e.g. software updates, remote training)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | OTHER SECURITY CONSIDERATIONS (OTHR) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | NONE | | | | | |
| | | | | | | |
| | Notes: | | | | | |
| | | | | | | |
| Note 1 | Example note. Please keep individual notes to one cell. Please use separate notes for separate information | | | | | Manufacturer Disclosure Statement for Medical Device Security -- MDS2 |

4
README.md
View File

@ -9,10 +9,12 @@ For more information, please visit:
* https://basebox.tech/why-basebox/regulatory-compliant
* https://openregulatory.com/
<p style="text-align: center; margin: 60px auto;" align="center">
<p align="center">
<br><br><br>
<a href="https://basebox.tech">
<img src="img/basebox_logo.svg">
</a>
<br><br><br>
</p>

0
DIN EN 62304/checklist-software-release.md → iec-62304/checklist-software-release.md
View File

0
DIN EN 62304/checklist-software-requirements-review.md → iec-62304/checklist-software-requirements-review.md
View File

0
DIN EN 62304/document-roadmap.md → iec-62304/document-roadmap.md
View File

6
General documents/instructions-for-use.md → iec-62304/instructions-for-use.md
View File

@ -4,9 +4,11 @@
# User Manual [enter Product Name]
Version: [enter content]
Date: [enter content]
**Document Change History**
| Version | Date | Author | Change Comment |
| ------- | ---------- | -------------- | -------------- |
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
[Placeholder Company Address]
Email: [enter content]

18
General documents/intended-use.md → iec-62304/intended-use.md
View File

@ -1,5 +1,12 @@
# Intended Use
**Document Change History**
| Version | Date | Author | Change Comment |
|---------|------------|----------------|----------------|
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
## Mapping of Requirements to Document Sections
> Only relevant if you're aiming for MDD (and not MDR) compliance:
@ -27,20 +34,19 @@
## Product
* Name: *\<product name\>*
* Version: *\<product version\>*
* Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
* Name: basebox
* Version: Applies to all versions
* Basic UDI-DI: Applicable for the medical device which integrates basebox.
## Intended Use
> Describe the core medical functionality of your device and how it treats, diagnoses or alleviates a disease.
> Keep it high-level so that this description is true for as long as possible even when the device is updated.
The following characteristics of an intended use have to be defined by the medical device manufacturer using basebox.
## Intended Medical Indication
> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by
> your software. Importantly, also list exclusion criteria: Maybe patients with a certain diagnosis should not
> be using your device.
N/A. See above.
## Contraindications

0
DIN EN 62304/list-of-known-anomalies.md → iec-62304/list-of-known-anomalies.md
View File

0
DIN EN 62304/post-market-surveillance-plan.md → iec-62304/post-market-surveillance-plan.md
View File

0
DIN EN 62304/software-architecture-checklist.md → iec-62304/software-architecture-checklist.md
View File

0
DIN EN 62304/software-architecture-description.md → iec-62304/software-architecture-description.md
View File

6
DIN EN 62304/software-development-maintenance-plan.md → iec-62304/software-development-maintenance-plan.md
View File

@ -1,5 +1,11 @@
# Software Development and Maintenance Plan
**Document Change History**
| Version | Date | Author | Change Comment |
|---------|------------|----------------|----------------|
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
> This document is related to your product. You somehow need to associate it with it. The easiest way would be
> to just put all product-related documents into a folder in your QMS so that the association is
> clear. Alternatively, you could mention the related product and version here, but then you'd have to update

0
DIN EN 62304/software-requirements-list.md → iec-62304/software-requirements-list.md
View File

0
DIN EN 62304/software-system-test-plan.md → iec-62304/software-system-test-plan.md
View File

0
DIN EN 62304/sop-deployment.md → iec-62304/sop-deployment.md
View File

0
DIN EN 62304/soup-list.md → iec-62304/soup-list.md
View File

104
iec-81001-5-1/iec-81001-5-1.md Normal file
View File

@ -0,0 +1,104 @@
Basebox Compliance Conformity Assessment against: IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle, (2021-12)
**bold** = TBD
| Chapt | Requirements | How basebox Rel 1 development fulfilled the IEC 81001-5-1 requirements | References |
| ------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| | Introduction - The scope of the standard is limited to HEALTH SOFTWARE and its connectivity to its INTENDED ENVIRONMENT OF USE, based on IEC 62304, but with emphasis on CYBERSECURITY. | Introduction - Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device. | |
| 1 | This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1[11] – taking the specific needs for HEALTH SOFTWARE into account | In order to apply best practices for security and privacy engineering for the basebox component the requirements from IEC 81001-5-1 were followed as applicable. | |
| 2 | Normative references | The following sections exlain how the requirements from the standard were applied during the design and devopment of basebox Revision 1. | |
| 3 | Terms and definitions | Any requirements which were not applicable to the basebox development have an according rational. | |
| 4 | General requirements | Many of the design and development documentation contain security and some confidential information. Those documents are not to be published herein. An according note is provided where applicable. | |
| 4.1 | Quality management | But these design and development documents could be reviewed during any on site audit. | |
| 4.1.1 | Quality management system | The establishment of an basebox adequate Quality Management System which comprises the complete life-cycle of basebox and which is based upon ISO 13485 is in preparation | |
| 4.1.2 | Identification of responsibilities | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.3 | Identification of applicability | Performed for basebox. (Note: not to be published) | |
| 4.1.4 | SECURITY expertise | Security expertise was established by hiring experienced SW engineers during the start of the company but also by acquiring independent consultation from specialized external experts like the Johner Institute. | |
| 4.1.5 | SOFTWARE ITEMS from third-party suppliers | These items are covered by basebox in the SBoM (Software Bill of Materials). | |
| 4.1.6 | Continuous improvement | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.7 | Disclosing SECURITY-related issues | Not applicable for basebox (since basebox is not a medical device). Any medical device company which is integrating basebox has to establish this activity. | |
| 4.1.8 | Periodic review of SECURITY defect management | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.9 | ACCOMPANYING DOCUMENTATION review | Peer Reviews were performed to ensure the completeness and correctness of any basebox accompanying documentation | |
| 4.2 | SECURITY RISK MANAGEMENT | Threat modelling was perfomed for basebox. All identified threat mitigation controls were implemented and verified. Testing comprised a penetration test which was executed by an independent test house. (Note: threat model not to be published) | |
| 4.3 | SOFTWARE ITEM classification relating to risk transfer | Shall be documented by any medical device manufacturer which integrates basebox. | |
| 5 | Software development PROCESS | | |
| 5.1 | Software development planning | | |
| 5.1.1 | ACTIVITIES in the LIFE CYCLE PROCESS | **Basebox was developed based upon state-of-the art software engineering methodologies and practices. A formalized software development process which is in compliance with IEC 62304 standard will be part of the upcoming holistic Quality Management system.** | |
| 5.1.2 | Development environment SECURITY | The development environment is secured according to existing security standards. E.e. by 2FA, backups, ssl and other measures. (Note: not to be published) | |
| 5.1.3 | Secure coding standards | basebox was implementd by using the following public coding standard: LIST HERE. In addition, basebox has defined its own coding standards. These are: LIST HERE. | |
| 5.2 | HEALTH SOFTWARE requirements analysis | | |
| 5.2.1 | HEALTH SOFTWARE SECURITY requirements | The Manufacturer Disclosure Statement for Medical Device Security (MDS2) form provides an overview of the standard based security requirements and capabilities which were specified and implemented for basebox. | |
| 5.2.2 | SECURITY requirements review | The security requirements for basebox have been reviewed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published) | |
| 5.2.3 | SECURITY risks for REQUIRED SOFTWARE | **tbd.** | |
| 5.3 | Software architectural design | | |
| 5.3.1 | DEFENSE-IN-DEPTH ARCHITECTURE/design | **The basebox architecture and design was developed by having the defense-in-depth-strategy in mind. Security requirements were identified in lockstep with the development of the componenent and identification of its defense layers. (Note: the review results are not to be published)** | |
| 5.3.2 | Secure design best practices | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to identify, enforce and maintain secure design practices. The MANUFACTURER shall document secure design best practices, which should include but are not limited to: a) documenting all TRUST BOUNDARIES as part of the design; b) least privilege (granting only the privileges to users/software necessary to perform intended operations); c) using proven secure SOFTWARE ITEMS/designs where possible; d) economy of mechanism (striving for simple designs); e) using secure design patterns; f) ATTACK SURFACE reduction; g) removing backdoors, debug access and debug information used during development or documenting their presence and the need to protect them from unauthorized access; and h) protecting any remaining debug information from unauthorized access. The MANUFACTURER shall define a SECURITY ARCHITECTURE as part of DEFENSE-IN-DEPTH, including the practices listed above as appropriate. | The basebox architecture and design does consider secure design best practices like (non-exhaustive list): trust boundaries, economy of mechanism, attack surface reduction, removing backdoors, protecting any remaining debug information from unauthorized access. (Note: secure design best practices are not to be published) | |
| 5.3.3 | SECURITY architectural design review | The architectural design review was performed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published) | |
| 5.4 | Software design | | |
| 5.4.1 | Software design best practices | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to develop and document a secure HEALTH SOFTWARE design and maintain the use of best practices for the secure design, taking into account: <br />a) software technology at application level (for examples algorithms, methods);<br />b) the programming technology used, (for example programming language);<br />c) the secure design best practices in 5.3.2. | **TBD inkl. 5.3.2** | |
| 5.4.2 | Secure design | Threat modelling comprised the identification of threats and efefctive mitigation-measures (also called security controls). These security controls were considered during the basebox design and implementation. (Note: the secure designs are not to be published) | |
| 5.4.3 | Secure HEALTH SOFTWARE interfaces | **Specification of Security settings** | |
| | The HEALTH SOFTWARE design shall identify and characterize each interface of the HEALTH SOFTWARE including physical and logical interfaces. As appropriate, the MANUFACTURER identifies as part of the design: a) whether the interface is externally accessible (by other PRODUCTS) or internally accessible – between SOFTWARE ITEMS of the HEALTH SOFTWARE- or both; b) SECURITY implications of the HEALTH SOFTWARE SECURITY CONTEXT on the external interface; c) potential users of the interface and the ASSETS that can be accessed through the interfaces (directly or indirectly); d) whether the static design includes access to interfaces across TRUST BOUNDARIES; e) SECURITY considerations, assumptions and/or constraints associated with the use of the interface within the HEALTH SOFTWARE SECURITY CONTEXT; including applicable THREATS; f) the SECURITY roles, privileges/rights and access control permissions needed to use the interface and to access the ASSETS defined in c); g) the SECURITY CAPABILITIES and/or compensating mechanisms used to safeguard the interface and the ASSETS identified in c) including run-time VALIDATION of inputs as well as handling outputs and errors; h) the use of third-party SOFTWARE ITEMS to implement the interface and their SECURITY CAPABILITIES; i) documentation that describes how to use the interface if it is externally accessible; and j) description of how the design mitigates the THREATS identified in the THREAT MODEL. | | |
| 5.4.4 | Detailed design VERIFICATION for SECURITY | **Describe Peer reviews . What is documented and what was tested exactly?** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for conducting design reviews to identify, characterize and track to closure WEAKNESSES associated with each significant revision of the secure design including but not limited to: a) SECURITY requirements that were not adequately addressed by the design; b) THREATS and their ability to exploit VULNERABILITIES in PRODUCT interfaces, TRUST BOUNDARIES and ASSETS; c) identification, documentation and characterization of detailed design best-practices that were not followed (5.3.2 and 5.4.1). | | |
| 5.5 | Software unit implementation and VERIFICATION | | |
| 5.5.1 | Secure coding standards | The coding standards from 5.1.3 were applied during the coding activties | |
| 5.5.2 | SECURITY implementation review | Peer review activties ensured:<br />a) the adquate implementation of security requirements and design<br />b) all security requirements and designs were implemented and can be traced down to code<br />c) the coding standards (ref. 5.5.1) were applied Additionally static code analyses (SCA) was performed using **TOOL**<br />D) to determine remaining secure coding errors | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that implementation reviews are performed for identifying, characterizing and feeding into the problem resolution PROCESS all SECURITY-related issues associated with the implementation of the secure design including: a) identification of SECURITY requirements (see 5.2) that were not adequately addressed by the implementation; NOTE Requirements allocation, including SECURITY requirements, is part of typical design PROCESSES. b) identify secure coding standards used and document any parts of the secure coding standards that were not followed (for example, use of banned functions or failure to apply the principle of least privilege); c) Static Code Analysis (SCA) for source code to determine secure coding errors using the secure coding standard for the supported programming language, as established in 5.1.3. SCA is often supported by tools, but it can be done through code inspections and codewalkthroughs. d) review of the implementation and its TRACEABILITY to the SECURITY CAPABILITIES defined to support the SECURITY design (see 5.3 and 5.4); and e) examination of THREATS and their ability to exploit implementation interfaces, TRUST BOUNDARIES and ASSETS (see 5.3 and 5.4). | | |
| 5.6 | Software integration testing | **Integration testing was done in combination with penetration testing since basebox has to be integrated in some applications in order to perfrom those test activties. (Note: the test plan and results are not to be published)** | **correct?** |
| 5.7 | Software system testing | | |
| 5.7.1 | SECURITY requirements testing | **Since basebox is a sw component the comprehensive system testing shall be perfomed by the customer who is integrating basebox. But basebox is providing the list of security requirements (controls) to customers which are relevant for a secure integration of basebox in any system (medical device) and shall be considered therefore during integration and system testing activities perfomed by the customers.** | **correct?** |
| 5.7.2 | THREAT mitigation testing | **Welche verschlüsselungsmaßnahmen und andere spezifische Sicherheitsmassnahmen sind implementiert und wie sind diese getestet** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for testing the effectiveness of the mitigation for the THREATS identified and assessed in the THREAT MODEL. ACTIVITIES shall include: a) creating and executing adequate testing for each mitigation implemented to address a specific THREAT, in order to ensure that the mitigation works as designed; b) creating and executing plans for attempting to thwart each mitigation; and c) ensuring that the mitigation does not introduce other VULNERABILITIES to the design. | | |
| 5.7.3 | VULNERABILITY testing | **Write list of OTS Components used in basebox (= SBoM) and check vulnarabilities of each one in public libraries and set reference link. Define relevance of each vulnarability for basebox.** | [Hier die Freitext Suche der cve / Mitre Web Seite. Geben Sie z.B. Windos 11 ein erhalten Sie eine lange Liste pot. Vulnerabilties, die dann auf ihre Relevenaz hin analysiert werden müssen](https://cve.mitre.org/cve/search_cve_list.html) |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for performing tests that focus on identifying and characterizing potential SECURITY VULNERABILITIES in the HEALTH SOFTWARE. Known VULNERABILITY testing shall be based upon, at a minimum, recent contents of an established, industry-recognized, public source for known VULNERABILITIES. As appropriate testing shall include: a) abuse case for malformed or unexpected input testing focused on uncovering SECURITY issues. This shall include manual or automated abuse case testing and specialized types of abuse case testing on all external interfaces and protocols. Examples include fuzz testing and network traffic load testing and capacity testing; b) ATTACK SURFACE testing to determine all avenues of ingress and egress to and from the system, common VULNERABILITIES including but not limited to weak access-control-lists (ACLs), exposed ports and services running with elevated privileges; c) “closed box” known VULNERABILITY scanning focused on detecting known VULNERABILITIES in (if applicable) hardware, host, interfaces or SOFTWARE ITEMS; NOTE 1 For example, this could be a network based known VULNERABILITY scan. d) SOFTWARE COMPOSITION ANALYSIS on all binary executable files including embedded firmware, to be used with HEALTH SOFTWARE and delivered by a third-party supplier. This analysis can be used to detect: 1) known VULNERABILITIES in the SOFTWARE ITEMS; 2) linking to vulnerable libraries; 3) SECURITY rule violations; 4) compiler settings that can lead to VULNERABILITIES; and 5) comparison of the software encountered to the software bill of materials. NOTE 2 Tools can support SOFTWARE COMPOSITION ANALYSIS by generating a list of software packages included. e) dynamic SECURITY testing – like e.g. fuzz testing, that detects flaws not visible under static code analysis, including but not limited to denial of service conditions due to failing to release runtime handles, memory leaks and accesses made to shared memory without authentication. This testing shall be applied if such tools are available. | | |
| 5.7.4 | Penetration testing | An independent pentest **which did comprise fuzz testing** was executed by the test lab of the Johner Institute. As mentioned above an integration of basebox in sample applications or systems were done in order to be able to perform the pen testing activities. | |
| 5.7.5 | Managing conflicts of interest between testers and developers | In order to avoid the conflicts of interests between developer and tester in a small team the mentioned external and independent expertise from the Johner Institute and other security experts were consulted. | |
| 5.8.2 | Release documentation | **To be checked by GD when published** | |
| 5.8.3 | File INTEGRITY | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to provide an INTEGRITY VERIFICATION mechanism for all scripts, executables and other SECURITY-relevant files used with a HEALTH SOFTWARE. This ACTIVITY (or ACTIVITIES) is required to ensure that PRODUCT users can verify that executables, scripts, and other important files received from the MANUFACTURER have not been altered. Common methods of meeting this requirement include cryptographic hashes and digital signatures (which also provide proof of origin). | **tbd.** | |
| 5.8.4 | Controls for private keys | **tbd.** | |
| | The MANUFACTURER shall have procedural and technical controls in place to protect private keys used for code signing from unauthorized access or modification. | **tbd.** | |
| 5.8.5 | Assessing and addressing SECURITY-related issues | **tbd.** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that a HEALTH SOFTWARE or an update is not released until its SECURITY-related issues have been addressed and tracked to closure (see 9.5). This includes issues associated with: a) requirements (see 5.2); b) SECURITY by design (see 5.3 and 5.4); c) implementation (see 5.5); d) VERIFICATION / VALIDATION (see 5.5, 5.6 and 5.7); and e) SECURITY defect management (see 9.4). | **tbd.** | |
| 5.8.6 | ACTIVITY completion | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 5.8.7 | SECURE decommissioning guidelines for HEALTH SOFTWARE | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to create PRODUCT user documentation that includes guidelines for removing the HEALTH SOFTWARE from use. | **tbd.** | |
| 6 | SOFTWARE MAINTENANCE PROCESS | **A formalized software maintenance process which is in compliance with the IEC 62304 standard will be part of the upcoming basebox adequate Quality Management system. The formalized software maintenance process will consider and establish the security requirements from this standard** | |
| 6.1 | Establish SOFTWARE MAINTENANCE plan | | |
| 6.1.1 | Timely delivery of SECURITY updates | Statement in section 6 applies | |
| 6.2 | Problem and modification analysis | | |
| 6.2.1 | Monitoring public incident reports | Statement in section 6 applies | |
| 6.2.2 | SECURITY update VERIFICATION | Statement in section 6 applies | |
| 6.3 | Modification implementation | | |
| 6.3.1 | SUPPORTED SOFTWARE SECURITY update documentation | Statement in section 6 applies | |
| 6.3.2 | MAINTAINED SOFTWARE SECURITY update delivery | Statement in section 6 applies | |
| 6.3.3 | MAINTAINED SOFTWARE SECURITY update INTEGRITY | Statement in section 6 applies | |
| 7 | SECURITY RISK MANAGEMENT PROCESS | | |
| 7.1 | RISK MANAGEMENT context | | |
| 7.1.1 | General | Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device. | |
| 7.1.2 | PRODUCT SECURITY CONTEXT | For that reoson the ISO 14971 requirements are not applicable for basebox. | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that the intended PRODUCT SECURITY CONTEXT is documented. This ACTIVITY (or ACTIVITIES) is required to ensure that the minimum requirements of the environment and the assumptions about that environment are documented in order to achieve the SECURITY level for which the PRODUCT was designed. The purpose of defining this information is so that both the developers of the HEALTH SOFTWARE and the PRODUCT users have the same understanding about how the PRODUCT is intended to be used. This will help the developers make appropriate design decisions and the users to use the PRODUCT as it was intended. The SECURITY CONTEXT could include: a) location in the network; b) physical SECURITY or CYBERSECURITY provided by the environment where the PRODUCT will be deployed; c) isolation (from a network perspective); d) if known, potential impact to SAFETY caused by degradation of SECURITY; e) SECURITY controls implemented in dedicated hardware with which the HEALTH SOFTWARE is intended to be used. For example, it is important to document whether physical SECURITY is required. If no physical SECURITY is expected to be present, then that can add a number of related requirements such as not allowing push-button configuration on the PRODUCT. Another example is if the PRODUCT cannot feasibly (i.e. without reducing SAFETY or performance) implement a firewall of its own, it can be expected to be protected by a user-supplied firewall that connects it to the health-ITnetwork. Documenting these external SECURITY features for the PRODUCT (its SECURITY CONTEXT) allows developers to design a DEFENSE-IN-DEPTH strategy that complements this SECURITY CONTEXT and testers to validate and verify the SECURITY of a PRODUCT in an environment similar to how it is intended to be deployed. Having this PROCESS means that the deployment environment in which the PRODUCT is intended to be used is correctly represented in all PROCESSES involved in the development and testing of this PRODUCT and are documented. | But as oulined along the requirements in the previous sections of this list basebox was developed by applying state-of-the-art practices for security and privacy by design which comprises the complete life cycle of the component. Applying state-of-the-art practices for security and privacy shall help to reduce any cyber risk which might have an impact on health risk once the component ist integrated in a medical device. The referenced information may serve as input to the risk management process which has to be performed by customers: The referenced < document > describes the security context of basebox and provides security rules and controles which shall be applied by customer before integrating basebox in any customer application. | Risk Management inputs: - List of known bugs - SBoM, including the list of evaluated vulnerabilities (cve's) Security rules |
| 7.2 | Identification of VULNERABILITIES, THREATS and associated adverse impacts | Statements in section 7.1 and 7.2 apply | |
| 7.3 | Estimation and evaluation of SECURITY risk | Statements in section 7.1 and 7.2 apply | |
| 7.4 | Controlling SECURITY risks | Statements in section 7.1 and 7.2 apply | |
| 7.5 | Monitoring the effectiveness of RISK CONTROLS | Statements in section 7.1 and 7.2 apply | |
| 8 | Software CONFIGURATION MANAGEMENT PROCESS | **Generic description of CI process here** | |
| | The MANUFACTURER shall establish a general PRODUCT development/maintenance/support PROCESS that includes CONFIGURATION MANAGEMENT with change controls and change history. For SECURITY obligations with HEALTH SOFTWARE already released or in the market, CONFIGURATION MANAGEMENT shall provide the capability to reproduce a list of included external components that are or could become susceptible to VULNERABILITIES. | | |
| 9 | Software problem resolution PROCESS | | |
| 9.1 | Overview | The establishment of an basebox adequate Quality Management System which comprises the post-market activties for basebox is in preparation | |
| 9.2 | Receiving notifications about VULNERABILITIES | The post-market activties will comprise requirements for the sw problem resolution process which will be aligned with the following processes and activties: - receiving customer complaints - performing root cause analysis, also for potential vulenerabilties and, if required, in cooperation with customers - maintaing the threat model - performing corrective and preventive action - informing customers about known vulnerabilties | |
| 9.3 | Reviewing VULNERABILITIES | Statements in section 9.1 and 9.2 apply | |
| 9.4 | Analysing VULNERABILITIES | Statements in section 9.1 and 9.2 apply | |
| 9.5 | Addressing SECURITY-related issues | Statements in section 9.1 and 9.2 apply | |
| Annex A | Informative: Comprises: Relationship to IEC 62443 and IEC 62304, Risk Transfer, Secure coding best practices | | |
| Annex B | Informative: Guidance on implementation of SECURITY LIFE CYCLE ACTIVITIES | | |
| Annex C | Informative: THREAT MODELLING | | |
| Annex D | Informative: Relation to practices in IEC 62443-4-1:2018, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements | | |
| Annex E | Informative: Documents specified in IEC 62443-4-1 | | |
| Annex F | Normative: TRANSITIONAL HEALTH SOFTWARE | | |