"Risk가 Acceptable인지 Not Acceptable인지 어떻게 판단해요?"
Risk Management를 처음 작성하는 분들이 가장 많이 막히는 지점이에요.
ISO 14971을 읽으면 이런 말이 나와요.
"The manufacturer shall define criteria for risk acceptability"
"제조사가 기준을 정해라."
근데 여기서 멈추는 분들이 많아요.
"기준을 정하라는 건 알겠는데, 어떻게 정해야 NB가 인정해주는 거죠?"
그게 바로 이 글에서 다룰 내용이에요.
Risk Acceptability Matrix 자체는 이미 많이 알려져 있어요.
근데 실무에서 지적받는 이유는 Matrix가 없어서가 아니에요.
"판단 기준이 어디서 왔는지, 왜 이 기준인지"를 설명 못 해서예요.
왜 NB는 Risk Acceptability 기준을 집중적으로 보는가
ISO 14971:2019에서 Risk Acceptability는 제조사가 직접 정의하게 되어 있어요.
정해진 정답이 없다는 뜻이기도 하고, 동시에 "제조사가 근거 없이 편의대로 기준을 잡을 수 있다"는 위험이 있다는 뜻이기도 해요.
NB 입장에서 가장 경계하는 게 바로 이거예요.
"이 제조사가 Risk를 낮게 보이려고 Acceptable 기준을 느슨하게 잡은 건 아닌가?"
그래서 NB는 두 가지를 확인해요.
① 기준이 존재하는가
② 그 기준이 어디서 왔는가
기준이 있어도 근거가 없으면 "자의적 판단"으로 봐요.
이게 Major 지적으로 이어지는 가장 흔한 패턴이에요.
Risk Acceptability 기준, 실제로 어디서 가져와야 하는가
"기준을 제조사가 정한다"는 게 "마음대로 정한다"는 뜻은 아니에요.
ISO 14971:2019 Annex D에서 기준 설정의 근거로 인정받는 소스를 정리하면 이렇게 돼요.
| 근거 유형 | 예시 | 비고 |
| 국제 표준 / 가이드라인 | WHO, Clinical Practice Guidelines | 가장 강력한 근거 |
| 유사 제품 시판 데이터 | 동일 분석물 기존 제품의 사고율, 문헌 데이터 | SoA(State of the Art) 근거 |
| 규제 기관 요구사항 | IVDR Annex I GSPR, 국가별 규정 | 최소 기준으로 사용 |
| 내부 임상 데이터 | 사내 시험 데이터, 기존 제품 클레임 데이터 | 가장 약한 근거, 단독 사용 피해야 |
NB가 가장 좋아하는 구조는 이거예요.
"[국제 임상 가이드라인] 기준에서 이 분석물에 대한 허용 오차 범위를 XX%로 정의하고 있으며,
이를 근거로 본 제품의 Risk Acceptability 기준을 설정함.
추가로 **[유사 제품 시판 데이터]**에서 동일 Hazard의 발생률이 XX%로 확인되어 Probability 기준 설정에 참조함."
두 가지 이상의 근거를 조합하면 훨씬 탄탄해져요.
Risk Acceptability Policy — 이게 있어야 기준이 생긴다
많은 분들이 Risk Acceptability Matrix는 만들어요.
근데 그 Matrix가 어떤 원칙으로 만들어졌는지를 설명하는 Risk Acceptability Policy가 없는 경우가 많아요.
NB는 Matrix 앞에 반드시 이 Policy가 있어야 한다고 봐요.
Policy에 들어가야 하는 내용은 이렇게 구성해요.
① Acceptable risk의 정의
"본 제품에서 Acceptable Risk란, 임상적으로 유의미한 영향 없이 정상 사용 조건에서 발생 가능한 수준의 잔류 위험을 의미함."
② Severity 기준 정의
"Severity는 잘못된 진단 결과가 환자의 임상 결정에 미치는 영향을 기준으로 S1(Negligible)~S5(Catastrophic) 5단계로 정의함."
③ Probability 기준 정의
"Probability는 제품 수명 기간 내 해당 Hazard가 발생할 추정 빈도를 기준으로 P1(Remote)~P5(Frequent) 5단계로 정의함.
추정 근거: CLSI EP05 Precision 데이터 / 유사 제품 Field complaint 데이터."
④ ALARP 영역 정의
"Matrix에서 ALARP 영역에 해당하는 Risk는 추가 Risk Control 조치 후에도 잔류하는 경우, Benefit-Risk Analysis를 통해 최종 판단함."
⑤ Not Acceptable 판단 시 처리 방법
"Not Acceptable로 판단된 Risk는 Risk Control 조치 완료 전까지 제품 출시 불가로 처리함."
이 Policy가 Risk Management Plan 안에 명시적으로 있어야 해요.
없으면 NB가 바로 물어봐요.
"Risk Acceptability 판단의 원칙이 어디에 정의되어 있는가?"
잘못된 작성 vs 심사 통과 수준 — 실제 비교
❌ 이렇게 쓰면 NB가 질문해요
| Risk | Severity | Probability | Level | Acceptability |
| Incorrect result | High | Low | Medium | Acceptable |
문제점이 보이나요?
- Severity "High"의 정의가 없음
- Probability "Low"의 근거가 없음
- "Medium → Acceptable" 판단 기준이 없음
- 이 기준이 어디서 왔는지 없음
결과가 있어도 과정이 없으면 NB는 인정 안 해요.
✅ 이 수준이면 통과돼요
Risk Acceptability Policy (발췌)
Severity 정의
S3 (Serious): 잘못된 진단 결과로 부적절한 치료가 개시되거나, 필요한 치료가 지연될 가능성이 있는 수준.
근거: CLSI EP12 User Protocol for Evaluation of Qualitative Tests 기준 적용.
Probability 정의
P2 (Remote): 제품 수명 내 100,000회 사용 중 1회 미만 발생 예상.
근거: CLSI EP05 Precision 연구에서 CV 3.2% 확인, 유사 제품 FDA MAUDE 데이터 참조.
Risk Severity Probability Risk Level Acceptability 근거
| Risk | Severity | Probability | Risk level | Acceptability | 근거 |
| Incorrect result due to interference | S3 | P2 | Medium | ALARP | EP07 Interference study, CLSI EP07 기준 |
차이가 보이시죠?
- 각 Level의 정의가 명확함
- Probability에 실제 데이터 근거가 있음
- ALARP 판단의 근거가 연결됨
NB 지적이 가장 많이 나오는 5가지 패턴
1. Severity 정의가 임상적 영향이 아닌 경우
IVD에서 Severity는 반드시 **"잘못된 결과가 환자에게 미치는 임상적 영향"**으로 정의해야 해요.
"기기 오작동 빈도"나 "측정 오차 수준" 자체를 Severity로 쓰면 안 돼요.
→ "False Positive → 불필요한 치료 개시 → 약물 부작용 위험" 이런 chain으로 연결해서 정의해야 해요.
2. Probability 추정에 근거가 없는 경우
"경험적 판단으로 Low", "전문가 의견으로 Rare" 같은 표현은 NB에서 바로 지적받아요.
→ CLSI EP05 Precision 데이터, Interference 연구 결과, Field complaint 이력, 문헌 발생률 중 최소 하나 이상으로 근거를 제시해야 해요.
3. ALARP 판단 후 처리가 끊기는 경우
ALARP 영역에 Risk가 있을 때, 추가 조치 없이 "ALARP이므로 수용" 처리하면 지적이에요.
ALARP은 "현실적으로 가능한 최저 수준까지 낮춘 후 수용"이에요.
그 과정이 Risk Control 조치로 문서화되어 있어야 해요.
→ ALARP 영역 Risk 항목마다 "어떤 Control 조치를 적용했고, 그 후에도 잔류하는 이유"가 명시되어 있어야 해요.
4. Risk Acceptability Policy가 RMP 안에 없는 경우
Policy를 별도 문서로 만들거나, 심지어 RMF 어디에도 없는 경우예요.
→ Risk Acceptability 기준은 Risk Management Plan 내에 명시적인 섹션으로 포함되어야 해요.
5. 기준이 제품 특성과 무관하게 Generic한 경우
의료기기 전반에 쓰이는 Generic Matrix를 그대로 복사해서 쓰는 경우예요.
NB가 이렇게 물어봐요.
"이 기준이 귀사 제품의 Intended Use와 대상 환자군 특성을 반영해서 만들어진 것인가?"
→ Intended Use와 대상 population의 위험 민감도를 반영한 기준임을 명시해야 해요.
예: "본 제품은 패혈증 의심 환자를 대상으로 하므로, 진단 지연의 임상 영향이 크다. 이를 반영하여 Severity 기준을 일반적 IVD 대비 보수적으로 설정함."
실제 심사에서 나온 지적 사례
| 케이스 | 상황 | 결과 |
| 사례 1 | Severity를 "측정 오차 수준(CV)"으로 정의 — 임상 영향 기술 없음 | Major 지적 |
| 사례 2 | Probability "Low" 판단 근거 없음 — "전문가 의견" 한 줄 | 보완 요청 → 전체 재작성 |
| 사례 3 | ALARP 항목 12개, 추가 Control 조치 없이 전부 "수용" 처리 | "ALARP justification 부족" Major 지적 |
| 사례 4 | Risk Acceptability Policy가 RMF 어디에도 없음 | "기준 정의 문서 제출 요청" → 심사 보류 |
| 사례 5 | Generic Matrix 복사 사용, IVD 특성 미반영 | "Product-specific justification 없음" 지적 |
사례 3이 가장 치명적이에요.
ALARP을 남발하면 "Risk를 제대로 평가하지 않았다"는 신호로 읽혀요.
ALARP은 반드시 Control 조치 후 남은 잔류위험에만 써야 해요.
Risk Acceptability 기준 설정 순서 — 이 흐름으로 시작하세요
Step 1. Intended Use + 대상 환자군의 임상적 위험 수준 파악
(응급 진단인지, 스크리닝인지, 만성질환 모니터링인지에 따라 기준 엄격도가 달라요)
Step 2. Severity 정의 작성
(임상 영향 chain 기반, S1~S5 각 Level의 정의를 IVD 맥락에 맞게 작성)
Step 3. Probability 정의 + 근거 확보
(사내 Precision 데이터, 문헌, 유사 제품 데이터 중 활용 가능한 것 정리)
Step 4. Risk Acceptability Matrix 작성
(Severity × Probability 조합별 판단 기준 — Acceptable / ALARP / Not Acceptable)
Step 5. ALARP 처리 원칙 명시
(추가 Control 적용 후 잔류하는 경우의 Benefit-Risk 판단 절차 포함)
Step 6. Risk Acceptability Policy로 문서화 → RMP 내 포함
ALARP 영역, 실무에서 어떻게 다뤄야 하는가
ALARP은 "As Low As Reasonably Practicable"이에요.
실무에서 자주 나오는 오해가 있어요.
"ALARP이면 수용해도 된다."
틀렸어요.
ALARP은 **"현실적으로 가능한 모든 Control 조치를 적용한 뒤, 그럼에도 남은 잔류위험을 수용하는 것"**이에요.
Control 조치 없이 ALARP 처리 → NB에서 바로 지적이에요.
올바른 ALARP 처리 흐름은 이렇게 돼요.
Risk 발생 → Risk Control 조치 적용 (Design / Protective / IFU)
→ Residual Risk 재평가 → 여전히 ALARP 영역
→ 추가 Control 불가 이유 명시 (기술적 한계 / 비례성 부족)
→ Benefit-Risk Analysis에서 최종 수용 판단
→ RMR(Risk Management Report)에 기록
이 흐름이 문서에 있어야 NB가 납득해요.
기준을 정의했다면, 다음은 그 기준으로 Residual Risk를 어떻게 평가하는지예요.
Severity와 Probability를 실제 수치로 추정하는 방법은 아래 글에서 이어서 확인하세요.
👉 [Residual Risk 평가에서 Severity vs Probability — 헷갈리면 탈락] 보러가기
Residual Risk 평가에서 Severity vs Probability (헷갈리면 탈락)
Residual risk 평가에서 가장 많이 틀리는 부분이 있습니다.👉 Severity와 Probability를 제대로 구분하지 않는 것!이 문제 하나로 Risk 평가 전체가 무너질 수 있습니다. 이 글에서는 ISO 14971:2019 기준으로
ivd-insights.tistory.com
👉 [GSPR-Risk Management 파일, 실제로 어떻게 연결해야 하는가] 보러가기
GSPR-Risk Management 파일, 실제로 어떻게 연결해야 하는가
GSPR 작성할 때 "Risk Management File 참조"라고만 써두면 되는 거 아닌가?— 이렇게 생각했다가 NB에서 "GSPR 요구사항과 RM 파일 사이의 연결 구조가 명확하지 않다"는 지적 받는 경우가 정말 많아요.단
ivd-insights.tistory.com
👉 [IVD Risk Management에서 Benefit-Risk Analysis 실제로 어떻게 쓰는 걸까] 보러가기
IVD Risk Management에서 Benefit-Risk Analysis실제로 어떻게 쓰는 걸까?
Risk Management 파일 만들면서 Benefit-Risk Analysis 섹션 어떻게 채워야 할지 막막했던 적 있지 않아요?"위험보다 이득이 크다" 한 줄 쓰고 넘어갔다가 NB에서 바로 지적 받은 케이스, 생각보다 엄청 많습
ivd-insights.tistory.com
정리
Risk Acceptability 판단 기준은 "제조사가 정한다"는 게 핵심이에요.
근데 그 기준이 어디서 왔는지, 왜 이 기준인지 설명 못 하면 NB에서 인정받지 못해요.
NB가 확인하는 핵심 3가지:
- Risk Acceptability Policy가 RMP 내에 명시적으로 있는가
- Severity는 임상 영향 기반, Probability는 데이터 기반으로 정의되었는가
- ALARP 처리가 Control 조치 후 잔류위험에만 적용되었는가
기준 설정 순서: IU 파악 → Severity 정의 → Probability 근거 → Matrix 작성 → ALARP 원칙 → Policy 문서화
가장 자주 틀리는 것: Probability 근거 없이 주관적 판단, ALARP 남발, Policy 자체가 없는 경우
다음 글 안내
Risk Acceptability 기준을 정했다면, 이제 그 기준 위에서 PMS와 PMPF를 어떻게 연결해야 하는지가 남아요.
다음 편은 PMS vs PMPF — 실무에서 헷갈리는 연결 구조 완전 정리로 찾아올게요.
Risk Acceptability 기준 설정하면서 막히는 부분 있으면 댓글로 남겨주세요.

'Risk management: ISO 14971' 카테고리의 다른 글
| GSPR-Risk Management 파일, 실제로 어떻게 연결해야 하는가 (0) | 2026.05.13 |
|---|---|
| PER Benefit-Risk 섹션과 RM 파일,왜 항상 같이 지적받을까? (0) | 2026.05.11 |
| IVD Risk Management에서 Benefit-Risk Analysis실제로 어떻게 쓰는 걸까? (0) | 2026.05.11 |
| Residual Risk Acceptability 기준 설정 (ALARP 실무 적용) (0) | 2026.04.16 |
| IVDR Risk Management 실패 사례 (NB 실제 지적 포인트) (0) | 2026.04.15 |