ГОСТ IEC 62304—2022
ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения С, если:
- ПРОГРАММНАЯ СИСТЕМА может способствовать возникновению ОПАСНОЙ СИТУАЦИИ, кото
рая приводит к недопустимому РИСКУ, после рассмотрения мер по УПРАВЛЕНИЮ РИСКОМ, внешних по
отношению к ПРОГРАММНОЙ СИСТЕМЕ, и в результате возможным ВРЕДОМ является смерть или
СЕРЬЕЗНАЯ ТРАВМА.
Для ПРОГРАММНОЙ СИСТЕМЫ, первоначально классифицированной как класс безопасности
программного обеспечения В или С, ИЗГОТОВИТЕЛЬ может реализовать дополнительные меры по
УПРАВЛЕНИЮ РИСКОМ, внешние по отношению к ПРОГРАММНОЙ СИСТЕМЕ (включая пересмотр ар
хитектуры системы, содержащей ПРОГРАММНУЮ СИСТЕМУ), и впоследствии присвоить ПРОГРАММ
НОЙ СИСТЕМЕ новую классификацию безопасности программного обеспечения.
Примечание1 — Внешними мерами по УПРАВЛЕНИЮ РИСКОМ могут быть аппаратные средства,
независимая ПРОГРАММНАЯ СИСТЕМА, медицинские процедуры или другие средства, позволяющие свести к
минимуму способность программного обеспечения приводить к возникновению ОПАСНОЙ СИТУАЦИИ.
Примечание 2 — Определение допустимости риска см. в подразделе 3.2 «Ответственность руковод
ства» ISO 14971:2007.
b) Не используется.
c) ИЗГОТОВИТЕЛЬ обязан документировать класс безопасности программного обеспечения,
присвоенный каждой ПРОГРАММНОЙ СИСТЕМЕ, в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
d) Если ПРОГРАММНАЯ СИСТЕМА подразделяется на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и
в дальнейшем ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ в свою очередь подразделяются на ПРОГРАММ
НЫЕ СОСТАВНЫЕ ЧАСТИ, то такие ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ должны наследовать класс
безопасности первоначальной ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ (или ПРОГРАММНОЙ СИСТЕ
МЫ), если только ИЗГОТОВИТЕЛЬ не обосновывает в документации присвоение другого класса без
опасности программного обеспечения (классы безопасности программного обеспечения, присвоенные
в соответствии с подразделом 4.3 а), заменяя «ПРОГРАММНУЮ СИСТЕМУ» на «ПРОГРАММНЫЕ СО
СТАВНЫЕ ЧАСТИ»), Это обоснование должно объяснять, почему ПРОГРАММНЫЕ СОСТАВНЫЕ ЧА
СТИ являются изолированными настолько, что могут классифицироваться отдельно.
e) ИЗГОТОВИТЕЛЬ должен документировать класс безопасности программного обеспечения
каждой ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, если этот класс отличается от класса ПРОГРАММНОЙ
СОСТАВНОЙ ЧАСТИ, из которой он был выделен при декомпозиции.
f) Для соответствия настоящему стандарту там, где настоящий стандарт применяется к группе
ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, ИЗГОТОВИТЕЛЬ должен использовать ПРОЦЕССЫ и ЗАДА
ЧИ, которые требуются для классификации ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ с наивысшей кате
горией из всей группы, если только ИЗГОТОВИТЕЛЬ в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА не приводит
документированные обоснования для использования более низкой классификации.
д) Каждой ПРОГРАММНОЙ СИСТЕМЕ, если ей не присвоен класс безопасности программного
обеспечения, по умолчанию должен присваиваться Класс С.
Примечание — В последующих разделах и подразделах классы безопасности программного обеспе
чения, к которым применяется конкретное требование, определяются в соответствии с требованием в форме
[Класс...].
4.4* УСТАРЕВШЕЕ/НАСЛЕДУЕМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
4.4.1 Общие сведения
В качестве альтернативы применению разделов 5—9 настоящего стандарта соответствие УСТА-
РЕВШЕГО/НАСЛЕДУЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ может быть продемонстрировано, как
указано в 4.4.2—4.4.5.
4.4.2 Деятельность по МЕНЕДЖМЕНТУ РИСКА
В соответствии с 4.2 настоящего стандарта ИЗГОТОВИТЕЛЬ должен:
a) оценить любую обратную связь, включая постпроизводственную информацию, об УСТАРЕВ
ШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ, касающуюся инцидентов и/или близких к ним ситуаций как
внутри своей организации, так и/или от пользователей;
b
) выполнить ДЕЯТЕЛЬНОСТЬ по УПРАВЛЕНИЮ РИСКОМ, связанную с продолжением исполь
зования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, с учетом следующих аспектов:
8