고객사 보안 점검 대응 가이드: 체크리스트·증빙 준비법

고객사가 보안 점검표를 보내왔다면 원칙은 두 가지입니다. 모든 항목에 사실대로 답하고, 답마다 확인할 수 있는 증빙을 붙이며, 미흡한 항목에는 '언제까지 무엇을 하겠다'는 개선 계획을 함께 적는 것입니다. 점검 담당자는 완벽한 회사를 찾는 게 아닙니다. 위험을 알고 관리하는 회사인지를 봅니다. "예"로만 채운 점검표보다 "부분 이행, 12월 말 완료 예정"이 섞인 점검표가 오히려 신뢰를 얻는 경우가 많습니다.

준비는 다섯 가지 질문 유형만 기준으로 잡으면 됩니다. 접근통제, 암호화, 접속기록, 취약점 점검 이력, 사고 대응 체계입니다. 대기업·공공기관 점검표는 대부분 개인정보보호위원회의 「개인정보의 안전성 확보조치 기준」과 ISMS-P 항목을 바탕으로 만들어지므로, 이 다섯 영역에 대한 답과 증빙이 있으면 질문의 대부분을 감당할 수 있습니다.

이 글은 보안 담당자가 따로 없는 스타트업의 개발자나 CTO가 처음 점검표를 받았을 때 바로 쓸 수 있도록, 유형별 답변 요령과 증빙 목록, 개선 계획 작성법을 정리했습니다.

고객사는 왜 보안 점검을 요구하나

고객사의 개인정보를 처리하거나 고객사 시스템과 연동하면 법적으로든 계약상으로든 우리 회사는 수탁사나 공급망의 일부가 됩니다. 개인정보 처리를 위탁한 쪽은 수탁자를 교육하고 처리 현황을 점검해야 할 관리·감독 책임을 집니다. 그래서 고객사 보안팀은 계약 전이나 매년 정기적으로 점검표를 보내고 증빙을 받아 둡니다.

받는 쪽에서 알아 둘 점은 이렇습니다.

점검표 항목 대부분은 고객사가 자기 감사에 대비해 남기는 기록입니다. 그래서 증빙 형태(캡처, 문서, 로그 샘플)를 꼼꼼히 봅니다.
2023년 개인정보 보호법 개정 이후 정보통신서비스 제공자용 기준이 따로 있던 체계가 「개인정보의 안전성 확보조치 기준」 하나로 통합됐습니다. 오래된 점검표에 예전 고시 용어가 남아 있어도 당황하지 말고 현행 기준으로 답하면 됩니다.
점검표 자체가 법령은 아닙니다. 우리 서비스와 관련 없는 항목(예: 자체 전산실 출입통제)은 "해당 없음"이라 쓰고 이유를 한 줄 덧붙이면 됩니다. 예: "AWS 서울 리전 사용, 물리 보안은 클라우드 사업자 책임 범위".

답변 원칙: 사실대로, 증빙과 함께, 계획을 붙여서

답은 항목마다 아래 네 가지 상태 중 하나로 정리하면 일관성이 생깁니다.

상태	쓰는 경우	함께 낼 것
이행	운영 환경에 실제 적용되어 있음	설정 캡처, 정책 문서, 로그 샘플
부분 이행	일부 시스템에만 적용, 또는 절차는 있으나 기록이 없음	적용 범위 설명 + 개선 계획
미이행	아직 없음	개선 계획(담당자·기한·방법)
해당 없음	구조상 적용 대상이 아님	사유 한 줄

가장 피해야 할 것은 "예"라고 답하고 증빙을 못 내는 상황입니다. 후속 질의에서 드러나면 그 항목 하나가 아니라 점검표 전체의 신뢰가 떨어집니다. 확신이 없다면 "부분 이행"으로 답하고 범위를 설명하는 편이 안전합니다.

증빙을 만들 때 실무 팁도 있습니다.

캡처에는 날짜와 대상 시스템이 보이게 합니다. 콘솔 URL이나 계정 ID 등 민감한 부분은 가리되, 어떤 화면인지는 알아볼 수 있어야 합니다.
문서는 "작성일, 승인자, 개정 이력"이 있는 형태로 만듭니다. 한 장짜리 정책이라도 버전 관리가 되어 있으면 인정받기 쉽습니다.
로그 샘플은 개인정보를 마스킹해서 제출합니다. 원본 로그를 그대로 보내는 일 자체가 점검 감점 요인이 될 수 있습니다.

유형 1: 접근통제와 권한 관리

자주 받는 질문은 이렇습니다. "개인정보처리시스템 접근 권한을 업무별로 차등 부여하는가", "퇴사자 권한을 즉시 회수하는가", "외부에서 접속할 때 추가 인증을 쓰는가", "권한 부여·변경·말소 기록을 보관하는가".

사실대로 답하는 예시

부분 이행. 관리자 페이지는 역할 기반 권한(최고관리자/CS/조회 전용)으로 운영하며, AWS 콘솔과 관리자 페이지 모두 MFA를 적용했습니다. 다만 권한 변경 이력은 현재 슬랙 승인 메시지로만 남고 있어, 11월 30일까지 관리자 페이지 내 권한 변경 로그 테이블을 도입할 예정입니다.

준비할 증빙

역할별 권한 매트릭스(역할 × 메뉴/기능 표)
클라우드 콘솔·관리자 페이지 MFA 설정 화면
최근 퇴사자 계정 비활성화 기록(날짜 포함)
권한 변경 이력 샘플

개발자 입장에서 흔한 빈틈은 권한 검사가 화면에만 있고 API에는 없는 경우입니다. 점검 담당자가 "조회 전용 계정으로 엑셀 다운로드 API를 직접 호출하면 어떻게 되느냐"고 물으면 답할 수 있어야 합니다.

// 취약: 메뉴만 숨기고 API는 로그인 여부만 확인
app.get("/admin/api/users/export", requireLogin, async (req, res) => {
  const rows = await db.user.findMany();
  res.send(toCsv(rows));
});

// 개선: 서버에서 역할을 확인하고, 다운로드 행위를 기록
app.get(
  "/admin/api/users/export",
  requireLogin,
  requireRole(["SUPER_ADMIN"]),
  async (req, res) => {
    const rows = await db.user.findMany({ select: exportFields });
    await auditLog.write({
      actorId: req.user.id,
      action: "USER_EXPORT",
      targetCount: rows.length,
      ip: req.ip,
      reason: req.query.reason ?? null,
    });
    res.send(toCsv(rows));
  }
);

관리자 화면 전반을 점검하려면 관리자 페이지 보안 체크리스트를 같이 보면 좋습니다.

유형 2: 암호화

질문은 대체로 세 갈래입니다. "비밀번호를 일방향 암호화하는가", "고유식별정보·계좌번호 등 중요 정보를 저장할 때 암호화하는가", "전송 구간에 TLS를 적용하는가".

답변 요령

알고리즘과 적용 위치를 구체적으로 씁니다. "암호화함"보다 "비밀번호는 bcrypt(cost 12), 계좌번호는 AES-256-GCM으로 애플리케이션 레벨 암호화, 키는 AWS KMS 보관"이 훨씬 설득력 있습니다.
DB 스토리지 암호화(디스크 암호화)만 켜 둔 상태라면 그렇게 적습니다. 컬럼 단위 암호화를 묻는 항목에는 "부분 이행"이 정확한 답입니다.
주민등록번호처럼 수집 자체가 제한되는 정보는 "수집하지 않음"이 가장 좋은 답입니다.

# 취약: 빠른 해시를 솔트 없이 사용
import hashlib
password_hash = hashlib.sha256(password.encode()).hexdigest()

# 개선: 비밀번호 전용 해시 함수 사용
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

준비할 증빙: 암호화 대상 정보 목록(필드명·알고리즘·키 관리 방식), 해시 처리 코드 일부 또는 설계 문서, TLS 설정 확인 결과(SSL 점검 도구 결과 캡처), KMS 키 정책 화면.

유형 3: 접속기록 보관과 점검

접속기록은 스타트업이 가장 자주 "미이행"을 받는 영역입니다. 「개인정보의 안전성 확보조치 기준」은 개인정보처리시스템 접속기록을 1년 이상 보관하도록 하고, 5만 명 이상의 정보주체 개인정보를 처리하거나 고유식별정보·민감정보를 처리하는 시스템 등은 2년 이상 보관하도록 정하고 있습니다. 또한 접속기록과 개인정보 다운로드를 확인·점검하는 주기와 방법, 사후조치를 내부 관리계획에 정해 이행하고, 기록이 위·변조되지 않게 보관해야 합니다.

여기서 말하는 접속기록은 웹 서버 액세스 로그가 아닙니다. 누가(계정), 언제, 어디서(IP), 어떤 정보주체의 정보를, 무엇을 했는지(조회·수정·다운로드) 가 남아야 합니다.

{
  "actor_id": "admin_17",
  "accessed_at": "2026-10-27T14:03:11+09:00",
  "source_ip": "203.0.113.24",
  "subject": "user:58213",
  "action": "VIEW_DETAIL",
  "fields": ["name", "phone"],
  "request_id": "req_9f2c"
}

준비할 증빙

접속기록 샘플(마스킹 처리)과 필드 설명
보관 기간 설정 화면(예: 로그 버킷 수명 주기 정책, 객체 잠금 설정)
내부 관리계획 중 접속기록 점검 주기·방법 부분
최근 점검 결과 기록(대량 조회·다운로드 확인 내역)

아직 없다면 개선 계획에 "관리자 페이지 감사 로그 테이블 추가 → 별도 스토리지로 일 단위 내보내기 → 쓰기 전용 권한 분리"처럼 단계를 쪼개 적으면 됩니다. 구현 항목 전반은 개인정보 안전성 확보조치 기준, 개발자가 구현할 항목에 정리해 두었습니다.

유형 4: 취약점 점검 이력

"최근 1년 내 취약점 점검이나 모의해킹을 받았는가", "결과와 조치 내역을 제출하라"는 질문입니다.

받은 적이 없을 때 정직하게 답하는 법

미이행. 외부 전문기관 점검 이력은 없습니다. 현재 자체 점검으로 의존성 취약점 스캔(CI 단계)과 OWASP ASVS Level 1 기준 자가 점검을 수행하고 있으며, 2027년 1분기 중 외부 웹 취약점 진단을 받고 결과 요약과 조치 내역을 공유하겠습니다.

OWASP ASVS는 웹 애플리케이션·API 보안 요구사항을 레벨별로 정리한 표준입니다. 현재 버전은 5.0.0이며 항목을 v5.0.0-챕터.섹션.요구사항 형식으로 인용하도록 권장합니다. 자가 점검 결과를 낼 때 "ASVS v5.0.0 L1 기준, 해당 항목 중 몇 개 충족"처럼 기준을 명시하면 점검 담당자가 범위를 이해하기 쉽습니다. 다만 ASVS는 인증 제도가 아니므로 "ASVS 인증"이라고 쓰지 않도록 주의합니다.

제출 자료를 만들 때

보고서 원문 전체보다 요약본(점검 기관, 기간, 범위, 위험도별 발견 건수, 조치 완료 여부)을 먼저 냅니다. 원문은 상세 공격 경로가 담겨 있어 NDA 체결 후에만 공유하는 것이 일반적입니다.
조치하지 못한 항목이 남아 있다면 숨기지 말고 위험 수용 사유나 조치 예정일을 적습니다.

어떤 점검을 받을지 고민된다면 모의해킹과 취약점 진단 차이를 참고해 범위를 정하면 됩니다.

유형 5: 사고 대응 체계

"보안 사고 발생 시 대응 절차가 있는가", "고객사에 언제, 어떻게 통보하는가", "비상 연락망이 있는가"를 묻습니다.

최소한 갖출 것

한두 쪽 분량의 사고 대응 절차서: 탐지 → 초기 차단 → 영향 범위 파악 → 신고·통지 → 재발 방지
역할 지정: 사고 책임자(보통 CTO), 대외 커뮤니케이션 담당, 기록 담당
고객사 통보 기준: "개인정보 유출이 의심되는 경우 인지 후 ○시간 이내 계약서상 담당자에게 유선·이메일 통보". 이 시간은 고객사 계약 조건과 맞춰야 합니다.
연 1회 이상 모의 훈련 또는 탁상 훈련 기록

준비할 증빙: 절차서(버전·승인일 포함), 비상 연락망, 훈련 기록 또는 실제 장애 회고 문서. 실제 장애 회고(postmortem)도 대응 체계가 작동한다는 좋은 증빙이 됩니다.

미흡 항목에 개선 계획을 붙이는 법

개선 계획은 구체적이고, 기한이 있고, 담당자가 있어야 합니다. 아래 형식을 그대로 쓰면 됩니다.

| 항목 | 현재 상태 | 개선 내용 | 담당 | 완료 예정 | 중간 산출물 |
|---|---|---|---|---|---|
| 접속기록 보관 | 미이행 | 관리자 조회·다운로드 감사 로그 구축, 별도 버킷 2년 보관 | CTO 김OO | 2026-12-15 | 로그 샘플, 버킷 정책 캡처 |
| 외부 취약점 진단 | 미이행 | 웹·API 외부 진단 1회 실시 | CTO 김OO | 2027-03-31 | 결과 요약본 |
| 권한 변경 이력 | 부분 이행 | 관리자 권한 변경 로그 테이블 도입 | 백엔드 이OO | 2026-11-30 | 로그 화면 캡처 |

판단 기준도 정리해 둡니다.

우선순위: 개인정보 대량 노출로 이어질 수 있는 항목(접근통제, 다운로드 기록, 관리자 MFA)부터 앞에 둡니다.
기한: 지킬 수 있는 날짜만 씁니다. 기한을 넘기면 점검표 전체 신뢰에 영향을 줍니다. 늦어질 것 같으면 먼저 연락해 일정을 다시 합의합니다.
보완 통제: 당장 못 하는 항목은 임시 조치를 함께 적습니다. 예: "감사 로그 구축 전까지 엑셀 다운로드 기능을 최고관리자만 쓸 수 있게 제한".

자주 묻는 질문

보안 인증(ISMS-P 등)이 없으면 계약이 어려운가요?

고객사와 데이터 규모에 따라 다릅니다. 많은 경우 인증이 없어도 점검표와 증빙, 개선 계획으로 계약이 진행됩니다. 인증을 계약 조건으로 명시했는지 먼저 확인하고, 그렇지 않다면 점검표에 성실히 답하는 데 집중하세요.

점검표에 모르는 용어가 나오면 어떻게 하나요?

추측해서 "예"라고 답하지 말고 고객사 담당자에게 질문 의도를 물어보세요. 질의 자체는 감점 요인이 아닙니다. 점검 의도를 알고 나면 "해당 없음"으로 정리되는 항목도 꽤 많습니다.

증빙을 위해 소스코드나 인프라 정보를 다 보내야 하나요?

아닙니다. 설정 화면 캡처, 정책 문서, 마스킹한 로그 샘플이면 충분한 경우가 대부분입니다. 상세 보고서나 아키텍처 문서는 NDA를 맺은 뒤 열람 방식으로 공유하는 방법을 제안하세요.

정리

고객사 보안 점검은 "완벽함"이 아니라 "위험을 알고 관리하는지"를 봅니다. 사실대로 답하고 증빙을 붙이세요.
접근통제, 암호화, 접속기록, 취약점 점검 이력, 사고 대응 체계 다섯 영역의 답변과 증빙 폴더를 미리 만들어 두면 다음 점검부터는 금방 끝납니다.
미흡한 항목은 담당자·기한·중간 산출물이 있는 개선 계획과 임시 보완 통제를 함께 내면 충분히 설득할 수 있습니다.
어디서부터 손대야 할지 판단이 어렵다면 무료 분석 신청으로 현재 상태를 먼저 점검받아 볼 수 있습니다.