우리 회사는 ENX VCS 준비가 됐을까? — 협력사 Self Assessment 가이드

ENX VCS 완전 정복 — 5편 (完)

ENX VCS 완전 정복 시리즈

1

이전 글

ENX VCS란 무엇일까?

탄생 배경, TISAX 차이, R155→21434→5112→VCS 계층 구조

DONE

2

이전 글

ENX VCSA Catalogue 완전 분석

9개 챕터 24개 Control Question을 직접 뜯어보면

DONE

3

이전 글

심사관은 어떤 증적을 요구할까?

ENX VCS Audit Evidence 완전 정리

DONE

4

이전 글

ENX VCS 심사는 어떻게 진행될까?

Organizational Check부터 라벨 발급까지

DONE

5

지금 읽는 글 — 시리즈 완결

우리 회사는 ENX VCS 준비가 됐을까?

협력사를 위한 Self Assessment 가이드

NOW

준비 수준을 물어볼 때 자주 나오는 말

"21434는 하고 있으니까 VCS도 바로 받을 수 있지 않을까요?"

"우리가 어느 부분이 부족한지 모르겠어요. 심사를 받아봐야 알까요?"

"Secure Boot, SecOC 다 구현했는데 VCS 준비된 거 아닌가요?"

"어디서부터 시작해야 할지 모르겠어요."

이 글은 공개된 VCSA(Vehicle Cyber Security Audit Catalogue) 1.1을 기반으로 작성됐다. "이 항목을 모두 체크하면 심사를 통과한다"는 의미가 아니다.

실제 심사 결과는 심사기관만 판단할 수 있다. 이 체크리스트는 VCSA의 MUST 요구사항을 기반으로 "지금 우리 조직에 어떤 갭이 있는가"를 스스로 점검하기 위한 자가 진단 도구다.

---

이 Self Assessment를 사용하는 방법

각 항목에 대해 세 가지 중 하나로 평가해보자.

평가	의미	판단 기준
✅ YES	조직 차원의 프로세스와 수행 기록이 모두 존재한다	심사관에게 즉시 보여줄 수 있는 증적이 있다
⚠️ PARTIAL	프로세스는 있지만 수행 기록이 부족하거나, 일부 프로젝트에만 적용된다	문서는 있지만 실제 운영 증거가 약하다
❌ NO	프로세스 또는 수행 기록이 존재하지 않는다	심사관의 질문에 답할 수 없다

⚠️ 주의 — PARTIAL도 위험하다

"프로세스 문서는 있다"는 YES가 아니다. VCSA의 MUST 요구사항은 대부분 "프로세스가 수립되어 있고(established), 구현되어 있고(implemented), 유지되어야 한다(maintained)"는 세 가지를 요구한다. 문서만 있고 수행 기록이 없다면 PARTIAL 또는 NO에 가깝다.

ℹ️ 체크리스트 출처 안내

각 항목의 MUST 배지는 VCSA 1.1 원문의 "Requirements (must)" 컬럼에 명시된 MUST 요구사항에서 직접 도출됐다. 자주 지적 배지는 ENX Portal 공개 자료와 심사기관 공개 블로그에서 언급된 내용을 기반으로 했다.

---

챕터별 Self Assessment Checklist

Ch.1

Organizational Cybersecurity

CQ 4개 / MUST 요구사항 14개

핵심 관점 — 보안이 엔지니어 개인의 역량이 아니라 조직 시스템으로 운영되고 있는가?

1.1차량 사이버보안 리스크와 관련된 정책이 문서화되어 있고 보안 목표와 규칙을 포함한다

MUST

1.1정책의 주기적 검토와 필요 시 개정 이력이 존재한다

MUST자주 지적

1.2CSMS의 범위(적용 조직, 프로젝트, 제품)가 정의되고 관리된다

MUST

1.2경영진이 CSMS의 효과성을 정기적으로 검토한 기록이 있다

MUST자주 지적

1.2VCSA Self-Assessment 등을 통해 적용 가능한 통제 항목이 결정되어 있다

MUST

1.2개념·개발·생산·운영 단계 전반의 사이버보안 활동을 지원하는 규칙과 프로세스가 수립·유지된다

MUST

1.3차량 사이버보안 책임이 정의·문서화·할당·소통되어 있다 (RASIC, 조직도 등)

MUST

1.3담당자에게 책임 수행을 위한 필요 권한과 리소스(인력·예산·도구)가 확보되어 있다

MUST

1.4각 프로젝트에 사이버보안 활동 책임자가 지정되어 있고, 고객 요구사항을 반영한 사이버보안 계획(WP-06-01)이 존재한다

MUST

1.4프로젝트 주요 마일스톤에서 사이버보안 계획이 업데이트·검증된다

MUST

1.4각 항목·컴포넌트의 사이버보안 논거를 제공하는 Cybersecurity Case(WP-06-02)가 작성된다

MUST자주 지적

자가 점검 질문 — 지금 당장 "우리 CSMS의 책임자는 누구인가"와 "경영진이 마지막으로 CSMS를 검토한 것은 언제인가"에 즉시 답할 수 있는가?

Ch.2

Human Resources — Cybersecurity Culture

CQ 1개 / MUST 요구사항 3개

핵심 관점 — "보안 전문가가 있는가"가 아니라 "조직 전체의 보안 역량이 관리되고 있는가?"

2.1사이버보안 관련 민감한 업무 영역과 직무 역할이 결정되어 있다

MUST

2.1직무별 직원 요건이 결정되고 충족된다 (역량 프로필, Skill Matrix 등)

MUST

2.1직원이 사이버보안 업무 관행을 내재화해야 할 필요성에 대해 교육받고 인식 제고가 이루어진다 — 교육 수행 기록이 존재한다

MUST자주 지적

자가 점검 질문 — "TARA를 수행하는 이 엔지니어가 TARA를 수행할 역량이 있다는 근거가 있는가?" — 교육 이력이나 역량 프로필로 답할 수 있는가?

Ch.3

Risk Management

CQ 3개 / MUST 요구사항 14개

핵심 관점 — TARA가 존재하는가보다, TARA 결과가 실제 의사결정(리스크 처리, 목표 도출)에 연결되는가?

3.1TARA에 관련 이해관계자가 참여한다

MUST

3.1사이버보안 관련 항목·컴포넌트와 자산이 식별·문서화된다 (WP-15-02)

MUST

3.1위협 시나리오 식별 시 UN R155 Annex 5의 적용 가능한 시나리오가 포함된다 (WP-15-03)

MUST자주 지적

3.1영향 평가 방법론에 안전·재무·운영·개인정보 측면이 포함된다 (WP-15-04)

MUST

3.1공격 경로 분석 방법, 공격 가능성 평가 방법, 리스크 값 산정 방법이 정의되어 있다 (WP-15-05~07)

MUST

3.2각 위협 시나리오에 대해 회피·감소·공유·수용 중 하나의 리스크 처리 옵션이 결정된다

MUST

3.2Cybersecurity Goal이 정의되고 TARA 결과와 연결된다 (WP-09-03)

MUST자주 지적

3.3TARA 결과에서 발생하는 고객 관련 리스크가 고객에게 효과적으로 소통된다 — 소통 기록이 있다

MUST자주 지적

자가 점검 질문 — 특정 위협 시나리오를 하나 골라서 WP-15-03(위협) → WP-09-03(목표) → 요구사항까지 추적해볼 수 있는가? 중간에 연결이 끊어지는 곳이 있는가?

Ch.4

Internal Assessments

CQ 1개 / MUST 요구사항 4개

핵심 관점 — 조직이 스스로 문제를 발견할 수 있고, 발견된 문제가 추적되는가?

4.1주기적이고 독립적인 내부 감사가 수행된다 — 감사자가 업무 당사자와 분리되어 있다

MUST자주 지적

4.1사이버보안 리스크 관리의 효과성이 검증된다 (KPI 보고서 등)

MUST

4.1감사 결과가 기록·보존된다 (WP-05-05)

MUST

4.1잠재적 부적합에 대한 시정 조치가 시작되고 완료 여부가 추적된다

MUST

자가 점검 질문 — 최근 내부 감사 결과를 5분 안에 보여줄 수 있는가? 그리고 그 결과에서 나온 시정조치가 완료됐는지 추적 가능한가?

Ch.5

Concept and Product Development Phase

CQ 3개 / MUST 요구사항 10개

핵심 관점 — 개발 결과물의 추적성이 TARA에서 Validation까지 끊기지 않는가?

5.1리스크 처리 결정에 기반한 Cybersecurity Goal이 결정되고 Concept이 도출된다 (WP-09-03, WP-09-06)

MUST

5.1Item Definition이 정의된다 — 항목 기능, 경계, 운영 환경, 예비 아키텍처 포함 (WP-09-01)

MUST

5.1사이버보안 요구사항이 정의되고, 목표 및 클레임과의 완전성·일관성이 검증된다

MUST

5.1요구사항이 아키텍처 설계의 컴포넌트에 할당된다

MUST

5.2컴포넌트 구현·통합 결과가 사이버보안 사양에 적합한지 검증된다 (WP-10-04, WP-10-07)

MUST

5.2개발 중 발견된 취약점이 기록된다 (WP-10-05) — "없다"가 아니라 "기록했다"가 맞다

MUST자주 지적

5.3사이버보안 목표 달성을 확인하는 Validation 활동이 수행되고 불합리한 잔여 리스크 없음이 결정된다 (WP-11-01)

MUST자주 지적

자가 점검 질문 — TARA → Goal → Requirement → Architecture → Verification → Validation 체인을 하나의 프로젝트에서 끊기지 않게 추적할 수 있는가?

Ch.6

Post-Development Phase

CQ 2개 / MUST 요구사항 3개

핵심 관점 — 개발이 끝나고 양산으로 넘어갈 때 보안 요구사항이 실제로 유지되는가?

6.1양산 이전 릴리스를 위한 요구사항이 식별·검토되고 릴리스 보고서가 존재한다 (WP-06-04)

MUST

6.2생산 통제 계획(WP-12-01)에 사이버보안 요구사항이 반영된다 — Key Provisioning, Secure Boot 설정 등 포함

MUST자주 지적

자가 점검 질문 — 양산 라인에서 ECU에 키를 주입하거나 보안 설정을 적용하는 과정이 Production Control Plan에 명시되어 있는가?

Ch.7

Operations Security

CQ 5개 / MUST 요구사항 5개

핵심 관점 — 차량 수명 종료까지 보안이 유지되는가? 사고 발생 시 실제로 대응할 수 있는가?

7.1차량 내 항목·컴포넌트의 사이버보안 유지·향상을 위한 업데이트 개발 프로세스가 수립된다

MUST

7.3폐차 관련 사이버보안 요구사항(키·인증서 삭제 등)을 제공하는 절차가 수립된다

MUST

7.4사이버보안 사고 대응 계획이 수립되고 — 시정 조치, 이해관계자 소통, 법적 의무를 포함한다 (WP-13-01)

MUST

7.5사고 후 대응 검토(Post Incident Response Review)가 수행되고 기록된다

MUST자주 지적

자가 점검 질문 — 지금 당장 심각한 보안 취약점이 발견됐다는 연락을 받으면, 누가 어떤 순서로 무엇을 해야 하는지 조직 내에 명확히 정의되어 있는가?

Ch.8

Supply Chain Relationships

CQ 1개 / MUST 요구사항 4개

핵심 관점 — 우리 회사 보안뿐 아니라, 우리가 사용하는 협력사의 보안 수준을 어떻게 관리하는가?

8.1공급사의 사이버보안 역량이 평가·선정된다 — 역량 기록(RC-07-02)이 존재한다

MUST자주 지적

8.1공급사와의 상호작용·의존성·책임을 정의하는 프로세스가 수립된다 — CIAD 또는 동등한 수단이 계약에 포함된다

MUST자주 지적

8.1항목·컴포넌트의 사이버보안 목표와 요구사항이 공급사에 전달되고 소통 기록이 있다

MUST

8.1조직과 공급사 간 분산된 사이버보안 활동을 명시하는 프로세스가 수립된다

MUST

자가 점검 질문 — 우리가 사용하는 반도체, 소프트웨어 라이브러리, 모듈의 협력사 중 사이버보안 역량을 공식적으로 평가한 곳이 있는가? 그 기록이 있는가?

Ch.9

Continual Cybersecurity Activities

CQ 4개 / MUST 요구사항 10개

핵심 관점 — 새로운 CVE나 위협 정보가 등장했을 때 조직이 체계적으로 인지하고 대응하는가?

9.1사이버보안 정보 수신을 위한 내·외부 소스가 선정되고 관리된다 (WP-08-01) — NVD, CVE, Auto-ISAC 등

MUST

9.1수집된 정보를 이벤트로 분류하기 위한 트리거가 정의·유지된다 (WP-08-02)

MUST자주 지적

9.1수집된 정보의 모니터링과 분류가 실제로 수행되고 기록된다 (WP-08-03)

MUST자주 지적

9.2사이버보안 이벤트가 항목·컴포넌트의 취약점을 식별하기 위해 평가된다 (WP-08-04)

MUST

9.3취약점이 분석되고, 취약점으로 분류되지 않은 경우 근거가 문서화된다 (WP-08-05)

MUST

9.3취약점 분석 및 개선 결과가 고객에게 적시에 소통된다

MUST

9.4식별된 취약점이 잔여 리스크를 수용 가능한 수준으로 관리된다 (WP-08-06)

MUST

9.4취약점 관리 조치의 책임 할당을 위한 계약 모델이 수립된다

MUST

자가 점검 질문 — 지난 6개월 동안 우리 제품에 사용된 OSS나 컴포넌트에서 발견된 CVE를 모니터링하고 분석한 기록이 있는가?

---

Self Assessment 결과 해석

이 체크리스트는 VCSA 1.1 MUST 요구사항 기반의 자가 진단이다. 실제 심사 결과와 다를 수 있으며, 심사 결과는 심사기관만 판단할 수 있다.

대부분 YES

VCSA 요구사항 관점 준비 가능성 높음

공개된 VCSA 요구사항 기준으로 상당한 체계를 보유할 가능성이 있다. 다음 단계는 심사기관 선정과 킥오프 미팅을 통한 상세 갭 확인이다.

YES와 PARTIAL 혼재

갭이 있지만 준비 시작 가능

PARTIAL 항목에서 "프로세스는 있지만 수행 기록이 부족한" 경우가 많다. 특히 Ch.1 거버넌스, Ch.8 공급망, Ch.9 취약점 모니터링 챕터의 PARTIAL을 먼저 확인하는 것을 권장한다.

NO가 다수

CSMS 체계 수립이 우선

심사 준비 이전에 V-CSMS 체계 자체를 수립하는 것이 먼저다. ENX Portal의 Self-Assessment와 심사기관의 사전 Gap Assessment 서비스를 활용하는 것을 고려할 수 있다.

---

공개 자료 기준으로 많이 지적된다고 언급된 영역

ENX Portal 공개 자료와 심사기관들의 공개 블로그에서 언급된 내용을 정리하면, 개발 엔지니어링(Ch.5) 중심 조직에서 다음 세 챕터가 상대적으로 준비가 부족한 경향이 있다고 언급된다.

챕터	자주 나온다고 언급된 갭	근거
Ch.1 (거버넌스)	정책 개정 이력 없음 / 경영진 검토 기록 없음 / Cybersecurity Case 미작성	ENX Portal 공개 자료 기반
Ch.8 (공급망)	CIAD 미존재 / 공급사 보안 역량 평가 기록 없음	ENX Portal, DQS 공개 블로그 기반
Ch.9 (취약점 모니터링)	모니터링 프로세스는 있지만 수행 기록(WP-08-03) 없음 / 트리거 미정의	ENX Portal 공개 자료 기반

💡 이 글에서 사용한 자료 출처

ENX VCSA 1.1 (ENX Portal 공개 다운로드) / ENX Portal 공식 FAQ 및 등록 가이드 / ISO/PAS 5112 — ENX VCSA 매핑 파일 (ENX Portal 공개 다운로드) / DQS, TÜV NORD 등 심사기관 공개 블로그

---

ENX VCS는 Secure Boot를 심사하지 않는다. SecOC를 심사하지 않는다.

VCSA의 24개 질문이 확인하려는 것은 단 하나다.

"이 조직은 차량 사이버보안을 지속적으로 수행할 수 있는 체계를 갖추고 있는가?"

1편부터 5편까지 살펴본 V-CSMS, VCSA, Audit Evidence, 심사 프로세스, Self Assessment — 모든 내용은 이 한 문장으로 연결된다. 차량 사이버보안은 기술의 문제이기도 하지만, 그 기술이 조직 안에서 지속적으로 작동할 수 있도록 만드는 것은 결국 조직 운영의 문제다.

핵심 요약 — 시리즈 완결

1

이 체크리스트는 VCSA 1.1 MUST 요구사항 기반의 자가 진단이다 — 심사 통과 기준이 아니며, 실제 심사 결과는 심사기관만 판단할 수 있다.

2

PARTIAL도 위험하다 — "문서가 있다"는 YES가 아니다. MUST 요구사항은 프로세스 수립·구현·유지 세 가지를 요구한다.

3

공개 자료 기준으로 Ch.1, Ch.8, Ch.9가 자주 언급된다 — 기술 구현 문제가 아니라 조직 운영 체계의 문제에 가깝다.

4

자가 점검 질문이 핵심이다 — 각 챕터의 자가 점검 질문에 즉시 답할 수 없다면, 그 영역이 갭일 가능성이 높다.

5

ENX VCS는 조직이 사이버보안을 지속적으로 수행할 수 있는가를 본다 — 1편부터 5편까지의 모든 내용이 이 한 문장으로 연결된다.

ENX_VCS SelfAssessment VCSA V-CSMS ISO/PAS5112 ISO/SAE21434 자동차사이버보안인증 공급망보안 CSMS갭분석 ENX_VCS준비 TARA