요약
의료기기 소프트웨어를 규율하는 세 표준은 경쟁하지 않는다. 서로 다른 축을 나눠 담당한다. ISO 14971은 위험 관리의 틀을, IEC 62304는 소프트웨어 생명주기의 공정을, IEC 62443은 산업 제어·연결 시스템의 사이버보안을 맡는다. 실무자가 흔히 혼란스러워하는 지점은 이 셋이 겹치는 영역, 특히 "안전(Safety)"과 "보안(Security)"이 만나는 곳이다.
이 글은 세 표준의 관계를 순수 해설 관점에서 정리한다. 특정 제품·회사·실제 평가 결과는 다루지 않으며, 위험 매트릭스 예시는 이해를 돕기 위해 가상의 숫자로 직접 구성했다. 목표는 하나다 — 세 표준이 각자 어떤 질문에 답하고, 어디서 손을 맞잡는지 방어자가 한눈에 파악하는 것이다.
한 문장으로 요약하면 이렇다. ISO 14971이 "위험을 어떻게 다룰 것인가"라는 틀을 세우면, IEC 62304가 "소프트웨어를 그 틀 안에서 어떻게 만들 것인가"를 규정하고, IEC 62443이 "연결된 환경에서 어떻게 지킬 것인가"를 더한다.
1. 세 축 — 무엇이 다른가
먼저 각 표준이 답하는 근본 질문을 구분한다.
| 표준 | 정식 명칭 (개요) | 담당 축 | 핵심 질문 |
|---|---|---|---|
| ISO 14971 | 의료기기에 대한 위험 관리 적용 | 위험 관리 프레임워크 | 위험을 어떻게 식별·평가·제어·모니터링하는가? |
| IEC 62304 | 의료기기 소프트웨어 생명주기 프로세스 | 소프트웨어 개발 공정 | 소프트웨어를 어떤 단계로 안전하게 개발·유지보수하는가? |
| IEC 62443 | 산업 자동화·제어 시스템 사이버보안 | 사이버보안 (시스템/네트워크) | 연결된 환경에서 위협으로부터 어떻게 방어하는가? |
세 표준의 성격 차이를 은유로 표현하면 이렇다.
- ISO 14971은 헌법이다. 위험을 다루는 최상위 원칙과 프로세스를 정한다. 다른 안전 관련 표준들이 이 프레임워크를 참조한다.
- IEC 62304는 건축 공정 규정이다. 소프트웨어라는 구조물을 어떤 순서로 설계·시공·검수·유지보수할지 규정한다.
- IEC 62443은 보안 경비 체계다. 완성된 시스템이 네트워크에 연결되어 운영될 때 외부 위협을 어떻게 막을지 규정한다.
이 은유의 핵심은 셋이 층위가 다르다는 점이다. 하나가 다른 하나를 대체하지 않는다. 실제 의료기기 개발에서는 세 표준이 동시에 적용되며, 서로를 참조하고 보완한다.
2. ISO 14971 — 위험 관리의 틀
프레임워크로서의 위치
ISO 14971은 의료기기 전 생명주기에 걸친 위험 관리의 골격을 제공한다. 다른 안전 표준들은 이 골격 위에 자신의 세부 요건을 얹는다. 소프트웨어 지침(IEC/TR 80002-1), 사이버보안 위험 원칙(AAMI TIR57), 네트워크 위험 관리(IEC 80001-1) 같은 표준들이 모두 ISO 14971의 프로세스를 자기 도메인에 적용하는 형태로 존재한다.
관계를 도식화하면 다음과 같다.
ISO 14971 (위험 관리 프레임워크)
├── IEC 62304 (소프트웨어 개발 공정)
├── IEC/TR 80002-1 (소프트웨어 특화 위험 관리 지침)
├── 사이버보안 위험 원칙 (예: AAMI TIR57)
└── 네트워크 위험 관리 (예: IEC 80001-1)즉 ISO 14971은 모든 위험 관리 활동이 참조하는 공통 언어다. 세 표준의 관계를 이해하려면 여기서 정의된 용어부터 정확히 알아야 한다.
핵심 용어 — 일상어와 다르다
위험 관리 표준의 용어는 일상적 의미와 법적·기술적 의미가 다르다. 방어자가 오해하기 쉬운 핵심 용어를 정리한다.
| 용어 | 표준상 정의 |
|---|---|
| 위해(Harm) | 사람의 건강, 재산, 환경에 대한 부상 또는 손상 |
| 위험원(Hazard) | 위해의 잠재적 원천 |
| 위험 상황(Hazardous Situation) | 사람·재산·환경이 하나 이상의 위험원에 노출된 상황 |
| 위험(Risk) | 위해 발생 확률과 위해 심각도의 조합 |
| 잔여 위험(Residual Risk) | 위험 제어 조치 시행 후 남아 있는 위험 |
가장 자주 오해되는 것이 "위험(Risk)"이다. 표준에서 위험은 단순한 "나쁜 일이 일어날 가능성"이 아니다. 확률과 심각도의 조합이다. 확률이 낮아도 심각도가 극단적이면 위험은 높게 평가되며, 그 반대도 성립한다. 이 정의가 뒤에 나올 위험 매트릭스의 두 축을 결정한다.
또 하나 중요한 구분은 **안전(Safety)과 보안(Security)**이다. 표준상 안전은 "수용 불가능한 위험으로부터의 자유"를 뜻한다. 보안은 별도 표준 계열에서 "정의된 조건 하에서 인명·건강·재산·환경이 위험에 처하지 않는 상태"로 정의된다. 이 둘의 관계가 세 표준이 겹치는 지점의 핵심이며, 4절에서 다룬다.
위험 관리 프로세스 용어
ISO 14971이 정의하는 프로세스 단계도 정확한 명칭이 있다. 실무에서 자주 혼용되지만 표준상으로는 구분된다.
| 용어 | 표준상 의미 |
|---|---|
| 위험 분석(Risk Analysis) | 위험원 식별 및 위험 추정을 위한 정보의 체계적 활용 |
| 위험 추정(Risk Estimation) | 위해 발생 확률과 심각도 값을 할당하는 과정 |
| 위험 평가(Risk Evaluation) | 추정된 위험을 위험 기준과 비교해 수용 여부를 결정 |
| 위험 사정(Risk Assessment) | 위험 분석 + 위험 평가를 포함하는 전체 과정 |
| 위험 제어(Risk Control) | 위험을 지정 수준으로 줄이거나 유지하는 결정과 조치 |
| 위험 관리(Risk Management) | 위 활동 전체에 대한 정책·절차·실행의 체계적 적용 |
이 계층을 그림으로 이해하면 이렇다. 위험 사정 = 위험 분석(위험원 식별 + 위험 추정) + 위험 평가이고, 위험 관리 = 위험 사정 + 위험 제어 + 모니터링이다. 표준을 읽을 때 이 포함 관계를 놓치면 요건의 범위를 오해하게 된다.
가상 위험 매트릭스 예시
ISO 14971은 위험 = 확률 × 심각도라는 원칙을 제시하지만, 구체적 등급 정의는 조직이 정하도록 한다. 아래는 이해를 돕기 위해 임의로 구성한 가상 예시다. 실제 조직은 자신의 임상적 맥락에 맞게 이 등급을 정의해야 한다.
심각도 등급 (가상)
| 등급 | 명칭 | 가상의 의미 |
|---|---|---|
| S1 | 무시 가능 | 불편함, 임상 개입 불필요 |
| S2 | 경미 | 일시적 손상, 경미한 개입 |
| S3 | 중대 | 회복 가능한 손상, 의료 개입 필요 |
| S4 | 치명적 | 영구 손상 또는 생명 위협 |
발생 확률 등급 (가상)
| 등급 | 명칭 | 가상의 빈도 표현 |
|---|---|---|
| P1 | 희박 | 거의 발생하지 않음 |
| P2 | 드묾 | 드물게 발생 |
| P3 | 가끔 | 때때로 발생 |
| P4 | 빈번 | 자주 발생 |
위험 수용 매트릭스 (가상)
| P1 (희박) | P2 (드묾) | P3 (가끔) | P4 (빈번) | |
|---|---|---|---|---|
| S4 (치명적) | 중 | 높음 | 높음 | 높음 |
| S3 (중대) | 낮음 | 중 | 높음 | 높음 |
| S2 (경미) | 낮음 | 낮음 | 중 | 중 |
| S1 (무시) | 낮음 | 낮음 | 낮음 | 중 |
이 가상 매트릭스에서 "높음"으로 판정된 조합은 추가 위험 제어 조치를 거쳐 수용 가능한 수준으로 낮춰야 한다. 조치 후에도 남는 것이 잔여 위험이며, 조직이 정한 기준에 따라 최종 수용 여부를 판정한다. 다시 강조하지만 위 숫자와 등급은 설명용 가상값이다. 실제 매트릭스는 기기의 의도된 용도와 임상 맥락에 따라 조직이 직접 정의한다.
3. IEC 62304 — 소프트웨어 생명주기 공정
ISO 14971과의 관계
IEC 62304는 의료기기 소프트웨어의 개발·유지보수 생명주기를 규정한다. 그런데 이 표준은 독립적으로 서 있지 않는다. 거의 모든 단계에서 ISO 14971의 위험 관리를 참조한다. 두 표준은 나란히 이행되며, 실제로 규제 심사에서는 IEC 62304의 각 공정 단계가 ISO 14971의 어느 위험 관리 단계와 연결되는지를 매핑한 문서를 요구한다.
소프트웨어 안전 등급 A/B/C
IEC 62304의 중심 개념 중 하나는 소프트웨어 안전 등급이다. 소프트웨어(또는 그 항목)가 실패했을 때 초래할 수 있는 위해의 심각도에 따라 세 등급으로 나눈다. 아래 등급 구분은 표준의 개념을 요약한 것이다.
| 등급 | 개념 | 요구 엄격도 |
|---|---|---|
| Class A | 실패해도 위해로 이어지지 않거나 위험이 수용 가능 | 기본 |
| Class B | 실패가 위해로 이어질 수 있으나 중대하지 않음 | 중간 |
| Class C | 실패가 사망 또는 중대한 손상으로 이어질 수 있음 | 최고 |
등급이 높을수록 요구되는 공정이 늘어난다. 예를 들어 Class C에서만 요구되는 추가 활동으로는 개발 표준·방법·도구의 명시(5.1.4), 안전 통제를 위한 소프트웨어 항목의 분리 식별(5.3.5), 상세 설계 및 단위 인터페이스 검증(5.4.2~3), 추가 단위 허용 기준(5.5.4) 등이 있다. Class B까지는 전체 생명주기 관리·요구사항·아키텍처·단위/통합/시스템 테스트·회귀 테스트를 이행하되, 위 Class C 전용 항목은 제외된다.
방어자 관점에서 이 등급 체계의 의미는 명확하다. 위해 심각도가 곧 공정 엄격도를 결정한다. 안전 등급 배정은 자의적이지 않고, ISO 14971의 위험 분석 결과에서 도출된다. 즉 3절의 IEC 62304 등급은 2절의 ISO 14971 심각도 평가에 뿌리를 둔다 — 여기서 두 표준이 맞물린다.
생명주기 단계별 위험 활동 매핑
IEC 62304의 소프트웨어 생명주기 전 단계에 ISO 14971 위험 관리가 교차 적용된다. 아래는 그 매핑을 요약한 것이다(✓ = 해당 단계에서 위험 활동 정의됨).
| IEC 62304 프로세스 | 위험분석 | 위험평가 | 위험통제 | 잔여위험 | 검토 | 생산후 |
|---|---|---|---|---|---|---|
| 5.1 계획 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 5.2 요구사항 분석 | ✓ | ✓ | ✓ | – | – | – |
| 5.3 아키텍처 설계 | ✓ | ✓ | ✓ | – | – | – |
| 5.4 상세 설계 | ✓ | ✓ | ✓ | – | – | – |
| 5.5 단위 구현·검증 | ✓ | ✓ | ✓ | – | – | – |
| 5.6 통합 테스트 | – | – | ✓ | – | – | – |
| 5.7 시스템 테스트 | – | – | ✓ | – | – | – |
| 5.8 출시 | ✓ | – | ✓ | ✓ | – | – |
| 6.3 변경 구현(유지보수) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
이 표에서 눈여겨볼 두 지점이 있다.
첫째, 계획 단계(5.1)와 유지보수 변경 단계(6.3)는 모든 위험 관리 열에 걸쳐 있다. 특히 유지보수가 개발 못지않게 넓게 표시된 이유가 중요하다 — 변경은 기존 위험 통제를 훼손할 수 있기 때문이다. 이미 검증된 안전 통제가 코드 변경 한 줄로 무력화될 수 있으므로, 유지보수 변경은 개발과 동등한 수준의 위험 관리를 요구한다. 방어자 관점에서 이것은 "패치가 새 취약점을 만들 수 있다"는 원칙의 규제적 표현이다.
둘째, 아키텍처 설계(5.3) 단계에 위험 활동이 몰려 있다. 이 단계에서 위험 유발 가능성이 있는 중요 데이터·컴포넌트를 식별하고, 중요 컴포넌트를 격리하는 아키텍처 수준 통제를 설계하며, 이중화 필요성을 판단한다. 즉 위험 통제는 코드를 짜기 전 설계에서 이미 시작된다. 나중에 보안을 덧붙이는 것이 아니라 아키텍처에 내장하는 접근이다.
추적성 — 두 표준을 잇는 실
IEC 62304와 ISO 14971을 실제로 묶는 것은 추적성(Traceability) 문서다. 위험 통제 검증 단계에서 요구되는 추적 사슬은 다음 네 단계다.
- 위험 상황 → 관련 소프트웨어 항목
- 소프트웨어 항목 → 특정 소프트웨어 원인
- 소프트웨어 원인 → 위험 통제 조치
- 위험 통제 조치 → 검증 결과
이 사슬이 완성되어야 "우리가 식별한 위험이 실제로 코드에서 통제되었고 그 통제가 검증되었다"는 것을 증명할 수 있다. 방어자 언어로 옮기면 위협 → 자산 → 완화 → 검증의 추적 사슬과 정확히 대응된다. 위협 모델링에서 익숙한 그 구조가, 의료기기 표준에서는 위험 관리 추적성이라는 이름으로 규제화되어 있는 셈이다.
추적성이 중요한 실무적 이유는 감사 가능성에 있다. 보안이나 안전 주장은 그 자체로는 검증할 수 없다. "우리 시스템은 안전하다"는 문장은 근거 없이는 무의미하다. 추적성 문서는 그 주장을 검증 가능한 형태로 바꾼다 — 각 위험이 어떤 통제로 이어지고, 그 통제가 어떤 시험으로 검증되었는지 사슬을 따라가면 확인할 수 있기 때문이다. 위협 모델링을 실무에서 운영해 본 사람이라면, 위협 목록만 만들고 완화·검증까지 사슬을 잇지 못한 채 방치되는 흔한 실패를 알 것이다. 의료기기 표준은 바로 그 사슬의 완성을 규제 요건으로 못 박아, "만들다 만 위협 모델"이 남지 않도록 강제한다.
SOUP — 알 수 없는 출처의 소프트웨어
IEC 62304의 또 다른 핵심 개념은 **SOUP(Software of Unknown Provenance)**다. 이미 개발되어 일반적으로 사용 가능하지만 적절한 개발 프로세스 기록이 없는 소프트웨어 항목을 뜻한다. 상용·오픈소스 라이브러리 대부분이 여기에 해당한다.
SOUP는 특별 관리 대상이다. 개발 조직이 그 내부 개발 과정을 통제하지 못했으므로, 대신 형상 관리에 포함시키고, 알려진 이상·취약점을 추적하고, 위험 평가에 반영해야 한다. 방어자 관점에서 SOUP 관리는 곧 **소프트웨어 공급망 보안(SBOM, 알려진 취약점 모니터링)**과 같은 문제를 다룬다. 남이 만든 코드를 내 제품에 넣을 때의 위험을 어떻게 통제하는가 — 표준은 이 질문에 오래전부터 답을 요구해 왔다.
4. IEC 62443 — 사이버보안 축이 합류하는 곳
안전과 보안이 만나는 지점
지금까지 다룬 ISO 14971과 IEC 62304는 본래 안전(Safety) 중심이다. 기기가 오작동해 환자에게 위해를 끼치지 않도록 하는 데 초점이 있다. 그러나 의료기기가 네트워크에 연결되면서 새로운 축이 필요해졌다 — 보안(Security), 즉 악의적 위협으로부터의 방어다.
여기서 중요한 통찰이 있다. 연결된 의료기기에서 보안 침해는 곧 안전 위험이 될 수 있다. 공격자가 기기의 동작을 변조하면 그것은 사이버 사건인 동시에 환자 안전 사건이다. 그래서 안전 프레임워크와 보안 프레임워크가 만나야 한다.
IEC 62443의 위치
IEC 62443은 본래 산업 자동화·제어 시스템(IACS)을 위한 사이버보안 표준 계열이다. 발전소·공장·인프라 제어 시스템을 위협으로부터 지키기 위해 만들어졌다. 의료기기 도메인에서 IEC 62443이 중요해진 이유는, 연결된 의료 시스템이 산업 제어 시스템과 구조적으로 유사한 보안 문제를 안기 때문이다 — 오래 운영되고, 패치가 어렵고, 실패가 물리 세계에 직접 영향을 주는 시스템이라는 점에서.
IEC 62443이 도입하는 핵심 개념 몇 가지를 방어자 관점에서 정리하면 다음과 같다.
| 개념 | 방어자 관점 의미 |
|---|---|
| Zones & Conduits | 시스템을 신뢰 구역으로 나누고 구역 간 통신 경로(conduit)를 통제 — 네트워크 분할 원칙 |
| Security Levels (SL 1~4) | 방어 목표를 위협 역량 수준에 따라 등급화 — 우발적 오용부터 고도 자원 공격자까지 |
| Foundational Requirements | 접근 통제·사용 통제·데이터 무결성·기밀성·데이터 흐름 제한 등 7대 기초 요건 |
| 역할 분담 | 제품 개발자·시스템 통합자·자산 운영자 각각의 책임을 구분 |
특히 보안 등급(SL) 개념은 ISO 14971의 위험 등급, IEC 62304의 안전 등급과 나란히 놓고 볼 때 흥미롭다. 세 표준이 모두 "위협/위해의 심각도에 비례해 통제 강도를 높인다"는 동일한 철학을 공유한다. 다만 등급을 정하는 축이 다르다 — ISO 14971은 위해 심각도, IEC 62304는 소프트웨어 실패의 안전 영향, IEC 62443은 공격자의 역량 수준이다.
세 표준의 등급 체계 비교
세 표준이 각자 어떤 축으로 엄격도를 나누는지 비교하면 관계가 선명해진다.
| 표준 | 등급 축 | 무엇을 측정하나 |
|---|---|---|
| ISO 14971 | 위험 = 확률 × 심각도 | 위해가 얼마나 나쁘고 얼마나 자주 일어나는가 |
| IEC 62304 | 안전 등급 A/B/C | 소프트웨어 실패가 얼마나 심각한 위해를 낳는가 |
| IEC 62443 | 보안 등급 SL 1~4 | 어느 수준의 공격자를 막아야 하는가 |
세 축은 독립적이면서도 연결된다. 예를 들어 IEC 62443의 보안 통제가 실패했을 때(공격 성공) 초래되는 결과는 ISO 14971의 위험 평가로 다시 흘러들어간다. 보안 사건은 위험 관리 프레임워크 안에서 하나의 위험원(Hazard)으로 취급된다. 이것이 세 표준이 겹치는 핵심 접합면이다.
한 가지 주의할 점은, 안전 등급과 보안 등급이 항상 같은 방향으로 움직이지는 않는다는 것이다. 소프트웨어 실패의 안전 영향이 낮은(Class A) 컴포넌트라도, 그것이 네트워크 경계에 위치해 공격의 진입점이 된다면 높은 보안 등급을 요구할 수 있다. 반대로 안전상 치명적인(Class C) 컴포넌트가 물리적으로 격리되어 외부 위협에 노출되지 않는다면 보안 등급 요구는 상대적으로 낮을 수 있다. 방어자는 두 등급을 별개로 평가하되, 최종적으로는 ISO 14971의 통합 위험 관리 안에서 함께 저울질해야 한다. 안전 등급이 높다고 보안 등급이 자동으로 높은 것도, 그 역도 아니다 — 두 축은 서로 다른 질문에 답하기 때문이다.
위협 모델링의 통합 그림
세 표준을 위협 모델링 흐름으로 통합하면 다음과 같은 그림이 나온다.
[ISO 14971 프레임워크] ← 최상위: 모든 위험을 관리하는 틀
│
├── 안전 위험 ──→ [IEC 62304]
│ 소프트웨어를 안전 등급에 맞춰 개발·검증
│
└── 보안 위험 ──→ [IEC 62443]
연결 환경을 보안 등급에 맞춰 방어
│
└── 보안 침해가 안전 위험으로 환류
→ 다시 ISO 14971 위험 평가로이 그림의 핵심은 순환이다. IEC 62443이 다루는 보안 위험은 최종적으로 ISO 14971의 위험 관리로 되먹임된다. 사이버보안은 별개의 프로세스가 아니라, 위험 관리 프레임워크가 다루는 위험의 한 유형으로 통합된다. 실제로 이 통합을 매개하는 보조 표준들(사이버보안 위험 원칙을 ISO 14971에 접목하는 AAMI TIR57, 의료기기 포함 IT 네트워크의 위험 관리를 다루는 IEC 80001-1 등)이 존재한다.
5. 세 표준을 함께 읽는 법 — 실무 정리
겹치는 지점 요약
세 표준이 겹치는 세 접합면을 정리하면 다음과 같다.
- ISO 14971 ↔ IEC 62304 접합면: 소프트웨어 안전 등급이 위험 심각도에서 도출되고, 생명주기 전 단계에 위험 관리가 교차 적용된다. 추적성 문서가 둘을 잇는 실이다.
- ISO 14971 ↔ IEC 62443 접합면: 보안 침해가 하나의 위험원으로 위험 관리 프레임워크에 편입된다. 보안 등급 결정이 위험 평가와 연결된다.
- IEC 62304 ↔ IEC 62443 접합면: 보안 요구사항이 소프트웨어 요구사항의 일부로 편입되고, 아키텍처 설계 단계에서 보안 통제(구역 분할, 접근 통제)가 안전 통제와 함께 설계된다.
각자 담당하는 축 요약
혼동을 막기 위해 마지막으로 각 표준의 고유 담당 영역을 못 박아 둔다.
- ISO 14971만 담당: 위험 관리의 최상위 프레임워크와 공통 용어. 위험 수용 기준의 정의. 다른 모든 표준이 참조하는 틀.
- IEC 62304만 담당: 소프트웨어 개발·유지보수의 구체적 공정 단계. 안전 등급 A/B/C. SOUP 관리. 생명주기 추적성.
- IEC 62443만 담당: 연결 환경의 사이버보안 아키텍처. 구역·통로 설계. 보안 등급 SL. 접근/사용 통제 등 기초 보안 요건.
방어자를 위한 실천 원칙
이 표준들을 처음 접하는 보안 실무자를 위한 다섯 가지 원칙으로 마무리한다.
- 틀부터 잡는다. ISO 14971의 용어와 프로세스를 먼저 익혀라. 나머지 두 표준의 요건이 이 틀 위에서 이해된다.
- 안전과 보안을 분리하지 마라. 연결된 기기에서 보안 침해는 안전 위험이다. 두 축을 하나의 위험 관리로 통합하라.
- 등급은 위해에서 나온다. 세 표준의 모든 등급 체계는 "얼마나 나쁜 결과인가"에서 도출된다. 자의적 등급 배정은 표준 위반이다.
- 변경을 개발만큼 엄격히 다뤄라. 유지보수·패치가 기존 통제를 훼손할 수 있다. 변경 관리는 위험 관리의 일급 시민이다.
- 추적성을 증거로 남겨라. 위협 → 자산 → 완화 → 검증의 사슬을 문서로 완성하라. 통제했다는 주장은 추적성으로만 증명된다.
맺음말
ISO 14971, IEC 62304, IEC 62443은 경쟁 관계가 아니라 역할 분담 관계다. 하나가 위험 관리의 틀을 세우고, 하나가 소프트웨어 공정을 규정하고, 하나가 연결 환경의 보안을 더한다. 세 표준이 만나는 지점은 명확하다 — 위해의 심각도가 통제의 엄격도를 결정하며, 보안 침해는 결국 안전 위험으로 환류된다.
이 글의 모든 내용은 공개된 국제표준의 구조와 개념에 대한 해설이다. 위험 매트릭스의 숫자와 등급은 이해를 돕기 위한 가상값이며, 실제 위험 평가는 각 조직이 자신의 임상적·운영적 맥락에서 직접 수행해야 한다. 표준은 답을 주지 않는다 — 답을 도출하는 규율 있는 방법을 줄 뿐이다.
참고할 국제표준 (공개)
- ISO 14971 — Medical devices — Application of risk management to medical devices
- IEC 62304 — Medical device software — Software life cycle processes
- IEC 62443 (계열) — Security for industrial automation and control systems
- IEC/TR 80002-1 — Guidance on the application of ISO 14971 to medical device software
- IEC 80001-1 — Application of risk management for IT-networks incorporating medical devices
- AAMI TIR57 — Principles for medical device security — Risk management
- ISO/IEC Guide 63 / Guide 51 — 위험 관련 용어의 정의 출처
