ENX VCS 완전 정복 — 2편
ENX VCS 완전 정복 시리즈
1
이전 글
ENX VCS란 무엇일까?
탄생 배경, TISAX 차이, R155→21434→5112→VCS 계층 구조
DONE
2
지금 읽는 글
ENX VCSA Catalogue 완전 분석
9개 챕터 24개 Control Question을 직접 뜯어보면
NOW
3
다음 글
심사관은 어떤 증적을 요구할까?
ENX VCS Audit Evidence 완전 정리
NEXT
4
예정
ENX VCS 심사는 어떻게 진행될까?
Organizational Check부터 라벨 발급까지
SOON
5
예정
우리 회사는 준비됐을까?
협력사를 위한 Self Assessment 가이드
SOON
ENX VCS 심사를 앞두고 자주 듣는 말
"21434 잘 하고 있으면 VCS 심사도 자연스럽게 통과할 수 있는 거 아닌가요?"
"심사관이 Secure Boot 구현 여부를 직접 확인하는 건가요?"
"VCSA가 ISO/SAE 21434랑 뭐가 다른 건지 모르겠어요."
"24개 질문이라는데 실제로 어떤 질문인지 알 수가 없어요."
ENX VCS 심사관은 ISO/SAE 21434 원문을 기준으로 심사하지 않는다.
심사에서 실제로 사용되는 기준은 VCSA(Vehicle Cyber Security Audit) Catalogue다. 24개의 Control Question이 조직의 V-CSMS를 평가한다. 이 글은 VCSA 1.1 원문을 직접 분석해 각 질문이 무엇을 확인하려는지 해석한다.
심사에서 실제로 사용되는 기준은 VCSA(Vehicle Cyber Security Audit) Catalogue다. 24개의 Control Question이 조직의 V-CSMS를 평가한다. 이 글은 VCSA 1.1 원문을 직접 분석해 각 질문이 무엇을 확인하려는지 해석한다.
VCSA는 무엇인가 — ISO/SAE 21434와 무엇이 다른가
ISO/SAE 21434는 "차량 사이버보안 엔지니어링을 어떻게 수행할 것인가"를 정의하는 표준이다. VCSA는 다른 질문을 던진다. "그것을 실제로 수행하고 있다는 것을 어떻게 확인할 것인가."
ENX VCS에 승인된 심사기관(BSI, DEKRA, DQS, SGS-TÜV Saar, TÜV NORD, TÜV SÜD)은 모두 동일한 VCSA를 기준으로 심사한다. 심사기관이 다르더라도 동일한 질문지를 사용해야 한다는 것이 ENX VCS가 기존 개별 21434 인증과 가장 크게 다른 점이다.
ℹ️ VCSA 1.1 구성 (공개 파일 직접 분석 기준)
Chapter 9개 / Control Question 24개 / Requirements 76개
심사관은 24개 Control Question을 중심으로 조직의 V-CSMS를 평가한다. 각 질문에는 MUST 요구사항과 Possible Evidence(증적 예시)가 함께 정의되어 있다.
Chapter 9개 / Control Question 24개 / Requirements 76개
심사관은 24개 Control Question을 중심으로 조직의 V-CSMS를 평가한다. 각 질문에는 MUST 요구사항과 Possible Evidence(증적 예시)가 함께 정의되어 있다.
VCSA 1.1 — 챕터별 Control Question 분포
Ch.1
4개
Ch.2
1개
Ch.3
3개
Ch.4
1개
Ch.5
3개
Ch.6
2개
Ch.7
5개
Ch.8
1개
Ch.9
4개
9개 챕터 — 심사관의 시선으로 읽기
각 챕터를 VCSA 원문 기반으로 해석한다. "심사관이 이 질문으로 무엇을 확인하려 하는가"에 초점을 맞춘다.
1
Organizational Cybersecurity
심사관의 핵심 질문 — "이 회사는 보안을 개별 엔지니어의 역량에 의존하는가, 아니면 조직 차원의 체계로 관리하는가?"
1.1
Are cybersecurity policies managed?
조직 규모와 구조에 맞는 사이버보안 정책이 수립되어야 한다.
차량 사이버보안 리스크와 관련된 정책이 정의·문서화되어 있어야 하며, 보안 목표와 규칙을 포함해야 한다
정책의 주기적 검토와 필요 시 개정이 수립되어 있어야 한다
대표 증적
[WP-05-01] 사이버보안 정책·규칙·프로세스 / 경영진 commitment 증거 / ISMS 인증서
1.2
Are vehicle related cybersecurity processes managed within the organization?
사이버보안은 조직의 전략 목표에 내재화되어야만 지속 가능하다.
CSMS의 범위가 정의·관리되어야 한다
경영진에 의한 CSMS 효과성 정기 검토가 이루어져야 한다
VCSA 자체 점검(self-assessment) 등을 통해 적용 가능한 통제 항목이 결정되어야 한다
개념·개발·생산·운영 단계 전반의 사이버보안 활동을 지원하는 규칙과 프로세스가 수립·유지되어야 한다
이해관계자와의 사이버보안 정보 공유·소통 체계가 수립되어야 한다
도구가 제품 사이버보안에 부정적 영향을 주지 않도록 관리되어야 한다
대표 증적
ISMS 또는 CSMS 매뉴얼 / 프로세스 표준 문서 / [WP-05-01], [WP-05-03], [WP-05-04]
1.3
Are processes established to organize cybersecurity responsibilities?
책임이 명확히 할당·위임되어야 CSMS가 실질적으로 운영된다.
조직 내 차량 사이버보안 책임이 정의·문서화·할당·소통되어야 한다
담당자가 조직 내부와 관련 비즈니스 파트너에게 공유되어야 한다
담당자에게 필요한 권한이 위임되어야 한다
책임을 충분히 수행하기 위한 리소스(인력·시간·예산·도구)가 확보되어야 한다
대표 증적
DIA, RASIC Chart, 보고·에스컬레이션 메커니즘이 포함된 조직도
1.4
Are processes established to manage project dependent cybersecurity?
프로젝트 생애주기 전반에서 사이버보안 활동을 고려해야 한다.
프로젝트 사이버보안 활동의 책임이 할당·소통되어야 한다
고객 사이버보안 요구사항이 식별되고 프로젝트 계획과 연결된 사이버보안 계획이 수립되어야 한다
주요 마일스톤에서 사이버보안 계획이 업데이트·검증되어야 한다
항목 또는 컴포넌트의 사이버보안 논거를 제공하는 Cybersecurity Case가 작성되어야 한다
리스크 기반 접근으로 사이버보안 평가 수행 여부가 결정·문서화되어야 한다
대표 증적
[WP-06-01] 사이버보안 계획 / [WP-06-02] 사이버보안 케이스 / [WP-06-03] 사이버보안 평가 보고서
2
Human Resources — Cybersecurity Culture
심사관의 핵심 질문 — "보안 전문가 몇 명이 있는가"가 아니라 "보안 역량이 조직 전체에 내재화되어 있는가"
2.1
Are cybersecurity culture and cybersecurity awareness established, implemented, and maintained?
역량 관리, 인식 관리, 지속적 개선을 포함한 사이버보안 문화를 수립·유지해야 한다.
민감한 업무 영역과 직무 역할이 결정되어야 한다
직무별 직원 요건이 결정되고 충족되어야 한다
직원이 사이버보안 업무 관행을 내재화해야 할 필요성에 대해 교육·인식 제고가 이루어져야 한다
대표 증적
[WP-05-02] 역량 관리 증거 / 역할별 역량 프로필 및 교육 이력 / 인식·교육 관리 증거
3
Risk Management
심사관의 핵심 질문 — "TARA 문서가 있는가"가 아니라 "리스크 분석이 실제 의사결정에 활용되고 있는가"
3.1
Are processes and methods established to perform TARA to determine cybersecurity risks for an item/components across the vehicle lifecycle?
차량 생애주기 전반에서 항목·컴포넌트에 영향을 미칠 수 있는 위협 시나리오를 식별·결정해야 한다.
TARA에 관련 이해관계자가 참여해야 한다
사이버보안 관련 항목과 컴포넌트가 식별·문서화되어야 한다
사이버보안 자산과 속성이 식별되어야 한다
손상 시나리오를 유발할 수 있는 위협 시나리오가 식별되어야 하며, 최소한 UN R155 Annex 5의 적용 가능한 시나리오가 포함되어야 한다
손상 시나리오가 식별되어야 하며, 최소한 안전·재무·운영·개인정보 측면의 영향 카테고리가 고려되어야 한다
공격 경로 분석·구축 방법, 공격 가능성 평가 방법, 리스크 값 산정 방법이 정의되어야 한다
대표 증적
[WP-15-01~08] 손상 시나리오, 자산, 위협 시나리오, 영향 평가, 공격 경로, 리스크 값 등
3.2
Are processes established to treat cybersecurity risks for an item across the vehicle lifecycle?
식별된 위협 시나리오에 대한 적절한 리스크 처리 옵션을 선택해야 한다.
각 위협 시나리오별로 리스크 회피·감소·공유·수용 중 하나의 처리 방식이 적용되어야 한다
리스크 감소를 위한 Cybersecurity Goal이 정의되어야 한다
리스크 공유·이전을 위한 Cybersecurity Claim이 명시되어야 한다
리스크 처리가 사이버보안 목표와 클레임에 대해 완전하고 일관성 있어야 한다
대표 증적
[WP-09-02] TARA 결과 / [WP-09-03] 사이버보안 목표 / [WP-09-04] 사이버보안 클레임
3.3
Are processes established to transparently communicate cybersecurity risks?
리스크 방법론과 잔여 리스크가 고객에게 소통되어야 한다.
TARA 결과에서 발생하는 고객 관련 리스크가 효과적으로 소통되어야 한다
4
Internal Assessments
심사관의 핵심 질문 — "조직은 문제를 스스로 발견할 수 있는가? 그리고 발견된 문제를 추적·개선하는가?"
4.1
Are processes established to review the effectiveness of CSMS within the organization?
CSMS 조치의 효과성을 검증해 관련 리스크가 실질적으로 감소되었는지 확인해야 한다.
사이버보안 정책·절차 준수가 주기적이고 독립적인 내부 감사를 통해 검증되어야 한다
사이버보안 리스크 관리의 효과성이 적절히 검증되어야 한다
감사 결과가 기록·보존되어야 한다
잠재적 부적합에 대한 시정 조치가 시작되고 추적되어야 한다
대표 증적
리스크 분석 피어 리뷰 / 사이버보안 평가 보고서 / [WP-05-05] 조직 사이버보안 감사 보고서 / Lessons Learned 및 시정조치 프로토콜
5
Concept and Product Development Phase
심사관의 핵심 질문 — "TARA에서 도출된 목표가 요구사항으로 연결되고, 그것이 검증·확인까지 추적되는가?"
5.1
Are processes established to define the item and specify cybersecurity requirements?
사이버보안 설계와 요구사항은 차량 항목·컴포넌트와 병행해 개발되어야 한다.
리스크 처리 결정에 기반한 Cybersecurity Goal이 결정되고, 이로부터 Cybersecurity Concept이 도출되어야 한다
항목·컴포넌트의 기능, 경계, 운영 환경, 예비 아키텍처가 결정되어야 한다
항목과 운영 환경에 대한 사이버보안 요구사항이 정의되어야 한다
요구사항의 완전성·정확성·일관성이 목표 및 클레임에 대해 검증되어야 한다
정의된 요구사항이 아키텍처 설계의 컴포넌트에 할당되어야 한다
대표 증적
[WP-09-01] Item Definition / [WP-09-02~06] TARA·목표·클레임·검증 보고서·컨셉
5.2
Are processes established to verify the fulfilment of cybersecurity requirements on components during the development phase?
구현·통합 단계의 시험 결과가 사이버보안 사양에 적합한지 확인해야 한다.
정의된 사이버보안 사양이 상위 추상화 수준(아키텍처 설계 등)의 사양에 적합해야 한다
컴포넌트 구현·통합 결과가 사이버보안 사양에 적합한지 검증되어야 한다
대표 증적
[WP-10-04] 사이버보안 사양 검증 보고서 / [WP-10-05] 개발 중 발견된 취약점 / [WP-10-06] 통합 및 검증 보고서
5.3
Are processes established that validate cybersecurity goal and claims on item level during the development phase?
검증된 항목이 사이버보안 목표(차량 레벨)를 충족하는지 확인해야 한다.
사이버보안 목표 달성과 클레임의 유효성을 확인하기 위한 확인(Validation) 활동이 수행되어야 한다
불합리한 잔여 리스크가 없음이 결정되어야 한다
대표 증적
[WP-11-01] Validation 보고서
6
Post-Development Phase (excluding operations and maintenance)
심사관의 핵심 질문 — "개발이 끝난 후 양산으로 넘어갈 때 사이버보안 요구사항이 실제로 유지되는가?"
6.1
Are processes established for the release of an item or component for post-development phases?
사이버보안 평가 보고서가 필요한 사이버보안 수준이 달성됐음을 확인해야 양산 릴리스가 가능하다.
양산 이전 릴리스를 위한 요구사항이 식별·검토되어야 한다
양산 후 단계를 위한 사이버보안 요구사항이 수용되어야 한다
대표 증적
[WP-06-04] 양산 이전 릴리스 보고서 / [WP-06-01~03] 사이버보안 계획·케이스·평가 보고서
6.2
Are processes established to apply cybersecurity requirements during production phase?
생산 단계에서도 사이버보안 요구사항이 생산 통제 계획에 반영되어야 한다.
생산 단계에 사이버보안 요구사항이 적용되어야 하며, 이를 반영한 생산 통제 계획이 수립되어야 한다
대표 증적
[WP-12-01] Production Control Plan
7
Operations Security
심사관의 핵심 질문 — "보안 사고가 발생했을 때 대응할 수 있는가? 차량 수명 종료까지 보안이 유지되는가?"
7.1
Are processes established for updates to items or components?
차량 내 항목·컴포넌트의 사이버보안 유지·향상을 위한 업데이트 개발 및 업데이트 기능 프로세스가 수립되어야 한다
대표 증적
업데이트 프로세스 문서 및 관련 작업 산출물
7.2
Are processes established for communicating end of cybersecurity support for an item/component to customer?
사이버보안 지원 종료 결정이 고객에게 소통되어야 한다.
대표 증적
[WP-14-01] 사이버보안 지원 종료 소통 절차
7.3
Are processes established to make available cybersecurity requirements for decommissioning?
폐차 관련 양산 이후 사이버보안 요구사항을 제공하는 절차가 수립되어야 한다
7.4
Is a process established to respond to cybersecurity incidents?
사이버 공격의 피해를 제한하고 재발을 방지하기 위한 체계적 처리가 필요하다.
각 사이버보안 사고에 대한 대응 계획이 수립되어야 하며, 시정 조치, 이해관계자 소통 계획, 법적 의무 포함이 필요하다
대표 증적
디지털 조사 프로세스 문서 / 조사 보고서 / 시정조치 프로토콜 / [WP-13-01] 사이버보안 사고 대응 계획
7.5
Is a process established to validate the effectiveness and adequacy of the response to a cybersecurity incident?
사이버보안 사고 대응 프로세스의 효과성과 적절성을 증명해야 한다.
사고 후 대응 검토(Post Incident Response Review)가 수행되어야 한다
대표 증적
사고 대응 보고서 / 취약점 스캐닝 보고서 / 수리 정보 / 리스크 평가 피드백 메커니즘
8
Supply Chain Relationships
심사관의 핵심 질문 — "당신 회사가 사용하는 협력사의 보안 수준을 어떻게 확인하고 관리하는가?"
8.1
Are processes established to manage dependencies between the auditee organization and its VCS relevant suppliers?
계약 파트너·공급사와의 사이버 리스크 관련 의존성을 식별·평가·처리해야 한다.
기존 공급사 및 공급사 후보의 사이버보안 역량이 평가·선정되어야 한다
공급사와의 상호작용·의존성·책임을 정의하는 견적 프로세스가 수립되어야 한다
항목·컴포넌트의 사이버보안 목표와 요구사항이 공급사에 소통되어야 한다
조직과 공급사 간 분산된 사이버보안 활동을 명시하는 프로세스가 수립되어야 한다
대표 증적
공급사 사이버보안 역량 기록 [RC-07-02] / CIAD(Cybersecurity Interface Agreement for Development) / TISAX ISMS Label
9
Continual Cybersecurity Activities
심사관의 핵심 질문 — "신규 취약점이 발견됐을 때 조직은 어떻게 인지하고 어떻게 대응하는가?"
9.1
Are processes established to monitor cyber security information and to identify cybersecurity events from the monitored information?
차량 생애 전반에 걸쳐 사이버보안 위협 정보를 모니터링·수집하고 사이버보안 이벤트를 식별해야 한다.
사이버보안 정보 수신을 위한 내·외부 소스가 선정·관리되어야 한다
수집된 정보의 분류(triage)를 위한 트리거가 정의·유지되어야 한다
수집된 사이버보안 정보의 모니터링과 분류가 수행되어야 한다
사이버보안 정보가 사이버보안 이벤트로 전환되는지 확인해야 한다
대표 증적
[WP-08-01] 선정된 정보 소스 / [WP-08-02] 트리거 / [WP-08-03] 분류된 사이버보안 이벤트
9.2
Are processes established to evaluate cybersecurity events?
공격 벡터, 알려진·신흥 사이버 위협, 사이버 취약점을 지속적으로 평가·분류해야 한다.
사이버보안 이벤트가 항목·컴포넌트의 취약점을 식별하기 위해 평가되어야 한다
대표 증적
RASIC 테이블 / [WP-08-04] 사이버보안 이벤트로부터의 취약점
9.3
Are processes established to identify and analyse vulnerabilities?
취약점을 파악하기 위해 취약점(weakness)이 분석되어야 한다.
취약점을 식별하기 위해 취약점이 분석되어야 한다
취약점 분석과 취약점 개선 관련 결과가 고객에게 적시에 소통되어야 한다
취약점으로 식별되지 않은 취약점에 대한 근거가 제공되어야 한다
대표 증적
[WP-08-05] 취약점 분석
9.4
Are processes established to manage identified vulnerabilities?
식별된 취약점이 잔여 리스크를 수용 가능한 수준으로 관리되어야 한다.
식별된 취약점이 잔여 리스크를 수용할 수 있는 근거에 기반해 관리되어야 한다
취약점 관리 조치의 책임 할당을 위한 계약 모델이 수립되어야 한다
대표 증적
[WP-08-06] 취약점 관리 증거
심사관은 결국 무엇을 확인하는가
24개 Control Question을 전부 읽고 나면 공통된 패턴이 보인다. 심사관이 확인하려는 것은 세 가지로 수렴한다.
⚠️ ENX VCS는 Secure Boot를 구현했는지 확인하는 심사가 아니다
특정 보안 기술의 적용 여부를 묻는 심사가 아니다. 심사관이 묻는 것은 "조직이 차량 사이버보안을 지속적으로 수행할 수 있는 체계를 갖추고 있는가"다. TARA를 작성했는지가 아니라, TARA가 실제 의사결정에 활용되고 있는지를 본다.
특정 보안 기술의 적용 여부를 묻는 심사가 아니다. 심사관이 묻는 것은 "조직이 차량 사이버보안을 지속적으로 수행할 수 있는 체계를 갖추고 있는가"다. TARA를 작성했는지가 아니라, TARA가 실제 의사결정에 활용되고 있는지를 본다.
💡 VCSA 24개 질문이 확인하는 세 가지
① 체계가 존재하는가 — 정책, 프로세스, 역할, 책임이 문서화되어 있는가
② 실제로 운영되는가 — 프로젝트에 적용되고, 회의 기록이 있고, 추적성이 있는가
③ 증명할 수 있는가 — Work Product, 기록, 보고서, 감사 결과가 존재하는가
① 체계가 존재하는가 — 정책, 프로세스, 역할, 책임이 문서화되어 있는가
② 실제로 운영되는가 — 프로젝트에 적용되고, 회의 기록이 있고, 추적성이 있는가
③ 증명할 수 있는가 — Work Product, 기록, 보고서, 감사 결과가 존재하는가
🔧 현업에서 느끼는 것들
Chapter 1과 9가 가장 많이 놓친다 — 개발 엔지니어 중심의 조직은 Chapter 5(개발)은 잘 준비하지만, Chapter 1(조직 거버넌스)의 경영진 commitment와 CSMS 범위 정의, Chapter 9(취약점 모니터링·이벤트 평가)는 프로세스 자체가 없는 경우가 많다. 특히 9.1의 "내·외부 소스 선정 및 트리거 정의"는 처음 듣는 조직도 있다.
Chapter 8이 예상외로 까다롭다 — 자신의 CSMS는 준비했는데 "우리 협력사의 보안 역량을 어떻게 평가하는가"는 처음 접하는 조직이 많다. CIAD(Cybersecurity Interface Agreement for Development)가 계약에 포함되어 있어야 한다는 요구도 준비가 안 된 곳이 대부분이다.
Chapter 3.3은 짧지만 가볍지 않다 — "고객에게 리스크를 소통하라"는 단 하나의 MUST 요구사항이지만, TARA 결과의 어떤 부분을 어떤 방식으로 고객에게 전달하고 있는지 증적이 없는 경우가 많다. 고객 소통은 이메일 한 통이 아니라 체계적인 프로세스여야 한다.
VCSA의 24개 질문은 다 달라 보이지만 결국 하나의 질문을 다양한 각도에서 확인한다.
"이 조직은 차량 사이버보안을 지속적으로 수행할 수 있는 체계를 갖추고 있는가?"
다음 편에서는 각 Control Question에 대응하는 실제 Audit Evidence — WP(Work Product) 목록을 챕터별로 완전히 정리한다.
핵심 요약
1
심사관은 VCSA 1.1을 기준으로 평가한다 — ISO/SAE 21434 원문이 아니다. 9챕터 24개 Control Question이 실제 심사 기준이다.
2
챕터 구성은 조직부터 운영까지 전체 생애주기를 커버한다 — Ch.1(거버넌스) → Ch.3(리스크) → Ch.5(개발) → Ch.7(운영) → Ch.9(지속적 취약점 관리)로 이어지는 흐름이다.
3
VCSA는 특정 기술 구현 여부를 묻지 않는다 — Secure Boot나 SecOC 적용 여부를 직접 확인하지 않는다. 보안 체계가 수립되어 있고, 운영되고 있으며, 증명 가능한지를 본다.
4
많이 놓치는 챕터는 1, 8, 9다 — 개발 엔지니어링 중심 조직은 Ch.5는 잘 준비하지만, 거버넌스(Ch.1), 공급망 관리(Ch.8), 취약점 모니터링(Ch.9)은 체계가 없는 경우가 많다.
5
각 Control Question에는 MUST 요구사항과 증적 예시가 있다 — 다음 편에서 챕터별 Work Product(WP) 목록을 완전히 정리한다.
반응형
'차량 사이버보안 > 규제 · 인증' 카테고리의 다른 글
| ENX VCS 심사는 어떻게 진행될까? — Organizational Check부터 라벨 발급까지 (1) | 2026.06.10 |
|---|---|
| 심사관은 어떤 증적을 요구할까? — ENX VCS Audit Evidence 완전 정리 (0) | 2026.06.09 |
| ENX VCS란 무엇일까?ISO/SAE 21434만으로는 부족했던 공급망 사이버보안 평가 (0) | 2026.06.09 |
| ENX VCS란 무엇일까? — ISO 21434만으로는 부족했던 공급망 사이버보안 평가 (0) | 2026.06.01 |
| 21434 V&V 공백, 8477이 채워줄까 — 현재 개발 현황과 실무자가 알아야 할 것 (0) | 2026.06.01 |