B2B SaaS security questionnaire·vendor review evidence 체크리스트 2026, SSO·audit log·data retention·support access 증거를 enterprise sales와 고객 보안 검토에 맞추기 전 확인할 기준
B2B SaaS security questionnaire·vendor review evidence 체크리스트 2026, SSO·audit log·data retention·support access 증거를 enterprise sales와 고객 보안 검토에 맞추기 전 확인할 기준
B2B SaaS가 enterprise 고객에게 팔리기 시작하면 제품 데모보다 먼저 security questionnaire, vendor review, security evidence 요청이 들어옵니다. 고객은 "SSO가 되나요", "audit log를 export할 수 있나요", "데이터 삭제와 보존 상태를 어떻게 확인하나요", "지원 담당자가 고객 계정에 접근하면 기록이 남나요"처럼 운영 증거를 묻습니다.
이 글은 인증 취득이나 보안 보증을 약속하는 글이 아닙니다. 고객 보안 검토에 답하기 전, SaaS 운영팀이 SSO, SCIM, audit log, data retention, backup restore, support access, CRM follow-up 증거를 어디에 두고 어떤 최신성으로 관리할지 정리하는 체크리스트입니다.
직전 글인 B2B SaaS support impersonation·customer access 감사 체크리스트는 고객지원 접근 세션을 다뤘습니다. 이번 글은 그 접근 로그와 B2B SaaS 데이터 보존·backup restore 요청 추적 체크리스트, B2B SaaS 감사 로그·관리자 변경 추적 체크리스트, B2B SaaS enterprise SSO·SCIM 권한 동기화 체크리스트를 고객 보안 검토 답변 묶음으로 정리하는 흐름에 초점을 둡니다.
security questionnaire는 답변 문서가 아니라 증거 인덱스입니다
security questionnaire를 영업팀의 문답 파일로만 보면 매번 답변이 달라집니다. 더 안정적인 구조는 질문별로 원본 증거 위치, 담당자, 최신 확인일, 고객에게 공유 가능한 요약을 붙이는 것입니다.
| 구분 | 운영 질문 |
|---|---|
| 질문 ID | 고객 질문을 내부 기준 항목으로 매핑했는가 |
| evidence owner | 답변 책임자가 sales인지 security ops인지 product ops인지 정했는가 |
| source system | admin console, ticket, audit log, docs 중 어디가 원본인가 |
| freshness | 마지막 확인일과 다음 리뷰 예정일이 있는가 |
| customer-safe summary | 고객에게 보여줄 수 있는 요약과 내부 전용 메모를 나눴는가 |
| exception status | 미지원, 부분 지원, 로드맵, 별도 계약 항목을 분리했는가 |
핵심은 "예" 또는 "아니오"를 빨리 쓰는 것이 아닙니다. 고객 질문이 반복될 때 같은 증거에서 같은 답변이 나오게 만드는 것입니다.
질문 유형을 제품 기능, 운영 증거, 고객 설정으로 나눕니다
enterprise vendor review에서는 서로 다른 질문이 한 문서에 섞입니다. SSO 지원 여부는 제품 기능이고, audit log 보관과 export는 운영 증거이며, 고객 admin이 직접 켤 수 있는 설정은 고객 설정입니다. 이 셋을 분리하지 않으면 답변 품질이 흔들립니다.
| 질문 유형 | 예시 질문 | 답변 기준 |
|---|---|---|
| product capability | SSO, SCIM, role mapping을 지원하는가 | 기능 상태와 플랜 조건 |
| operational evidence | audit log, support access, backup restore 기록이 남는가 | 원본 로그와 export 가능성 |
| customer configuration | 고객 admin이 접근 권한을 직접 관리할 수 있는가 | admin console 화면과 설정 가이드 |
| data handling state | export, deletion, retention 상태를 확인할 수 있는가 | ticket, job status, customer notice |
| sales exception | 특정 고객만 예외 기능을 요구하는가 | 예외 승인자와 만료일 |
답변을 이렇게 나누면 "지원합니다"라는 한 문장 대신 어떤 기능이 제품에 있고, 어떤 증거가 운영 로그에 있고, 어떤 값은 고객 설정에 달려 있는지 설명할 수 있습니다.
SSO와 SCIM 증거는 설정 화면보다 변경 이력을 봅니다
SSO와 SCIM은 보안 질문서에서 가장 자주 나오는 항목입니다. 단순히 SSO가 가능하다는 문장보다 중요한 것은 어떤 IdP, 어떤 role mapping, 어떤 deprovision 이벤트, 어떤 admin change가 남는지입니다.
원문: 원문기사 보기
SSO·SCIM 증거 묶음에는 아래 항목을 두는 편이 좋습니다.
| 항목 | 확인할 값 |
|---|---|
sso_enabled_state |
enabled, disabled, enforced |
idp_provider |
Okta, Microsoft Entra ID, Google Workspace 등 |
scim_sync_status |
active, paused, failed, not_configured |
role_mapping_source |
IdP group, workspace role, manual override |
last_admin_change_at |
최근 설정 변경 시각 |
last_deprovision_event_at |
최근 권한 회수 이벤트 |
audit_export_available |
고객 또는 내부 export 가능 여부 |
이 항목은 기존 enterprise SSO·SCIM 권한 동기화 체크리스트와 같은 기준으로 관리하면 좋습니다.
audit log 답변은 export 가능성과 필드 범위를 같이 적습니다
고객이 audit log를 묻는 이유는 "기록이 있습니다"라는 답만 들으려는 것이 아닙니다. 누가, 언제, 어떤 계정에서, 어떤 설정을, 어떤 ticket 근거로 바꿨는지 확인할 수 있는지를 보려는 것입니다.
원문: 원문기사 보기
원문: 원문기사 보기
security questionnaire에는 아래처럼 답변 단위를 나눌 수 있습니다.
| 답변 항목 | 예시 |
|---|---|
| log coverage | login, admin change, billing admin, support access, export job |
| actor field | customer_admin, internal_admin, support_agent, system |
| target field | workspace, user, role, integration, billing setting |
| reason link | source ticket, customer approval, internal case |
| export format | CSV, API, admin console export |
| customer visibility | customer admin view, support-provided summary, internal only |
| review cadence | monthly, quarterly, after incident-like exception |
여기서 "incident-like exception"은 사고 판정을 뜻하지 않습니다. ticket 없는 접근, 종료 없는 support access, reason code 없는 admin change처럼 평소 흐름에서 벗어난 운영 예외를 말합니다.
data retention 답변은 보존 기간 단정 대신 상태 증거로 제한합니다
데이터 보존 질문은 민감해지기 쉽습니다. 이 글에서는 보존 기간이나 의무를 단정하지 않습니다. 운영 답변은 고객 계정의 데이터 상태, export job, deletion request, retention hold label, backup restore request가 어떤 시스템에서 추적되는지에 집중해야 합니다.
| 항목 | 고객에게 설명할 수 있는 상태 |
|---|---|
data_export_request |
requested, processing, completed, failed |
deletion_request_status |
received, verified, scheduled, completed, blocked |
retention_label |
normal, hold_active, pending_review |
backup_restore_request |
none, requested, dry_run, completed, failed |
customer_notice |
prepared, sent, acknowledged |
linked_ticket |
support ticket 또는 customer case ID |
이 구조는 고객 데이터 export·삭제 요청 추적 체크리스트와 backup restore 요청 추적 체크리스트에서 다룬 필드를 고객 보안 검토 답변으로 묶는 방식입니다.
support access 증거는 고객 문의와 세션 로그가 함께 있어야 합니다
enterprise 고객은 지원 담당자가 자기 계정에 접근할 수 있는지, 접근하면 기록이 남는지, 고객에게 안내되는지 묻습니다. 답변에는 기능명보다 운영 증거가 필요합니다.
원문: 원문기사 보기
support access evidence에는 아래 필드를 두면 답변이 안정됩니다.
| 필드 | 설명 |
|---|---|
source_ticket_id |
고객 문의 또는 내부 case와 연결 |
access_mode |
view_only, impersonation, admin_assisted_action |
reason_code |
billing_issue, sso_scim_setup, restore_request_support 등 |
customer_approval_status |
requested, approved, denied, expired |
session_ttl_minutes |
세션 제한 시간 |
ended_at |
종료 시각 |
post_access_notice_status |
고객 안내 상태 |
이 값이 있으면 "지원 접근이 가능한가"라는 질문에 "가능합니다"로 끝나지 않고, 언제 어떤 조건에서 어떤 기록이 남는지 설명할 수 있습니다.
CRM에는 보안 답변 원문이 아니라 영업 후속 상태만 남깁니다
security questionnaire 원본 답변, 고객 내부 질문, 계정별 예외 사유를 CRM에 그대로 복제하면 관리 범위가 넓어집니다. CRM은 영업 후속 상태와 갱신 리스크를 보는 곳으로 제한하는 편이 좋습니다.
원문: 원문기사 보기
CRM 필드는 아래 정도로 충분합니다.
| CRM 필드 | 예시 값 |
|---|---|
security_review_status |
not_started, in_progress, answered, waiting_customer, exception_review |
questionnaire_due_at |
고객 제출 마감일 |
evidence_owner |
sales_ops, security_ops, product_ops |
open_exception_count |
미해결 예외 수 |
customer_safe_summary_ready |
yes, no |
last_evidence_reviewed_at |
최근 증거 확인일 |
renewal_risk_from_security_review |
none, low, medium, high |
CRM에는 다음 액션만 남기고, 원본 evidence는 ticket, admin console, audit log, 내부 문서 저장소에서 관리하는 편이 낫습니다.
고객에게 줄 답변과 내부 메모를 분리합니다
좋은 vendor review 운영은 고객에게 보여줄 수 있는 답변과 내부 판단 메모를 분리합니다. 고객에게는 제품 기능, 설정 방법, 로그 범위, export 가능 여부, 제한 사항을 명확히 줍니다. 내부 메모에는 미지원 항목, 보강 예정, 예외 승인자, 다음 리뷰일을 남깁니다.
| 구분 | 고객용 답변 | 내부 메모 |
|---|---|---|
| SSO | 지원 IdP와 설정 범위 | 특정 고객 예외, 장애 이력 |
| audit log | 제공 가능한 로그 범위와 export 방식 | 누락 필드, 보강 예정 |
| support access | 접근 조건, 기록, 고객 안내 | 내부 escalation 기준 |
| data request | 요청 상태와 고객 안내 흐름 | 처리 지연 원인, owner |
| exception | 현재 제한 사항 | 예외 승인자, 만료일 |
이 분리가 없으면 고객에게 너무 많은 내부 정보가 나가거나, 반대로 필요한 제한 사항이 빠진 채 과장된 답변이 나갈 수 있습니다.
보안 검토 답변은 최신성 만료일을 가져야 합니다
security questionnaire 답변은 한 번 작성했다고 끝나지 않습니다. SSO 설정, audit log 필드, support access 정책, data retention 상태, CRM 필드는 제품과 운영이 바뀔 때 함께 바뀝니다.
| 항목 | 권장 리뷰 주기 |
|---|---|
| SSO·SCIM 기능 범위 | 분기별 또는 주요 릴리스 후 |
| audit log 필드 | 월간 또는 로그 스키마 변경 후 |
| support access 기준 | support workflow 변경 후 |
| data request 상태값 | export/deletion/restore 프로세스 변경 후 |
| customer-safe summary | 고객 제출 전 매번 |
| exception list | 마감일 전과 제출 후 |
특히 오래된 답변을 복사해 쓰는 방식은 위험합니다. 답변 템플릿에는 last_verified_at, verified_by, source_link, next_review_at이 있어야 합니다.
월간 리포트는 보안 점수보다 답변 불일치를 봅니다
보안 검토 운영의 목표는 멋진 점수를 만드는 것이 아니라, 고객 질문에 반복 가능한 답변을 주는 것입니다. 월간 리포트는 아래 불일치를 중심으로 보는 편이 실용적입니다.
| 점검 항목 | 질문 |
|---|---|
| stale answer | 90일 이상 확인되지 않은 답변이 있는가 |
| missing evidence owner | 담당자 없는 답변이 있는가 |
| unsupported marked yes | 실제 미지원인데 지원으로 답한 항목이 있는가 |
| evidence link broken | 원본 링크가 깨졌거나 권한이 없는가 |
| customer/internal mixed | 고객용 답변에 내부 메모가 섞였는가 |
| exception expired | 예외 만료일이 지났는데 갱신되지 않았는가 |
| duplicate answer | 고객별로 다른 문구가 같은 질문에 쓰였는가 |
이 리포트는 sales를 막기 위한 문서가 아닙니다. enterprise sales가 빨라지려면 반복 질문에 대한 증거가 정리돼 있어야 합니다.
바로 쓰는 체크리스트
- security questionnaire 질문마다 원본 evidence 링크가 있는가.
- SSO, SCIM, role mapping, deprovision 증거를 기능 설명과 분리했는가.
- audit log 범위와 export 가능 여부를 같은 표에 적었는가.
- support access 답변에 source ticket, reason code, session TTL, post-access notice가 포함되는가.
- data export, deletion, retention, backup restore 상태값을 단정 문구 대신 운영 상태로 설명하는가.
- 고객용 답변과 내부 메모가 분리되어 있는가.
- CRM에는 답변 원문이 아니라 due date, owner, exception count, renewal risk만 남기는가.
- 각 답변에
last_verified_at,verified_by,next_review_at이 있는가. - 미지원 또는 부분 지원 항목은 예외 승인자와 만료일을 가진 상태로 관리하는가.
- 월간 리포트에서 stale answer, broken evidence link, customer/internal mixed 항목을 확인하는가.
마무리
B2B SaaS의 security questionnaire와 vendor review는 영업 문서이면서 운영 증거 관리입니다. 답변을 잘 쓰는 것보다 더 중요한 것은 SSO, audit log, data retention, support access 증거가 같은 기준으로 연결되어 있고, 고객에게 보여줄 수 있는 요약과 내부 운영 메모가 분리되어 있는 상태입니다.
이 구조를 먼저 만들면 enterprise sales에서 반복 질문을 받을 때마다 새로 조사하지 않아도 됩니다. 고객에게는 과장 없는 답변을 주고, 내부팀은 어떤 증거를 언제 다시 확인해야 하는지 알 수 있습니다.
About The Author
