📄 2026.03.14 (Day 93) - 수탁사 점검 방법론 및 산출물 전반 검토


1. 핵심 개념 정리

수탁사 점검 프로젝트 전체 구조

# 핵심 개념 설명 실무/보안 관점
1 수탁사 점검 범위 개선방안 또는 보호대책 수립까지가 현실적 범위. 이행점검은 시간 제약상 제외 이행점검 미진행 시 “시간 제약으로 진행 불가” 라고 명확히 답변할 수 있어야 함
2 이행점검 점검 결과에 따른 조치 여부를 확인하는 단계. 보통 1분기 점검 후 2분기 이후 진행 실무에서도 동일 프로젝트 기간 내 이행점검까지 나가는 경우는 드묾
3 RFP 미작성 근거 리베로가 먼저 하랑항공에 수탁사 점검의 필요성을 제안한 시나리오 RFP 질문 시 “위탁사에 먼저 제안했다"는 답변으로 대응
4 요구사항 정의서 미작성 근거 컨설팅 프로젝트에서는 요구사항 정의서를 잘 작성하지 않음. RFP와 유사한 성격 면접에서 “다른 산출물에 시간을 더 투자했다"는 방향으로 답변
5 수탁사 목록 수탁사명, 위치, 담당자, 자체 개인정보 시스템 유무, 개인정보처리자 수, 처리 항목 등을 포함한 핵심 현황표 ISMS-P 인증기준 안내서 참고. 위탁사 대표에게 한 장으로 제출 가능한 수준으로 정리

산출물 체계 및 명명 규칙

# 핵심 개념 설명 실무/보안 관점
6 산출물 네이밍 규칙 (팀명)_사업명_(구분)_문서명_버전 형식. 버전은 1.0 이상 사업명이 길 경우 대표 키워드를 뽑아 사용. 파일명 변경 시 참조 경로도 함께 변경
7 위탁사 전체 결과보고서 수탁사 6개사 각각의 결과보고서를 취합한 종합 보고서. 팀 프로젝트 결과보고서와 별개 수탁사별 결과보고서 → 전체 종합 결과보고서 순으로 산출물 흐름 구성
8 위수탁 계약서 위탁자가 수탁자에게 요구하는 보안 요구사항이 필수 포함 항목 (ISMS-P 2.3.2 외부자 계약 시 보안 기준 적용) 표준계약서에 보안 요구사항을 가이드로 제공하는 방식
9 초안이라는 단어 산출물 문서명에 “초안"이라는 표현은 사용 금지 외부 제출 문서에 초안을 표기하는 것은 완성도에 대한 신뢰를 떨어뜨림
10 산출물 내 수치·날짜 검증 AI가 생성한 수치(과징금 비율, 통계 수치 등)는 반드시 사실 확인 필요 근거 없는 수치가 포함되면 PT 및 면접에서 신뢰도에 직격탄

ISMS-P 인증 체계 기초

# 핵심 개념 설명 실무/보안 관점
11 ISMS vs ISMS-P ISMS는 의무 인증, ISMS-P는 의무 아님 인증 범위 확인 시 인증기준 안내서를 반드시 참고
12 인증 주기 3년 1사이클: 최초 인증 → 사후 1차 → 사후 2차 → 갱신(갱신은 최초 수준으로 진행) 연 1회 심사. 갱신 시 최초 인증과 거의 동일한 강도로 진행됨
13 항목 수 101개 항목, KISA 기준 세부 확인 항목 약 330개, 금보원 기준 약 400개 쉴더스 내부에도 유사 문서 존재. 큰 흐름부터 접근하는 것이 효율적
14 2.3 외부자 보안 수탁사는 외부자에 해당. 수탁사 점검 시 2.3 기준을 주요 참고 기준으로 활용 2.3.2: 외부자 계약 시 보안. 위수탁 계약서 작성 기준으로 연계
15 PDCA 사이클 Plan → Do → Check → Act. 보안 관리체계 운영의 기본 프레임워크 현황 분석 → 위험 평가 → 보호대책 수립 흐름과 대응

2. 실습 내용 정리

활동 1: WBS 수정 검토

목표: WBS 구조의 논리적 흐름 및 명칭 오류 수정

주요 검토 및 수정 사항:

[ 행별 수정 내용 ]

- 11 ~ 17행  :  체계 수립 행정  >  프로젝트 준비
- 23 ~ 27행  :  WBS & 일정관리  >  WBS
- 28 ~ 64행  :  체크리스트  >  수탁자 체크리스트 수립
- 65 ~ 79행  :  계약서 · 협약서 · 제안요청서  >  수탁사 관리체계 수립
    - 계약서별 수탁사 맞춤 수정 항목 삭제  ( 계약서는 양식 수립까지 )
    - 제안요청서  >  사업제안서로 변경,  위치를 프로젝트 준비  >  사업수주로 이동
- 80 ~ 95행  :  보고서류  >  보고서 작성
- 96 ~ 109행  :  수행계획서는 상단으로 이동,  교육계획서는 별도 교육 자료로 분리
- 110 ~ 115행  :  인터뷰 항목 삭제  ( 인터뷰는 점검 방법 중 하나로 편입 )
- 116 ~ 131행  :  이행점검 섹션 유지  ( 시간 제약 사유로 미진행 처리 )
- 132 ~ 159행  :  수탁사 현황 섹션을 체크리스트 수립 이후로 배치
    - 순서  :  체크리스트 수립  >  수탁사 현황  >  수탁사 점검
- 기타  :  가중치 · 증적 · 양식 통일 행 삭제  ( 컨설팅에서 가중치 미사용 )
    - G열  ( 진척률 )  삭제 검토

[ 확인 항목 ]

- **WBS** 항목명과 수행계획서 · 사업제안서 항목명 일치 여부
- 수탁사별 점검 항목은 구분,  보고서 작성은 통합 처리
- **WBS** 가 세로로 길어지면 관리 및 가독성 저하  >  적절한 수준으로 압축
- 파일명 변경 시 별첨 · 참조 경로 동시 변경 필수

보안 인사이트:

  • WBS의 논리적 순서는 실제 컨설팅 업무 흐름과 일치해야 면접 답변 신뢰도가 높아짐
  • 이행점검 미수행은 결함이 아니라 프로젝트 범위 설정의 문제임을 명확히 인식
  • 항목명 불일치는 심사·PT 시 즉각적인 신뢰도 하락 요인

활동 2: 사업제안서 검토 및 수정

목표: 컨설팅 실무 기준에 맞춘 사업제안서 구조 및 내용 보완

주요 수정 사항:

[ 목차 구조 ]

- 서비스 제안서  >  사업 제안서
- 목차는 한 쪽으로 정렬  ( 표 형식 권장 )
- 주 리베로 소개  >  제안사 소개
- 1.4 위탁사 6개 관련 항목 삭제
- 3. 제안 서비스  >  사업 수행 내용 또는 사업 범위
- 3.7은 위험평가로 종결  ( 체계 삭제 )
- 5. 제안 예산 삭제  ( 예산서는 별도 제출,  기술 / 가격 평가 분리 )
- 6번 항목에 투입 인력 계획 통합
- 7.1  교육 및 지원으로 변경
- 7.2  보안 및 기밀 유지로 변경
- 8, 9번 통합  >  왜 리베로인가

[ 내용 수정 ]

1.1

- "집행"  >  "감독"으로 수정
- AI 생성 수치  ( 과징금 비율, 조사 증가 수치 등 )  반드시 사실 확인
- 규제 당국 조사 증가 수치  :  근거 자료 필요
- 재위탁 통제 공백 항목  :  RFP에 해당 내용이 명시되어 있다고 답변

1.2 법적 의무 및 위반 리스크 표 삭제 검토

1.3 표 4번 항목 삭제

1.4 위탁업무유형은 처리방침 참고, 민감도는 자체 판단

3.3 “수탁사의 개인정보보호 거버넌스 체계 전반” > “수탁사의 내부관리계획 등을 대상으로”

3.6 개인정보 생명주기 점검 > 개인정보 파기 절차 점검

3.7 점수 범위 기반 위험평가 > Y / N / P 기준으로 변경

3.8

- 수탁사별 점검 보고서  ( 부수 표기 삭제 )
- 법적 증빙 패키지  >  증빙 자료
- 개선 조치 계획서  >  개선 방안 보고서
- 임원 요약 보고 자료 삭제
- 종합 등급 평가 보고서  >  수탁사 점검 종합 보고서
- 주요내용 열 삭제,  제출 시기 열 추가  ( 날짜보다 "수탁사 점검 이후" 등 단계 기준 )
- 순서  :  수탁사별 점검 보고서  >  증빙 자료  >  개선 방안 보고서  >  수탁사 점검 종합 보고서
- 표 내 하이픈 단독 입력 금지

4. 수탁사별 맞춤형 점검 전략 > 점검 방안으로 변경

- 리스크  >  위험으로 통일
- 현장 점검 관련  :  암행 점검 표현 삭제,  주방 및 인도장 현장 점검으로 변경
- 야간 운영 시간대 현장 방문 삭제
- 예고 없이 점검원 방문 절대 금지  ( 컨설팅은 사전 협의 후 진행 )

6.3 투입 인력 계획

- PM은 상주 필수,  PL은 각 분야 리딩
- 구성  :  PM · 컨설턴트1  ( 관리체계 수립 )  /  PL · 컨설턴트2  ( 수탁사 점검진단 )
- 항공보안전문가는 현실적 필요 없음
- 자격 열  >  투입 일정으로 변경

7.1 역량 강화 교육 > 1년 무상 지원 형태, 비대면 1회 수준

- 이행점검은 서면 점검 형태  ( 2 ~ 3일 )로 진행

7.2 배경 조회 ( 형사 전과 확인 ) 항목 삭제

- 인적 보안  >  비밀유지서약서  +  단말 보안  ( 케이블 LOCK 등 )

활동 3: 수행계획서 및 체크리스트 검토

목표: 수행계획서 내용·형식 정합성 확인 및 체크리스트 산출물 보완

[ 수행계획서 수정 사항 ]

- 전체 사업명 통일  ( 첫 페이지 포함 )
- 수행과제 · 세부 수행 과제 내용을 **WBS** 와 일치
- 산출물 목록 **WBS** 와 일치
- 수행일정  :  WBS 수준으로 간소화,  담당자 이름 기재
- 점검 수행 일정  :  세부 수준 낮춰도 됨  ( WBS 참조 유도 )
- 별첨 파일명  :  사업명 키워드 뽑아 단축 기재
- 투입 인력 11명을 역할별로 배분하여 표기
- 보고 체계  :  일일보고 삭제  >  착수  >  주간  >  ( 중간 / 월간 )  >  종료 보고
- 소제목 구분 기호 누락 항목 보완
- 아라비아 숫자와 한글 번호  ( 가, 나, 다 )  혼용 금지  >  전 문서 통일

[ 체크리스트 수정 사항 ]

- 증적명 열 추가
- Y / P / N / NA  판정 열 추가
- 취약 항목은 빨간 글씨로 표시  ( 예  :  "실행계획이 누락되어" )
- 증적 자료 관리 방식
    - 옵션 A  :  체크리스트와 같은 폴더에 파일명  1.1.1 ~  형식으로 저장
    - 옵션 B  :  엑셀 새 시트 추가,  시트명을 항목번호  ( 예  :  1.1.1 증적명 )로 설정

[ 점검 계획서 수정 사항 ]

- 수탁사마다 별도 작성 불필요  >  하나로 통합
- 수탁사별 점검 일정 · 담당자를 표로 구분 기재
- 관련 근거  :  상위 개념으로 요약 정리
- 제목 수정 필요

3. 비교/분석 표

수탁사 점검 방법론 단계별 비교

단계 명칭 주요 활동 산출물
1단계 현황 분석 환경·요구사항 분석, 수행계획서 작성 수탁사 현황표, 수행계획서
2단계 사전 준비 점검기준 수립, 점검대상 선정, 체크리스트 배포 체크리스트, 점검 계획서
3단계 진단·평가 서면 점검, 현장 점검, 점검 결과 분석 증적 자료, 점검 결과 원본
4단계 대책 구현 결과 보고서 작성, 고객·수탁사 결과 확인, 개선·조치 계획 수립 수탁사별 결과보고서, 개선 방안 보고서, 종합 보고서
5단계 이행 이행점검 계획 수립, 이행점검, 이행점검 보고서 작성 이행점검 보고서 (본 프로젝트에서는 범위 외)

위험평가 방식 비교

항목 점수 기반 위험평가 Y/P/N 기반 위험평가
적용 대상 자산·위협·취약점 수치화가 가능한 환경 수탁사 개인정보 점검처럼 규정 준수 여부 판단 중심
장점 수치화된 우선순위 도출 가능 간결하고 직관적, 법령 준수 여부 판단에 적합
단점 점수 범위 설정의 근거 마련이 어려움, 수탁사 환경 적용에 한계 위험 수준의 세밀한 구분 어려움
본 프로젝트 3.7에서 점수 기반 제거 Y/P/N 기준으로 최종 결정

4. 심화 분석

면접 예상 질문 및 답변 구조

예상 질문 핵심 답변 포인트 주의사항
관련 법 뭐 알고 있어요? 개인정보보호법 중심 (제26조 위수탁, 제29조 안전조치), 정보통신망법, ISMS-P 연계 법 조문 번호까지 답변할 수 있으면 이상적
수탁사 점검은 어떤 절차로? 현황 분석 → 사전 준비 → 진단·평가 → 대책 구현 (1분 내외) 이행점검 시간 제약 사유 명확히 언급
위험관리란 무엇인가? 취약점·위협·위험 도출 → 위험전략 4가지 중 선택 → 즉시/단기/중기/장기 조치 계획 수립 위험전략: 수용·회피·전가·감소
RFP는 왜 없나요? 리베로가 먼저 하랑항공에 수탁사 점검을 제안한 시나리오로 답변 수동적 수주가 아닌 능동적 제안이라는 점 강조
요구사항 정의서는 왜 없나요? 컨설팅 프로젝트에서 요구사항 정의서는 잘 작성하지 않으며, 다른 산출물에 집중했다고 답변 RFP가 없는 상황과 연계 설명
수탁사 현황은 무슨 기준으로? 개인정보보호법, 안전조치 기준 등 법령 기반으로 현황 작성 (AI 활용, 팀 내 검토 과정 거침) 체크리스트 먼저인지, 현황 먼저인지 분위기 보고 답변

개인정보 점검 방법론 흐름도

[ 현황 분석 ]

- 환경 / 요구사항 분석
- 수행계획서 작성

[ 사전 준비 ]

- 점검기준 수립
- 점검대상 선정
- 점검일정 수립 및 체크리스트 배포

[ 진단 · 평가 ]

- 서면 점검
- 현장 점검
- 점검결과 분석

[ 대책 구현 ]

- 점검결과보고서 작성
- 고객 / 수탁사 결과 확인
- 보완 · 조치 계획 수립

[ 이행 ] ( 본 프로젝트 범위 외 - 시간 제약 )

- 이행점검 계획 수립
- 이행점검 실시
- 이행점검 보고서 작성

5. 실무/보안 적용

보안 전문가 관점 - 수탁사 점검 핵심 포인트

단계/유형 핵심 확인 포인트 관련 기준 대응 방안
관리적 점검 내부관리계획 수립 여부, 개인정보보호 책임자 지정 ISMS-P 2.3 외부자 보안 미수립 시 즉시 조치 권고, 개선 방안 보고서에 반영
기술적 점검 접근 통제, 암호화, 개인정보처리시스템 관리 개인정보보호법 제29조, 안전조치 기준 접근 통제 중대 결함은 위탁사 책임 연계 검토 필요
물리적 점검 보호구역·통제구역 설정, 출입 통제 현황 ISMS-P 물리적 보호 기준 현장 점검 사전 협의 필수 (암행 점검 금지)
파기 절차 개인정보 파기 절차 적정성, 전자적 파기 방법 개인정보보호법 제21조 파기 증적 자료 수집, 파기 방법 적정성 서면 확인
위수탁 계약 보안 요구사항 포함 여부 ISMS-P 2.3.2 표준계약서에 보안 요구사항 조항 삽입 가이드 제공

수탁사 점검 체크리스트 작성 기준

[ 체크리스트 열 구성 ]

- 항목번호  |  점검 항목  |  점검 내용  |  판정  ( Y / P / N / NA )  |  증적명  |  비고

[ 판정 기준 ]

- Y   =  양호  ( 기준 충족 )
- P   =  부분 양호  ( 일부 미충족 )
- N   =  취약  ( 기준 미충족,  빨간 글씨 표시 )
- NA  =  해당 없음

[ 증적 자료 관리 ]

- 파일명  :  항목번호 기준  ( 예  :  1.1.1 _ 접근통제정책 )
- 관리 방식  :  동일 폴더 내 보관  OR  엑셀 별도 시트  ( 시트명  :  항목번호 )

[ 체크리스트 작성 주의사항 ]

- 양호 시나리오  :  해당 법령 조항 명시 필수
- 취약 시나리오  :  구체적 결함 내용 기술  ( 예  :  "실행계획이 누락되어" )
- 수탁사별 판정 비율은 환경에 따라 상이하게 적용

산출물 최종 점검 기준

[ 모든 문서 공통 ]

- 아라비아 숫자와 한글 번호 혼용 금지  ( 전 문서 통일 )
- 산출물명에 "초안" 표현 금지
- AI 생성 수치 · 날짜 사실 확인 필수
- 강조 항목은 밑줄 또는 빨간 글씨로 명확히 표시
- 표 내 하이픈 단독 입력 금지
- 사업명 및 문서 제목 전체 통일  ( 모든 페이지 )

6. 배운 점 및 인사이트

새로 알게 된 점

  • 이행점검의 현실적 위치: 실무에서도 동일 프로젝트 기간 내 이행점검까지 수행하는 경우는 드물며, 이를 범위에서 제외하는 것은 결함이 아닌 합리적인 범위 설정임

  • 예산서 분리 제출 원칙: 제안서에는 예산을 포함하지 않고 별도로 제출하며, 기술 점수와 가격 점수는 분리 평가됨

  • 컨설팅 현장 점검 원칙: 예고 없는 방문이나 암행 점검은 실무에서 존재하지 않음. 모든 현장 점검은 사전 협의를 통해 진행

  • 위험평가 방식 선택: 수탁사 개인정보 점검에서 점수 기반 위험평가는 근거 마련이 어렵기 때문에 Y/P/N 기준이 더 적합

  • 산출물 정합성의 중요성: WBS, 수행계획서, 사업제안서 간 항목명·일정·담당자가 일치해야 PT 및 면접에서 신뢰도를 확보할 수 있음

이전 학습과의 연결고리

  • 체크리스트 Y/P/N/NA 기준과 연계: 이전에 확정한 판정 기준이 사업제안서 3.7의 위험평가 방식 변경과 직접 연결됨

  • ISMS-P 인증기준과 연계: 2.3 외부자 보안 기준이 수탁사 점검의 실질적 근거 기준으로 작동

  • 개인정보보호법 제26조·제29조: 위수탁 계약 및 안전조치 기준이 체크리스트 및 계약서 양식의 법적 근거로 반복 등장

실무 적용 아이디어

보안 전문가 관점:

  • 점검 방법론 내재화: 현황 분석 → 사전 준비 → 진단·평가 → 대책 구현 4단계를 체화하면 실제 컨설팅 투입 시 즉시 활용 가능

  • 산출물 네이밍 규칙 습관화: 실무에서도 문서 버전 관리와 파일명 규칙은 프로젝트 관리의 기본이므로 지금부터 적용

  • 면접 답변 구조화: 점검 방법론, 관련 법령, 위험관리 개념 3가지를 1분 내외로 구조화하여 언제든 설명할 수 있도록 준비

컨설팅 직무 관점:

  • 보고 체계 설계: 착수 → 주간 → 종료 보고의 단계별 보고 체계는 고객 커뮤니케이션 관리의 핵심

  • 산출물 간 정합성 유지: WBS · 수행계획서 · 제안서의 내용이 서로 맞물려야 전체 프로젝트의 완성도가 높아짐


7. Quick Reference

수탁사 점검 관련 주요 참고 사이트

[ 개인정보보호 관련 ]

- **ISMS-P** 인증  :  isms.kisa.or.kr
- 개인정보보호 포털  :  privacy.go.kr

[ 금융 보안 ]

- 금융보안원  :  fsec.or.kr

[ 커뮤니티 ]

- 보안인닷컴  ( 네이버 카페 )  :  보안 실무 정보 공유

[ 내부 참고 ]

- **ISMS-P** 인증기준 안내서  ( 인증 범위,  2.3 외부자 보안 등 )
- 위수탁 처리 안내서

핵심 개념 요약표

구분 항목 핵심 키워드 주요 내용 적용 방법
법령 개인정보보호법 제26조 위수탁 수탁사에 대한 위탁자의 관리·감독 의무 위수탁 계약서, 관리체계 수립
법령 개인정보보호법 제29조 안전조치 기술적·관리적·물리적 보호조치 의무 체크리스트 기준, 점검 항목
기준 ISMS-P 2.3.2 외부자 계약 보안 요구사항을 외부자 계약에 포함 위수탁 표준계약서 보안 조항
방법론 PDCA 관리체계 운영 Plan → Do → Check → Act 수탁사 점검 전체 프로세스
평가 Y/P/N/NA 점검 판정 양호/부분양호/취약/해당없음 체크리스트 판정 기준

산출물 최종 제출 전 체크리스트

문서 형식:

  • 전 문서 사업명 통일 확인
  • 아라비아 숫자 / 한글 번호 혼용 여부 확인
  • 산출물명에 “초안” 표현 여부 확인
  • 표 내 하이픈 단독 입력 여부 확인

내용 정확성:

  • AI 생성 수치·날짜 사실 확인 완료
  • 법령 조문 번호 정확성 확인
  • WBS·수행계획서·제안서 항목명 일치 확인
  • 담당자 이름 기재 완료

산출물 구성:

  • 체크리스트 증적명 열 추가
  • 체크리스트 Y/P/N/NA 판정 열 추가
  • 취약 항목 빨간 글씨 처리
  • 수탁사별 결과보고서 → 종합 보고서 흐름 완성

8. 트러블슈팅

문제 원인 해결 방법
WBS와 수행계획서 항목명 불일치 각자 작성하면서 명칭을 다르게 표기 WBS를 기준 문서로 확정 후 수행계획서·제안서 일괄 수정
AI 생성 수치의 정확성 문제 AI가 부정확한 통계·수치·연도를 생성 과징금 비율, 조사 통계 등은 PIPC 공식 발표자료 또는 법령 원문으로 검증
점검 계획서 수탁사별 중복 작성 점검 계획서를 수탁사마다 별도로 만들어 분량 증가 하나로 통합하고 수탁사별 일정·담당자만 표로 구분 기재
사업제안서 예산 항목 포함 컨설팅 제안서 작성 기준 미숙지 예산서는 별도 문서로 분리 제출. 제안서에는 투입 인력 계획만 포함
보고 체계에 일일보고 포함 실무 보고 체계 미숙지 착수 → 주간 → (중간/월간) → 종료 보고 체계로 수정

Today’s Insight:

오늘은 사업제안서, WBS, 수행계획서, 체크리스트, 점검 계획서, 결과보고서까지 프로젝트 전체 산출물을 한 번에 훑으며 실무 기준과의 간극을 좁히는 작업을 진행했다. 특히 컨설팅 현장에서는 “하지 않는 것"에도 명확한 이유가 있어야 한다는 점이 반복해서 강조됐다. 이행점검 미수행, 요구사항 정의서 미작성, 암행 점검 배제 모두 “모른 것"이 아니라 “범위 설정과 실무 관행의 판단"임을 명확히 인식해야 면접에서도 흔들리지 않는다. AI로 작성한 내용의 수치와 법령은 반드시 원문으로 검증하는 습관이 실무 신뢰도의 기본이며, 모든 산출물 간 항목명과 일정이 정합성을 갖출 때 비로소 완성도 있는 프로젝트 결과물이 된다.