심사관은 어떤 증적을 요구할까? — ENX VCS Audit Evidence 완전 정리

ENX VCS 완전 정복 — 3편

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 완전 정리

NOW

4

예정

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

Organizational Check부터 라벨 발급까지

SOON

5

예정

우리 회사는 준비됐을까?

협력사를 위한 Self Assessment 가이드

SOON

심사 준비할 때 자주 듣는 말

"TARA는 다 했는데 왜 증적이 부족하다고 하는 건가요?"

"문서는 많은데 심사관이 증적이 없다고 합니다. 뭘 더 내야 하죠?"

"WP-09-02가 뭔가요? ISO/SAE 21434 문서랑 같은 건가요?"

"어떤 문서를 준비해야 하는지 목록이 있으면 좋겠어요."

2편이 "심사관이 무엇을 묻는가"였다면, 이번 편은 "심사관이 무엇을 보고 싶어하는가"다.

VCSA 1.1 파일에는 각 Control Question마다 Possible Evidence 컬럼이 있다. 이 글은 그 컬럼의 내용을 챕터별로 완전히 정리한다. VCSA 원문 기반이다.

---

먼저 — 증적(Evidence)은 문서(Document)가 아니다

심사 준비를 처음 하는 조직이 가장 많이 착각하는 부분이 있다. 증적을 문서와 동일하게 생각하는 것이다.

❌ 사이버보안 정책서를 제출하면 그게 증적이다

✅ 정책서 자체는 문서다. 증적은 "그 정책이 실제로 운영되고 있다는 기록"이다

심사관이 사이버보안 정책을 볼 때 정책 내용의 수준을 평가하는 것이 아니다. "이 정책이 경영진의 승인을 받았는가", "주기적으로 검토되고 개정 이력이 있는가", "실제 프로젝트에 적용되고 있는가"를 확인한다. 정책 문서는 출발점일 뿐이다.

💡 문서(Document) vs 증적(Evidence)

문서 — 정책서, 절차서, 프로세스 정의, 템플릿 → "무엇을 할 것이다"
증적 — 승인 기록, 검토 회의록, 교육 이력, 수행 결과물, 프로젝트 산출물 → "실제로 했다"

ENX VCS 심사관은 둘 다 요구한다. 하지만 증적이 없으면 아무리 좋은 문서도 부적합 판정을 받을 수 있다.

---

Work Product(WP) 체계 이해하기

VCSA의 Possible Evidence 컬럼에서 가장 자주 등장하는 형식이 있다. WP-XX-XX 형태의 Work Product 번호다. 이는 ISO/SAE 21434에서 정의한 산출물 참조 체계를 VCSA가 그대로 활용하는 것이다.

VCSA에 등장하는 WP 그룹 구조

WP-05
조직 관리

→

WP-06
프로젝트 계획

→

WP-09
개념 단계

→

WP-10~11
개발·확인

→

WP-12~14
양산·운영

WP-15는 TARA 관련 산출물 전체를 포함하는 별도 그룹. WP-08은 지속적 사이버보안 활동(취약점 모니터링 등) 산출물.

VCSA에 등장하는 WP 번호는 총 38개다. 이 글에서는 챕터별로 핵심 WP를 정리하고, 심사관이 각 WP에서 실제로 무엇을 확인하는지를 설명한다.

---

챕터별 Audit Evidence — VCSA 원문 기반

Ch.1

Organizational Cybersecurity — 조직 거버넌스

심사관의 시선 — "경영진이 실제로 사이버보안에 관여하는가? CSMS가 형식이 아니라 실제로 운영되는가?"

WP-05-01

Cybersecurity Policy, Rules and Processes

사이버보안 정책, 규칙, 프로세스 문서. 경영진 commitment 증거, 정책 핸드북, ISMS 인증서 포함.

WP-05-03

Evidence of Organization's Management Systems

ISMS 또는 CSMS 매뉴얼. CSMS 범위 정의와 경영진 검토 기록.

WP-05-04

Evidence of Tool Management

사이버보안 관련 도구 목록과 영향 분석 프로토콜. 도구가 보안에 부정적 영향을 주지 않음을 입증.

WP-06-01 / 02 / 03

Cybersecurity Plan / Case / Assessment Report

프로젝트별 사이버보안 계획, 케이스, 평가 보고서. 마일스톤별 업데이트 이력 포함.

추가로 요구되는 증적 (VCSA 원문 기반):

• DIA, RASIC Chart, 보고·에스컬레이션 메커니즘 포함 조직도
• P-D-C-A 프로세스 수립 증거 (Plan-Do-Check-Act 주기적 운영)
• 프로세스 표준 및 전체 관련 역할에 대한 사이버보안 측면 문서 (VDA Red Book 기준)

⚠️ 가장 많이 지적되는 부적합 패턴

정책 문서는 존재하지만 경영진 검토 기록이 없거나, CSMS 범위가 "전체 조직"으로만 모호하게 정의된 경우. 1.4 질문에서 Cybersecurity Case가 아예 없거나 프로젝트 계획과 연결되지 않는 경우도 자주 나온다.

Ch.2

Human Resources — 역량과 보안 문화

심사관의 시선 — "이 직원이 TARA를 수행할 자격이 있다는 근거가 있는가? 교육이 계획이 아닌 실제 이력으로 존재하는가?"

WP-05-02 (역량)

Evidence of Competence Management

역량 프로필, 역할별 교육 이력, 자격 수준 정의. 직무별 역량 요건이 충족되었음을 보여주는 문서.

WP-05-02 (교육)

Evidence of Awareness and Training Management

교육 계획, 참석 기록, 시험 결과. "계획"이 아니라 실제 수행된 교육의 기록이어야 한다.

WP-05-02 (개선)

Evidence of Continuous Improvement

교육 효과성 평가, 역량 Gap 분석, 개선 이력. 정기적으로 역량 수준을 점검하고 있음을 입증.

⚠️ 가장 많이 지적되는 부적합 패턴

"교육 계획서"만 있고 실제 수행 기록이 없는 경우. 특히 신규 입사자나 역할 변경자에 대한 교육 이력이 누락되는 경우가 많다. 역할별 역량 요건이 정의되지 않아 누가 어떤 교육을 받아야 하는지 체계가 없는 경우도 지적된다.

Ch.3

Risk Management — TARA와 리스크 처리

심사관의 시선 — "TARA 문서가 있는가"가 아니라 "TARA 결과가 실제 보안 목표와 요구사항으로 연결되는가?"

WP-15-01

Damage Scenarios

손상 시나리오 목록. UN R155 Annex 5의 applicable damage scenarios 반영 여부가 핵심.

WP-15-02

Assets with Cybersecurity Properties

CIA(기밀성·무결성·가용성) 속성이 할당된 자산 목록. 자산 정의의 적절성을 확인.

WP-15-03

Threat Scenarios

위협 시나리오 목록. UN R155 Annex 5 Part A 반영 여부 확인.

WP-15-04

Impact Ratings

안전·재무·운영·개인정보 카테고리별 영향 등급. 방법론의 일관성 확인.

WP-15-05

Attack Paths

공격 경로 분석 결과. 논리적 일관성과 완전성 확인.

WP-15-06 / 07

Attack Feasibility / Risk Value

공격 가능성 평가와 최종 리스크 값. 산정 방법론의 명확성 확인.

WP-09-02

TARA Results

전체 TARA 결과 산출물. WP-09-03(Cybersecurity Goals)과 연결이 끊기지 않아야 한다.

WP-09-03 / 04

Cybersecurity Goals / Claims

리스크 처리 결정에서 도출된 사이버보안 목표와 클레임. TARA와의 추적성이 핵심.

추가로 요구되는 증적:

• UN R155 Annex 5 Part A 위협 목록 반영 증거
• UN R155 Annex 5 Part B·C 리스크 완화 계획
• 리스크 처리 가이드라인 (Decision tree, Risk matrix, 에스컬레이션 경로 포함)
• 리스크 식별 방법론 가이드라인 (자산 카탈로그, 손상·위협 시나리오, 공격 경로 정의 방법)

⚠️ 가장 많이 지적되는 부적합 패턴

TARA는 수행했지만 UN R155 Annex 5 위협 시나리오가 반영되지 않은 경우. WP-15 시리즈가 존재하지만 WP-09-03(Cybersecurity Goals)과 추적성이 끊어진 경우. 3.3 질문에서 TARA 결과의 고객 소통 기록이 없는 경우.

Ch.4

Internal Assessments — 자체 점검 체계

심사관의 시선 — "조직은 스스로 문제를 발견할 수 있는가? 발견된 문제가 추적되고 개선되는가?"

WP-05-05

Organizational Cybersecurity Audit Report

내부 감사 수행 결과 보고서. 감사 결과가 기록·보존되어야 하며, 단순 체크리스트가 아닌 독립적 평가 기록이어야 한다.

추가로 요구되는 증적:

• 사이버보안 리스크 분석 피어 리뷰 기록
• 사이버보안 평가 보고서 (주기적 내부 감사)
• KPI 보고서 (사이버보안 리스크 관리 효과성)
• 관련 Work Product 주기 검토 기록
• Lessons Learned 및 시정조치 프로토콜 (부적합 이슈 추적 이력)

⚠️ 가장 많이 지적되는 부적합 패턴

내부 감사 절차는 있지만 독립적으로 수행된 기록이 없는 경우. 시정조치가 시작됐지만 완료 여부 추적이 안 되는 경우. 리스크 관리 효과성을 측정하는 KPI 자체가 정의되지 않은 경우.

Ch.5

Concept and Product Development — 개발 단계

심사관의 시선 — "TARA → Goal → Requirement → 설계 → Verification → Validation — 이 체인이 끊기지 않는가?"

WP-09-01

Item Definition

항목 기능, 경계, 운영 환경, 예비 아키텍처 정의. TARA의 출발점이 되는 산출물.

WP-09-05

Verification Report for Cybersecurity Goals

사이버보안 목표의 완전성·정확성·일관성 검증 보고서.

WP-09-06

Cybersecurity Concept

사이버보안 목표에서 도출된 개념. 요구사항이 어떤 목표로부터 나왔는지 추적 가능해야 한다.

WP-09-07

Verification Report of Cybersecurity Concept

사이버보안 개념 검증 보고서.

WP-10-04

Verification Report for Cybersecurity Specifications

사이버보안 사양 검증 보고서. 상위 추상화 수준과의 적합성 확인.

WP-10-05

Weakness Found During Product Development

개발 중 발견된 취약점 목록. 발견됐지만 기록이 없으면 오히려 부적합.

WP-10-06 / 07

Integration and Verification Specification / Reports

통합 및 검증 사양과 보고서. 컴포넌트 구현·통합 결과가 사양과 적합함을 입증.

WP-11-01

Validation Report

차량 레벨 사이버보안 목표 달성 확인 보고서. "불합리한 잔여 리스크 없음"이 결론에 있어야 한다.

ℹ️ 추적성(Traceability)이 이 챕터의 핵심이다

심사관은 WP-15-08(리스크 처리 결정) → WP-09-03(사이버보안 목표) → WP-09-06(사이버보안 개념) → 요구사항 → WP-10-04(검증) → WP-11-01(확인)으로 이어지는 추적이 가능한지 확인한다. 중간에 한 고리라도 끊기면 부적합이다.

⚠️ 가장 많이 지적되는 부적합 패턴

요구사항이 TARA 결과와 연결되지 않는 경우. WP-10-05(개발 중 발견 취약점)가 아예 없는 경우 — 실제로는 반드시 발견되는 것들인데 기록하지 않은 것이므로 부적합. WP-11-01(Validation Report)이 "검토 완료"라고만 쓰여 있고 실질적인 내용이 없는 경우.

Ch.6

Post-Development — 양산 릴리스와 생산 단계

심사관의 시선 — "개발에서 양산으로 넘어갈 때 보안 요구사항이 Production Control Plan에 실제로 반영됐는가?"

WP-06-04

Report on Release for Post-Development

양산 이전 릴리스 보고서. WP-06-01~03(계획·케이스·평가)과 함께 확인.

WP-12-01

Production Control Plan

생산 통제 계획. 사이버보안 요구사항이 생산 라인에 적용되고 있음을 입증하는 핵심 산출물.

⚠️ 가장 많이 지적되는 부적합 패턴

Production Control Plan이 있지만 사이버보안 요구사항(Key Provisioning, Secure Boot 설정 등)이 반영되지 않은 경우. WP-06-04(릴리스 보고서)가 없거나 사이버보안 평가가 완료됐다는 근거 없이 양산으로 넘어간 경우.

Ch.7

Operations Security — 운영·사고 대응·수명 종료

심사관의 시선 — "보안 사고가 실제로 발생했을 때 대응할 수 있는가? 그 대응 능력을 어떻게 입증하는가?"

WP-13-01

Cybersecurity Incident Response Plan

각 사이버보안 사고에 대한 대응 계획. 시정 조치, 이해관계자 소통 계획, 법적 의무 포함.

WP-14-01

Procedures to Communicate End of Cybersecurity Support

사이버보안 지원 종료 소통 절차. "언제, 어떻게 고객에게 알릴 것인가"가 정의되어야 한다.

추가로 요구되는 증적:

• 업데이트 프로세스 문서 및 관련 Work Product (OTA 프로세스 포함)
• 디지털 조사 프로세스 문서
• 조사 보고서 및 시정조치 프로토콜
• 사고 대응 보고서 / 취약점 스캐닝 보고서 (사후 검토 증적)
• 소비자 사용 정보 / 수리 정보 / 리스크 평가 방법론 피드백 메커니즘

⚠️ 가장 많이 지적되는 부적합 패턴

Incident Response Plan은 있지만 실제 수행 이력(Investigation Reports, Corrective Action 기록)이 없는 경우. 7.5 질문에서 Post Incident Response Review가 아예 수행되지 않은 경우. 폐차 관련 보안 요구사항(키·인증서 삭제 등) 절차가 없는 경우.

Ch.8

Supply Chain Relationships — 공급망 관리

심사관의 시선 — "당신 회사의 협력사가 사이버보안을 제대로 하고 있다는 것을 어떻게 확인하는가?"

RC-07-02

Record of Cybersecurity Capability

공급사 사이버보안 역량 기록. 개발·양산 후·거버넌스·품질·정보보안 등 전반의 "best practices" 증거 포함.

CIAD

Cybersecurity Interface Agreement for Development

개발 사이버보안 인터페이스 협약. 공급사와의 상호작용·의존성·책임 분배가 계약에 명시되어야 한다.

추가로 요구되는 증적:

• TISAX ISMS Label (공급사 정보보안 수준 증명)
• 공급사 사이버보안 역량 평가 기록 (지속적 활동 및 사고 대응 이력 포함)
• 사이버보안 목표·요구사항 공급사 소통 기록

⚠️ 가장 많이 지적되는 부적합 패턴

CIAD가 계약서에 없거나 형식적으로만 있는 경우. 공급사 사이버보안 역량을 "TISAX 라벨 있음"으로만 확인하고 VCS 관련 역량을 별도 평가하지 않은 경우. 사이버보안 목표·요구사항이 공급사에 실제로 전달됐다는 기록이 없는 경우.

Ch.9

Continual Cybersecurity Activities — 취약점 모니터링

심사관의 시선 — "신규 CVE가 나왔을 때 조직은 어떻게 인지하고, 어떻게 분류하며, 어떻게 대응하는가?"

WP-08-01

Sources of Selected Information

내·외부 정보 소스 목록. NVD, CVE, Auto-ISAC, CERT, 고객 통지 등. 우선순위 기준으로 관리되어야 한다.

WP-08-02

Triggers

사이버보안 정보를 이벤트로 분류하는 트리거 정의. "어떤 조건이면 이벤트로 처리한다"가 문서화되어야 한다.

WP-08-03

Cybersecurity Events from Triaged Information

분류된 사이버보안 이벤트 목록. 실제로 이벤트가 식별되고 기록된 이력이 있어야 한다.

WP-08-04

Weaknesses from Cybersecurity Events

사이버보안 이벤트로부터 식별된 취약점 목록. RASIC 테이블로 책임이 할당되어야 한다.

WP-08-05

Vulnerability Analysis

취약점 분석 결과. 취약점으로 분류되지 않은 경우 그 근거도 문서화되어야 한다.

WP-08-06

Evidence of Managed Vulnerabilities

취약점 관리 증거. 잔여 리스크 수용 근거와 고객 소통 기록 포함.

⚠️ 가장 많이 지적되는 부적합 패턴 — 협력사들이 가장 어려워하는 챕터

WP-08-01(정보 소스)은 있지만 WP-08-03(실제 이벤트 기록)이 없는 경우 — 모니터링 프로세스는 있지만 수행 기록이 없다. CVE 패치는 했지만 WP-08-05(취약점 분석) 문서가 없는 경우. WP-08-02(Trigger)가 너무 모호해서 무엇을 이벤트로 처리해야 하는지 실무자가 모르는 경우.

---

전체 Work Product 참조표

VCSA 1.1에 등장하는 WP 전체 목록이다. 심사 준비 시 체크리스트로 활용할 수 있다.

WP 번호	산출물명	관련 챕터
WP-05-01	Cybersecurity Policy, Rules and Processes	Ch.1
WP-05-02	Evidence of Competence / Training / Continuous Improvement	Ch.2
WP-05-03	Evidence of Organization's Management Systems	Ch.1
WP-05-04	Evidence of Tool Management	Ch.1
WP-05-05	Organizational Cybersecurity Audit Report	Ch.4
WP-06-01	Cybersecurity Plan	Ch.1, Ch.6
WP-06-02	Cybersecurity Case	Ch.1, Ch.6
WP-06-03	Cybersecurity Assessment Report	Ch.1, Ch.6
WP-06-04	Report on Release for Post-Development	Ch.6
WP-08-01	Sources of Selected Information (External/Internal)	Ch.9
WP-08-02	Triggers for Triage	Ch.9
WP-08-03	Cybersecurity Events from Triaged Information	Ch.9
WP-08-04	Weaknesses from Cybersecurity Events	Ch.9
WP-08-05	Vulnerability Analysis	Ch.9
WP-08-06	Evidence of Managed Vulnerabilities	Ch.9
WP-09-01	Item Definition	Ch.5
WP-09-02	TARA Results	Ch.3, Ch.5
WP-09-03	Cybersecurity Goals	Ch.3, Ch.5
WP-09-04	Cybersecurity Claims	Ch.3, Ch.5
WP-09-05	Verification Report for Cybersecurity Goals	Ch.5
WP-09-06	Cybersecurity Concept	Ch.5
WP-09-07	Verification Report of Cybersecurity Concept	Ch.5
WP-10-04	Verification Report for Cybersecurity Specifications	Ch.5
WP-10-05	Weakness Found During Product Development	Ch.5
WP-10-06	Integration and Verification Specification	Ch.5
WP-10-07	Integration and Verification Reports	Ch.5
WP-11-01	Validation Report	Ch.5
WP-12-01	Production Control Plan	Ch.6
WP-13-01	Cybersecurity Incident Response Plan	Ch.7
WP-14-01	Procedures to Communicate End of Cybersecurity Support	Ch.7
WP-15-01	Damage Scenarios	Ch.3
WP-15-02	Assets with Cybersecurity Properties	Ch.3
WP-15-03	Threat Scenarios	Ch.3
WP-15-04	Impact Ratings with Associated Impact Categories	Ch.3
WP-15-05	Attack Paths	Ch.3
WP-15-06	Attack Feasibility Ratings	Ch.3
WP-15-07	Risk Value	Ch.3
WP-15-08	Risk Treatment Decisions	Ch.3, Ch.5

---

🔧 현업에서 느끼는 것들

WP-10-05(개발 중 발견된 취약점)가 없으면 오히려 의심받는다 — 이 산출물이 없다는 것은 "개발 중 아무 취약점도 발견되지 않았다"는 의미인데, 실제로 그럴 수는 없다. 발견된 것들이 기록되지 않은 것으로 해석된다. 심사 전에 빠져 있는 WP를 채우려는 시도가 오히려 역효과를 낸다.

WP-08 시리즈가 가장 준비가 안 된 영역이다 — WP-08-01(소스 목록)은 그나마 만들기 쉽다. 문제는 WP-08-02(트리거), WP-08-03(이벤트 기록)이다. "NVD를 모니터링한다"는 프로세스가 있어도 실제로 트리거를 정의하고 이벤트를 식별해 기록한 이력이 없는 경우가 대부분이다. 이것은 프로세스 문서만으로 해결되지 않는다.

추적성(Traceability)이 결국 모든 것을 결정한다 — 각 WP가 독립적으로 존재하는 것만으로는 부족하다. WP-15(TARA) → WP-09-03(Goal) → 요구사항 → WP-10-04(Verification) → WP-11-01(Validation)의 체인이 끊기지 않아야 한다. 심사관은 임의의 위협 시나리오 하나를 골라서 이 체인을 끝까지 추적해본다. 어느 한 고리에서 연결이 끊기면 그것이 부적합이다.

심사관이 찾는 것은 잘 만든 문서가 아니다.

"이 조직이 실제로 사이버보안을 수행하고 있다는 기록" 이다.

Work Product는 그 기록의 형식이다. 형식보다 중요한 것은 그 기록이 실제 활동에서 만들어졌는가다.

핵심 요약

1

증적(Evidence)은 문서(Document)와 다르다 — 정책서는 문서다. 경영진 검토 기록, 승인 이력, 수행 결과물이 증적이다.

2

VCSA에 등장하는 WP는 총 38개 — WP-05(조직), WP-06(프로젝트), WP-08(지속적 활동), WP-09~11(개발), WP-12~14(양산·운영), WP-15(TARA)로 그룹화된다.

3

추적성이 결국 모든 것을 결정한다 — WP-15(TARA) → WP-09-03(Goal) → 요구사항 → WP-10(Verification) → WP-11(Validation) 체인이 끊기면 부적합이다.

4

가장 많이 놓치는 WP는 WP-08 시리즈와 WP-10-05 — 취약점 모니터링 수행 기록(WP-08-03)과 개발 중 발견된 취약점 기록(WP-10-05)이 없는 경우가 가장 많다.

5

WP는 "Possible Evidence"다 — 필수 목록이 아니다 — VCSA 컬럼 이름 그대로 "가능한 증적 예시"다. 동일한 증거 능력을 가진 다른 형태의 산출물로 대체 가능하다.

ENX_VCS VCSA AuditEvidence WorkProduct ISO/PAS5112 ISO/SAE21434 V-CSMS 자동차사이버보안인증 공급망보안 TARA CybersecurityCase 취약점관리