SecurityHeroblog

여권은 하나, 도장은 여러 개 — 리포트 하나로 여러 규제를

EU NIS2, DORA, ISO 27001, 한국 ISMS-P, 일본 APPI, 싱가포르 CII. 요구하는 서류 이름은 다 다른데 밑바탕은 겹칩니다. 규제별로 무엇을 요구하고 리스크 평가 리포트가 그중 어디를 채우는지 표로 정리했습니다.

여행 가방을 싸본 적 있으실 겁니다. 나라마다 요구하는 게 다릅니다. 어디는 비자를 미리 받아야 하고, 어디는 입국 신고서를 쓰라고 하고, 어디는 백신 접종 증명서를 봅니다. 창구도 다르고 도장 모양도 다릅니다.

그런데 그 모든 창구에서 똑같이 내미는 게 하나 있습니다. 여권입니다. “이 사람이 누구인가”는 나라마다 새로 증명하지 않습니다. 한 번 만들어 둔 신원 서류를 여섯 나라 창구에 여섯 번 보여줄 뿐입니다.

규제 대응도 비슷한 모양입니다. 이 글은 그 이야기입니다.

이름이 다르다고 다른 걸 묻는 건 아니다

사실 지역마다 요구하는 문서의 이름이 다릅니다. EU에는 NIS2 지침이 있고, 금융권에는 DORA가 있습니다. 국제 표준으로는 ISO 27001이 있고, 개인정보 쪽에는 GDPR 제32조가 걸립니다. 한국에는 ISMS-P가 있고 2027년부터 의무화됩니다. 일본에는 APPI의 안전관리조치가, 싱가포르에는 사이버보안법의 CII 규정이 있습니다.

추정 이름만 늘어놓으면 여섯 개의 숙제처럼 보입니다. 그런데 창구를 하나씩 들여다보면 묻는 내용이 겹칩니다. “당신 시스템의 위험을 어떻게 파악했고, 그래서 무엇을 어떻게 조치했는가.” 표현은 달라도 결국 이 질문입니다. 여권을 여섯 번 보여주는 것과 같은 구조입니다.

창구별로 무엇을 묻나

사실 아래 표의 왼쪽은 각 제도가 요구하는 것이고, 오른쪽은 리스크 평가 리포트가 그중 어느 칸을 채우는지입니다. 오른쪽 칸을 눈여겨봐 주세요. 전부가 아니라 일부입니다.

지역 제도 요구하는 것 리포트가 채우는 자리
EU NIS2 (제21조) 리스크관리 조치의 문서화 · 감독기관 감사 시 입증 리스크 분석 · 접근통제 · 암호화 조치의 기술 증빙
EU DORA (제9조) ICT 리스크관리 · 취약점 스캔 · 네트워크 점검 등 회복력 테스트 클라우드 ICT 리스크평가 · 테스트 증빙
Global ISO 27001 · GDPR 제32조 위험 기반 보안조치 수립 · 위험평가 문서화 ISO 27005 위험평가 입력 · 기술적 보안조치 증빙
KR ISMS-P (2027 의무화) 정보보호·개인정보 통합심사의 위험평가·기술통제 위험평가 · 기술통제 항목의 심사 근거자료
JP APPI 안전관리조치 “필요·적절한” 기술적 안전관리조치의 문서화 기술적 보안조치의 문서화 산출물
SG Cybersecurity Act (CII) 연 1회 리스크평가 · 2년마다 독립 감사 연간 클라우드 리스크평가 산출물 · 감사 대비

추정 표를 세로로 훑으면 오른쪽 칸의 단어가 계속 반복됩니다. 위험평가, 기술 증빙, 문서화. 여섯 나라 창구에서 여섯 번 요구하는 게 같은 종류의 서류 한 장이라는 뜻입니다.

왜 하나로 되나 — 뿌리가 같아서다

사실 RMF의 리스크 평가 리포트는 NIST SP 800-30과 ISO 27005 방법론으로 만들어집니다. 둘 다 특정 나라 전용이 아니라, 위험을 어떻게 재고 어떻게 적을지를 정해 둔 국제 표준입니다. 그리고 NIS2 쪽은 CIR 2024/2690(EU 이행규정)과 ENISA 기술이행지침(2025년 6월)을 참고해 정리합니다.

추정 각국 제도가 이 표준들을 밑재료로 삼고 있기 때문에, 표준 방식으로 한 번 잘 재어 두면 여러 창구에서 재활용이 됩니다. 여권을 발급받을 때 쓴 신원 정보가 어느 나라 입국 심사에서도 통하는 것과 같습니다. 물론 심사관이 요구하는 양식과 부가 자료는 창구마다 다를 수 있습니다.

여권은 입국 허가가 아니다

여기서 비유를 한 번 더 밀어야 합니다. 여권이 있다고 아무 나라나 들어갈 수 있는 건 아닙니다. 여권은 **“내가 누구인지 증명하는 서류”**지, **“들어와도 좋다는 허가”**가 아닙니다. 허가는 그 나라 심사관이 줍니다.

그 서류는 이렇게 생겼습니다. 위험 등급 분포와 요약이 앞에 오고, PDF나 DOCX로 내보내 창구에 제출합니다.

SecurityHero RMF 컴플라이언스 리포트 화면 — 요약, 위험 등급 분포, PDF·DOCX 내보내기 버튼
여러 창구에 같은 서류를 내밉니다. 양식은 창구마다 다를 수 있습니다.

사실 RMF 리포트도 같은 자리에 있습니다. 규제 대응의 기술 근거자료입니다. 인증서 발급, 사고 신고(NIS2 제23조 등), 법적 대리는 포함하지 않습니다. 스캔 결과를 PDF나 DOCX로 내보내 감사·심사에 제출하거나 검토용 근거로 쓰는 것까지가 이 서류의 몫입니다.

사실 도장을 찍는 자리는 따로 있습니다. EU 감독기관·CSIRT 창구와 사고 신고 채널은 NIS2 대리인의 역할이고, 개인정보 쪽 문의 대응은 GDPR 제27조 대리인의 역할입니다. 파트너사인 Prighter가 현지 법인 없이 이 두 대리인 역할을 수행합니다. 기술 검증과 법률 대리는 서로를 대신하지 못하고, 둘이 맞물릴 때 EU 현지 법인을 세우지 않고도 EU 고객을 받는 구조가 됩니다.

서류가 어디에 남는가

사실 5편에서 다룬 이야기와 이어집니다. 스캔 결과와 리포트는 고객이 지정한 S3 버킷에 저장되고 고객이 소유한 KMS 키로 암호화됩니다. 데이터가 고객의 저장소 경계를 벗어나지 않습니다. 참고로 한국과 일본은 EU 적정성 결정국이라 데이터 이전 면에서 여건이 유리한 편입니다.

추정 여권을 남의 서랍에 맡겨 두지 않는 것과 같습니다. 여러 창구에 보여줄 서류일수록, 그게 내 손 안에 있다는 사실이 중요해집니다.

짚고 넘어갈 것

  • 이 글은 법률 자문이 아닙니다. “이렇게 하면 NIS2를 준수합니다”라고 말할 수 있는 자리가 아닙니다. 준수 여부의 판단은 감독기관과 심사기관, 그리고 각 사의 법률 자문이 하는 일입니다.
  • RMF 리포트는 인증서가 아닙니다. 규제 대응의 기술 근거자료입니다. 인증서 발급도, 사고 신고도, 법적 대리도 포함하지 않습니다.
  • 표의 오른쪽 칸이 제도 전체를 덮지 않습니다. 각 제도에는 조직·절차·교육·공급망처럼 기술 스캔으로 확인할 수 없는 요구사항이 함께 있습니다. 채워지는 것은 위험평가와 기술통제 레이어입니다.
  • 심사 현장에서 어떤 형식을 요구할지는 창구마다 다릅니다. 같은 근거자료라도 제출 양식과 추가 소명은 개별적으로 확인해야 합니다.
  • 제도는 개정됩니다. 이 글은 2026년 8월 기준으로 공개된 문서를 바탕으로 썼습니다.

시리즈 목차

  1. EU에 물건 팔려면 왜 보안 서류를 내야 하나
  2. 리스크 평가라는 말이 어렵게 들리는 이유
  3. 고칠 게 3천 개인데 뭐부터 하나
  4. 아무것도 설치하지 않고 어떻게 점검하나
  5. “데이터가 국경을 넘지 않습니다”가 무슨 뜻인가
  6. 서류 하나로 여러 나라를 상대하기 ← 이 글