ISMS-P 인증이 EU CRA 준비에 어떻게 도움이 될까?

ISMS-P 인증을 보유한 한국 제조업체라면 EU 사이버복원력법(CRA) 준비의 상당 부분이 이미 완료된 상태입니다. 문제는 어느 부분이 충족됐고, 어느 부분이 아직 부족한지를 명확히 파악하는 것입니다.

이 가이드는 ISMS-P와 CRA의 요구사항을 직접 비교하여, 중복되는 영역과 새롭게 작업이 필요한 부분을 구체적으로 설명합니다.

먼저 확인: CRA가 내 제품에 적용되는가?

CRA는 모든 제품에 적용되지 않습니다. 아래 흐름도로 먼저 확인하십시오.

flowchart TD
    A["제품에 소프트웨어나\n펌웨어가 포함됩니까?"] -->|아니오| B["CRA 적용 제외\n(순수 기계식 하드웨어)"]
    A -->|예| C["EU 시장에\n최종 판매됩니까?"]
    C -->|아니오| B
    C -->|예| D["제품 분류 확인\n(부속서 III / IV 참조)"]
    D --> E["일반 제품\n(부속서 III/IV 미해당)"]
    D --> F["중요 제품 Class I/II\n(부속서 III 해당)"]
    D --> G["핵심 제품\n(부속서 IV 해당)"]
    E --> H["자체 적합성 평가 가능\nEU DoC + SBOM + 기술 파일"]
    F --> I["Class I: 조화 표준 적용 시 자체 평가\nClass II: 제3자 인증 필수"]
    G --> J["EU 사이버보안 인증서\n또는 제3자 인증 필수"]
    H --> K["2027년 12월부터 의무 적용"]
    I --> K
    J --> K

CRA 제품 분류 기준

ISMS-P와 CRA: 근본적인 차이

ISMS-P와 CRA는 보호 대상 자체가 다릅니다.

ISMS-P 인증은 "우리 회사는 정보보안 관리를 체계적으로 한다"는 것을 증명합니다. CRA는 "우리 제품은 EU 사이버보안 기준을 충족한다"는 것을 제품별로 증명해야 합니다. 조직 수준의 인증과 제품 수준의 규제는 관점이 근본적으로 다릅니다.

중복 영역: ISMS-P가 CRA를 충족하는 부분

아래 표는 ISMS-P 보호대책 요구사항(2.x)과 CRA 요구사항의 직접 매핑입니다. ISMS-P 2023 인증 기준(KISA) 기준으로 작성했습니다.

graph LR
    subgraph ISMS["ISMS-P 보호대책 요구사항"]
        A["2.6 접근통제"]
        B["2.7 암호화 적용"]
        C["2.8 개발 보안"]
        D["2.10 보안관리"]
        E["2.11 사고 대응"]
        F["2.3 외부자 보안"]
    end

    subgraph STRONG["CRA 충족 ✅ (강함)"]
        G["CRA\n접근통제 요구사항"]
        H["CRA\n데이터 기밀성·무결성"]
        I["CRA\n보안 설계 원칙"]
    end

    subgraph PARTIAL["CRA 부분 충족 ⚠️ (보완 필요)"]
        J["취약점 처리\n프로세스"]
        K["ENISA 신고\n체계"]
        L["공급망 보안 문서"]
    end

    A --> G
    B --> H
    C --> I
    D --> J
    E --> K
    F --> L

충족되지 않는 영역: ISMS-P만으로는 부족한 부분

이 부분이 핵심입니다. ISMS-P가 다루지 않는 CRA 고유 요구사항입니다.

핵심 메시지: ISMS-P는 '조직 보안'을 위한 프레임워크입니다. CRA는 '제품 보안'을 위한 규제입니다. 인증 조직은 보안 문화와 프로세스가 이미 갖춰져 있어 유리한 출발점에 있지만, EU 규제 특유의 문서와 신고 체계는 별도로 구축해야 합니다.

ENISA 신고 타임라인 상세

ENISA 신고는 3단계로 운영됩니다. ISMS-P 2.11 사고 대응 계획에 이 타임라인을 추가해야 합니다.

flowchart LR
    A["적극적으로 악용되는\n취약점 또는\n심각 사고 발견"] --> B["24시간 내\n조기 경보"]
    B --> C["72시간 내\n완전 통지"]
    C --> D{"유형"}
    D -->|취약점| E["수정 조치 가능 후\n14일 이내\n최종 보고"]
    D -->|심각 사고| F["통지 후\n30일 이내\n최종 보고"]

전체 격차 분석

ISMS-P → EU CRA 격차 분석

━━━ 강하게 충족 (추가 작업 최소) ━━━
✅ 접근통제 및 인증 (2.6) → CRA 접근통제 요구
✅ 암호화 정책 및 적용 (2.7) → CRA 데이터 보호 요구
✅ 보안 개발 프로세스 (2.8) → CRA 보안 설계 요구

━━━ 부분 충족 (제품 단위 증거 보완 필요) ━━━
⚠️  취약점 관리 (2.10) → 조직 수준이 아닌 제품별 CVE 추적 증거 필요
⚠️  사고 대응 (2.11) → ENISA 신고 요건(24h/72h/14일·30일) 추가 적용 필요
⚠️  공급망 보안 (2.3) → 타사 컴포넌트 SBOM 항목으로 구체화 필요

━━━ 새롭게 구축 필요 (ISMS-P 범위 외) ━━━
❌ SBOM: 제품 내 모든 소프트웨어 구성 요소 목록 생성 및 유지
❌ EU 적합성 선언(EU DoC): 판매 회원국 언어별 법적 문서
❌ 기술 파일(Technical File): 제품별 기술 문서 패키지
❌ CE 마킹: 적합성 평가 절차 완료 후 마킹
❌ 보안 업데이트 지원 약정: 지원 기간과 제품 예상 사용 기간 산정 근거 문서화
EU 공인대리인 (임의): EU 내 사업장이 없는 경우 운영상 권장됩니다. 미선임 자체는 위반이 아니며, EU 단일 창구 · 10년 문서 보관 · 시장 감시 기관 응답을 위임하는 선택지입니다. [상세](/ko/cra-authorised-representative)
❌ ENISA 신고 체계 SOP: 24h/72h/최종 보고 절차 문서화

주요 일정

ISMS-P가 주는 진짜 이점

ISMS-P 인증 기업이 CRA 준비에서 얻는 구체적인 이점은 다음과 같습니다.

시간 단축: 보안 문화, 위험 관리 방법론, 사고 대응 프로세스가 이미 갖춰져 있습니다. CRA 특유의 문서와 프로세스를 추가하는 작업만 남습니다.

비용 절감: 접근통제(2.6), 암호화(2.7), 개발 보안(2.8)에 대한 증거 문서가 이미 존재합니다. 기술 파일에 재활용 가능합니다.

바이어 신뢰: EU 수입업체와 바이어에게 ISMS-P 인증서는 조직 수준의 보안 성숙도를 증명합니다. CRA 적합성 선언을 제출할 때 신뢰도를 높이는 보완 자료가 됩니다.

심사 대비: ISMS-P 심사를 통해 외부 감사에 대응하는 프로세스가 형성되어 있습니다. EU 시장 감시 기관 조사에 대응하는 역량도 유사한 방식으로 작동합니다.

무료 도구

SBOM 생성 및 취약점 확인에 활용할 수 있는 무료 오픈소스 도구:

• Syft: 컨테이너 이미지 및 코드베이스에서 SBOM 자동 생성 (SPDX, CycloneDX 지원)
• cdxgen: CycloneDX 형식 SBOM 생성 (Java, Python, Node.js, Go, Rust 등 지원)
• Trivy: 컨테이너 및 파일시스템의 CVE 취약점 스캔
• OSV.dev: 패키지명과 버전으로 CVE 조회 (Google 운영)

CRA 적용 여부 무료 확인 →

본 콘텐츠는 정보 제공을 목적으로 하며 법적 조언을 구성하지 않습니다. EU 제품 규제에 관한 구체적인 준수 요건에 대해서는 EU 규제에 정통한 법률 전문가에게 상담하시기 바랍니다.