DLP 솔루션 비교 2026, 데이터 유출 방지·문서보안·운영 기준

DLP 솔루션 비교를 검토하는 보안 운영실과 데이터 흐름 대시보드 — DLP는 제품명이 아니라 데이터 위치, 정책 예외, 운영 증거를 맞추는 보안 운영 체계다.

DLP 솔루션 비교를 시작할 때 가장 흔한 실수는 제품 데모 화면의 차단 버튼만 보고 결론을 내리는 것이다.

실제 구매 실패는 민감정보 정의가 흔들리거나, 예외 승인자가 없거나, 경고가 너무 많아 보안팀이 정책을 꺼버리는 지점에서 난다.

이 글은 Microsoft Purview DLP, Google Sensitive Data Protection, Amazon Macie 같은 공식 문서를 기준으로 기업이 먼저 볼 비교 축을 정리한다.

네이버 검색 수요는 내부 우선순위 판단에만 쓰고, 본문 근거는 공식 문서와 기술 문서로만 분리했다.

핵심 요약

DLP는 이메일 차단 도구가 아니라 데이터 식별, 위치별 통제, 예외 승인, 감사 증거를 묶는 운영 체계다.
Microsoft 365 중심 조직은 Purview DLP와 Endpoint DLP 범위를 먼저 보고, 데이터 레이크 조직은 Macie나 Sensitive Data Protection의 탐지 단가와 스캔 범위를 따져야 한다.
비용은 사용자 라이선스, 검사한 데이터량, 저장소 객체 수, 로그 보관, 튜닝 인력 시간을 따로 계산해야 한다.
도입 PoC는 차단부터 시작하지 말고 audit, warn, justify, block 순서로 운영팀과 데이터 오너가 버틸 수 있는지 검증해야 한다.

이 글이 필요한 사람

Microsoft 365, Google Workspace, AWS S3, SaaS 저장소에 흩어진 문서보안 범위를 한 번에 정리해야 하는 보안 담당자
개인정보, 계약서, 소스코드, API 키 유출을 막아야 하지만 어떤 DLP 제품군부터 볼지 모르는 IT 관리자
DLP 견적을 사용자 수 기준으로만 받았다가 데이터 검사량, 로그, 예외 운영 비용을 놓칠까 걱정되는 구매 담당자
Copilot, 생성형 AI, 외부 SaaS 업로드까지 포함해 데이터 유출 방지 정책을 재설계하려는 보안 아키텍트
감사 대응용 로그와 실제 차단 정책 사이의 간격을 줄이고 싶은 컴플라이언스 담당자

DLP 솔루션 비교의 첫 질문은 차단 위치다

DLP는 한 제품 안에서도 이메일, 파일 저장소, 엔드포인트, 클라우드 저장소, 웹 업로드, AI 프롬프트까지 통제 위치가 다르다.

Microsoft Learn은 Purview DLP가 Exchange, SharePoint, OneDrive, Teams, Office 앱, Windows와 macOS 엔드포인트, 온프레미스 파일 공유, Power BI, Copilot 일부 위치를 다룬다고 설명한다.

Google Cloud Sensitive Data Protection은 200개 이상 기본 infoType, 사용자 정의 탐지기, 비식별화, 저장소와 이미지 검사, 조직 단위 데이터 프로파일링을 축으로 둔다.

Amazon Macie는 S3 버킷과 객체의 민감정보 발견, 접근 제어 위험 가시화, 자동 데이터 발견과 대상 지정 검사에 초점이 맞춰져 있다.

이 조건이면 Microsoft 365 문서 공유가 핵심인 회사는 Purview 중심 PoC가 빠르고, S3 데이터 레이크가 핵심인 회사는 Macie나 별도 DSPM 축을 먼저 봐야 한다.

반대로 SaaS 업로드와 브라우저 경로가 핵심이면 DLP 단독보다 CASB, SSE, 브라우저 제어, IdP 조건부 접근을 함께 비교해야 한다.

후보군을 네 갈래로 나누면 비교가 쉬워진다

비교 축	대표 후보	강한 지점	먼저 볼 한계	PoC 질문
협업·메일 DLP	Microsoft Purview DLP	Exchange, SharePoint, OneDrive, Teams, Office, endpoint 정책을 한 정책 수명주기로 묶기 쉽다.	Microsoft 365 밖 저장소와 비관리 브라우저 경로는 추가 커넥터나 별도 통제가 필요하다.	현재 민감 문서가 어느 M365 위치에서 가장 많이 외부 공유되는가.
클라우드 데이터 발견	Google Sensitive Data Protection, Amazon Macie	저장소 안의 PII, 결제 정보, 비밀값, 사용자 정의 패턴을 대량 검사하기 좋다.	사용자 행위 차단보다 발견, 분류, 태깅, 티켓화가 중심이므로 엔드포인트 통제와 나눠 봐야 한다.	검사 대상 GB, 객체 수, 재검사 주기를 비용 모델로 계산했는가.
엔드포인트 DLP	Endpoint DLP, MDM 연동 DLP	USB, 로컬 복사, 프린트, 클립보드, 외부 업로드 같은 사용자 행동을 통제한다.	오탐이 곧 업무 중단으로 이어져 예외 승인과 경고 문구 설계가 중요하다.	차단보다 경고와 사유 입력만으로 위험 행동이 줄어드는가.
웹·SaaS·AI 경로 통제	CASB, SSE, 브라우저 제어, AI 보안 게이트	비관리 앱 업로드, 개인 클라우드, 생성형 AI 입력을 정책 위치로 끌어온다.	암호화 트래픽 처리, 프라이버시, 우회 브라우저, 네트워크 경로 설계가 구매 난도를 높인다.	Shadow IT 목록과 실제 업로드 이벤트를 근거로 정책을 만들 수 있는가.

표에서 보듯 DLP 솔루션 비교는 벤더 이름보다 보호 위치와 통제 방식이 먼저다.

차단 위치를 틀리면 기능은 좋아도 실제 유출 경로를 놓치고, 감사 때는 “정책은 있었지만 대상 저장소가 아니었다”는 결론이 나온다.

공식 문서 기준으로 확인한 핵심 사실

Microsoft Purview DLP는 키워드, 정규식, 내부 검증 함수, 근접 조건, 머신러닝 등 깊은 콘텐츠 분석으로 정책 일치를 판단한다고 문서화한다.
Microsoft 문서는 엔터프라이즈 앱과 장치, 인라인 웹 트래픽처럼 정책 위치가 나뉜다고 설명하므로 PoC 범위를 한 위치로 좁혀야 한다.
Google Sensitive Data Protection은 200개 이상 기본 infoType과 사용자 정의 탐지기, 마스킹, 편집, 형식 보존 암호화, 날짜 이동 같은 비식별화 기능을 제공한다.
Google 문서는 스트림, 구조화 텍스트, Cloud Storage, BigQuery, 이미지 검사와 재식별 위험 분석을 별도 축으로 제시한다.
Amazon Macie는 S3 버킷 인벤토리와 모니터링, 객체 모니터링, 검사한 데이터량을 기준으로 과금 축을 나누고 30일 무료 평가와 150GB 한도를 제시한다.
IBM은 DLP가 data in use, data in motion, data at rest 전반의 정책 집행이라는 점을 강조하고, 고객 PII와 지식재산 정보가 주요 대상이라고 설명한다.

공식 문서의 공통점은 “민감정보를 찾는다”에서 끝나지 않고 위치, 행위, 예외, 증거를 함께 다룬다는 점이다.

따라서 제품 비교표에는 탐지 정확도만이 아니라 데이터 오너, 예외 만료일, 보안 이벤트 라우팅, 비용 단위가 들어가야 한다.

비용 구조는 사용자 수와 검사량을 분리해서 봐야 한다

DLP 견적서의 첫 줄이 월 사용자 라이선스라면 구매팀은 저장소 검사량과 운영 인력 시간을 따로 물어봐야 한다.

Macie 공식 가격표는 S3 버킷 수, 모니터링 객체 수, 검사한 데이터량을 과금 축으로 나누며 30일 무료 평가와 150GB 검사 한도를 명시한다.

IBM의 데이터 침해 비용 보고서 인용 자료는 전 세계 평균 침해 비용을 USD 4.88 million, IP 관련 침해 비중을 43%로 제시한다.

이 숫자는 DLP 구매비를 정당화하는 절대 기준이 아니라, 고위험 데이터 유출의 재무 영향을 보수적으로 설명할 때 쓰는 위험 기준선이다.

생성형 AI 입력 경로까지 같이 사는 경우에는 DLP 비용과 별도로 입력 토큰, 출력 토큰, USD 청구 단위를 보안 게이트 견적서에 분리해 적어야 한다.

비용 항목	공식 근거로 볼 숫자·단위	견적 질문	실무 판단
저장소 발견 비용	Amazon Macie는 30일 무료 평가와 자동 발견 150GB 한도를 제시한다.	무료 평가 뒤 월 검사 GB와 객체 수가 어떻게 늘어나는가.	S3가 핵심이면 사용자 수보다 검사량 추정이 먼저다.
버킷 인벤토리 비용	Macie 예시는 15개 S3 버킷에 월 $0.10 단가를 곱해 $1.50을 계산한다.	버킷 수가 계정·리전별로 몇 개인가.	버킷이 많고 데이터가 적은 조직도 기본 모니터링 비용을 본다.
라이선스 비용	Microsoft 365 계열 DLP는 플랜과 위치별 권한에 따라 달라진다.	Endpoint DLP, Teams, Copilot, 비Microsoft 앱 보호가 같은 플랜에 들어가는가.	사용자당 가격표만 보면 실제 보호 위치가 빠질 수 있다.
사고 위험 기준	IBM은 전 세계 평균 데이터 침해 비용을 USD 4.88 million으로 제시한다.	우리 조직의 PII, 계약서, 소스코드 유출 시 손실 항목은 무엇인가.	ROI 계산에는 차단률보다 고위험 데이터의 업무 가치가 들어가야 한다.
운영 인력 비용	정책 튜닝, 예외 승인, 로그 검토, 감사 대응은 별도 내부 시간이다.	첫 90일 동안 주당 몇 시간의 데이터 오너 검토가 필요한가.	DLP는 콘솔 구매보다 운영 회의 비용이 먼저 무너진다.

이 조건이면 저장소 검사량이 큰 데이터 플랫폼은 GB, 객체 수, 재검사 주기를 먼저 모델링하고, 협업툴 중심 조직은 사용자 라이선스와 보호 위치를 먼저 맞춘다.

비용표가 공개되지 않은 엔터프라이즈 DLP 제품은 “계약별 변동”으로 남기되, 어떤 단위가 청구되는지 견적서에 직접 적게 해야 한다.

도입 전 90일 PoC 순서

1주차에는 보호할 데이터 유형을 10개 이하로 줄이고, 주민번호·카드번호·계약서·소스코드 비밀값처럼 테스트 가능한 패턴부터 정한다.
2주차에는 Exchange, SharePoint, OneDrive, Teams, S3, BigQuery, 개인 클라우드, USB, 브라우저 업로드 중 실제 유출 가능 경로를 표로 만든다.
3주차에는 audit only 정책으로 7일 이상 이벤트를 모으고, 데이터 오너가 이벤트를 이해할 수 있는 이름으로 정책을 바꾼다.
4주차에는 warn and justify 정책을 일부 부서에 켜고, 경고 문구와 사유 입력이 업무를 멈추지 않는지 본다.
5주차에는 고위험 데이터만 block 정책으로 올리고, 보안팀·법무팀·현업 오너의 예외 승인 SLA를 측정한다.
6주차 이후에는 SIEM, SOAR, 티켓 시스템, HR 소스와 연결해 joiner, mover, leaver 이벤트와 DLP 예외가 충돌하지 않는지 확인한다.
90일 종료 전에는 false positive, true positive, 승인 예외, 무응답 티켓, 재발 이벤트를 KPI로 남기고 정식 계약 범위를 줄인다.

PoC에서 가장 위험한 선택은 첫날부터 전사 차단 정책을 켜는 것이다.

경고와 사유 입력으로 줄어드는 위험 행동이 보이면 차단 범위를 좁혀도 보안 효과를 설명할 수 있다.

실무 시나리오 1: Microsoft 365 중심 회사

실무 시나리오 1은 영업·재무·인사 문서가 SharePoint와 OneDrive에 몰려 있고, 외부 공유 링크와 Teams 첨부가 주요 유출 경로인 회사다.

이 경우는 Purview DLP 정책을 Exchange, SharePoint, OneDrive, Teams, Office 앱, Endpoint DLP 범위로 나누고, 문서 라벨과 DLP 조건을 같은 단어로 맞추는 것이 먼저다.

재무팀 파일을 외부 도메인으로 공유할 때 차단만 걸면 현업은 개인 메신저나 개인 클라우드로 돌아갈 수 있다.

그래서 첫 달에는 경고, 사유 입력, 관리자 알림, 데이터 오너 승인으로 사용자의 실제 우회 패턴을 먼저 봐야 한다.

항목	권장 시작값	보류해야 할 신호	확장 기준
정책 위치	SharePoint, OneDrive, Exchange부터 audit	Teams 채팅까지 한 번에 차단해 업무 문의가 폭증	외부 공유 이벤트 상위 20개 정책을 튜닝
민감정보 유형	주민번호, 카드번호, 계약서 키워드, 고객명부 패턴	부서별 용어가 달라 오탐이 30% 이상	사용자 정의 사전과 근접 조건 보강
엔드포인트	USB 복사 warn and justify	개발자 빌드 산출물까지 차단	고위험 라벨 파일만 block
증거	정책명, 파일 위치, 사용자, 사유, 승인자 저장	보안팀만 이해하는 이벤트명	감사 질문에 데이터 오너가 답할 수 있음

실무 시나리오 2: S3와 데이터 레이크 중심 회사

실무 시나리오 2는 고객 행동 로그, 결제 검증 파일, 백오피스 export가 S3나 BigQuery 같은 저장소에 계속 쌓이는 회사다.

이 조건이면 DLP 솔루션 비교의 중심은 사용자 행위 차단보다 저장소 발견, 데이터 프로파일링, 태그, 소유자 지정, 재검사 주기가 된다.

Macie는 S3에 강하고, Google Sensitive Data Protection은 infoType 탐지와 비식별화 흐름이 강하므로 데이터 위치가 먼저다.

데이터 레이크에서는 “누가 파일을 내려받았는가”보다 “어느 버킷과 테이블에 PII가 섞였는가”가 앞선 질문이 된다.

첫 검사는 전체 스캔보다 민감 가능성이 높은 prefix, 데이터셋, export 폴더를 좁혀 시작한다.
검사 결과는 보안팀 콘솔에만 두지 말고 버킷 태그, 데이터 카탈로그, 티켓 시스템으로 보내 데이터 오너가 보게 한다.
마스킹, 편집, 형식 보존 암호화, 날짜 이동 같은 비식별화는 분석팀의 쿼리 요구와 함께 검토한다.
자동 발견 비용은 저장소 증가와 함께 오르므로 월별 신규 GB, 객체 수, 재검사 정책을 따로 기록한다.

실무 시나리오 3: 생성형 AI와 Shadow IT 업로드

실무 시나리오 3은 직원이 고객 파일을 개인 클라우드, 외부 번역 도구, 생성형 AI 입력창에 붙여 넣는 것이 걱정되는 조직이다.

이 경우는 전통적인 메일 DLP만으로 부족하고, 브라우저 제어, CASB, SSE, IdP 조건부 접근, AI 사용 정책을 함께 비교해야 한다.

Microsoft 문서가 인라인 웹 트래픽과 Edge for Business 경로를 언급하는 이유도 관리되지 않은 앱과 AI 입력 경로가 실제 유출 위치가 되었기 때문이다.

다만 네트워크 경로 DLP는 프라이버시, 복호화 범위, 우회 브라우저, 원격 근무 단말 정책을 건드리므로 법무와 HR이 같이 서명해야 한다.

위험 경로	탐지 신호	1차 대응	정식 통제
개인 클라우드 업로드	대량 파일 업로드, 외부 도메인, 민감 라벨	경고와 사유 입력	승인된 SaaS만 허용하고 예외 만료일 부여
생성형 AI 입력	고객명부, 계약 조항, 소스코드 비밀값 패턴	입력 전 경고와 로그	기업용 AI 경로와 데이터 처리 약관으로 분리
외부 번역·요약 도구	문서 복사 붙여넣기, 파일 첨부	업무 대체 경로 안내	승인 도구 목록과 브라우저 정책 연결
USB·로컬 복사	고위험 라벨 파일의 이동식 매체 복사	warn and justify	특정 라벨만 block하고 관리자 승인 예외

정책 설계는 탐지보다 예외 운영이 어렵다

DLP 솔루션 비교에서 탐지율만 묻는 조직은 도입 뒤 예외 요청과 업무 마찰을 감당하지 못할 가능성이 높다.

보안팀은 차단 이벤트를 좋아하지만, 현업은 고객 제출, 외부 감사, 법무 검토, 장애 대응처럼 정당한 반출 업무를 계속 해야 한다.

이 조건이면 예외 승인자, 만료일, 티켓 번호, 사유 입력, 재발 이벤트 집계가 없는 DLP 제품은 정식 도입을 보류하는 편이 낫다.

반대로 예외 만료와 데이터 오너 검토가 콘솔 밖으로 잘 나오는 제품은 초기 오탐이 있어도 운영으로 줄일 수 있다.

운영 질문	좋은 답	위험한 답	확인 증거
누가 예외를 승인하는가	데이터 오너와 시스템 오너가 함께 승인	보안팀이 모든 예외를 임의 승인	티켓 번호, 승인자, 만료일
오탐은 누가 줄이는가	정책 오너가 샘플을 보고 조건을 조정	벤더에게만 튜닝을 맡김	정책 변경 로그와 false positive 샘플
차단 전 사용자에게 무엇을 보여주는가	업무 대체 경로와 사유 입력 안내	무조건 금지 문구만 표시	경고 문구별 이탈률과 재시도 이벤트
감사 증거는 어디에 남는가	SIEM, 티켓, 데이터 카탈로그에 연결	DLP 콘솔에만 이벤트 저장	검색 가능한 사건번호와 보존 정책

도입 전 체크리스트

보호할 민감정보 유형을 10개 이하로 줄이고, 각 유형마다 공식 기준 또는 내부 데이터 사전을 붙였다.
메일, 협업툴, 엔드포인트, S3, BigQuery, SaaS, 브라우저, AI 입력 경로를 위치별로 나눴다.
각 위치에서 audit, warn, justify, block 중 어떤 단계를 적용할지 정했다.
사용자 라이선스, 검사 GB, 객체 수, 로그 보관, 구현 컨설팅, 내부 튜닝 시간을 따로 추정했다.
DLP 이벤트가 SIEM, SOAR, 티켓 시스템, 데이터 카탈로그로 나가는지 확인했다.
예외 승인자와 만료일이 없으면 block 정책을 켜지 않는다는 원칙을 세웠다.
개발자와 분석팀이 쓸 샘플 데이터, 비식별화, synthetic data 대안을 준비했다.
감사 대응 질문에 맞춰 정책명, 데이터 유형, 파일 위치, 사용자, 승인자, 조치 결과가 검색되는지 테스트했다.

실무 스켈레톤: 정책 intake 파일

아래 YAML은 특정 제품의 실제 정책 문법이 아니라 DLP 도입 회의에서 빠진 질문을 줄이는 intake 템플릿이다.

# dlp-policy-intake.yml
# 목적: DLP 솔루션 비교 전에 보호 위치, 탐지 기준, 예외 승인, 증거 보관 책임을 고정한다.
# 실제 제품 정책명과 커넥터 이름은 Microsoft Purview, Google Sensitive Data Protection, Amazon Macie, CASB/SSE 문서에 맞게 바꾼다.

classification_model:
  sensitive_types:
    - personal_identifier
    - payment_card
    - health_record
    - contract_file
    - source_code_secret
  custom_detectors:
    regex_dictionary: required
    proximity_keyword: required
    false_positive_sample_set: required

coverage_scope:
  microsoft_365:
    exchange: monitor_then_restrict
    sharepoint_onedrive: warn_and_justify
    teams_messages: monitor_sensitive_sharing
  endpoint:
    windows: block_usb_copy_for_high_risk
    macos: warn_before_external_upload
  cloud_storage:
    s3: discover_classify_and_tag_owner
    bigquery_cloud_storage: inspect_and_deidentify_when_needed
  web_and_ai:
    unmanaged_saas_upload: step_up_or_block
    ai_prompt_upload: warn_log_and_review

exception_workflow:
  owner_approval: required
  expiry_days: 30
  evidence_ticket: required
  quarterly_review: required
  break_glass_reason: required

response_rules:
  severity_high:
    action: block_and_alert
    notify: data_owner_security_team
  severity_medium:
    action: warn_justify_and_log
    notify: data_owner
  severity_low:
    action: audit_only
    notify: policy_owner_weekly

템플릿의 목적은 차단 규칙을 빨리 만드는 것이 아니라 데이터 오너와 운영 책임을 먼저 고정하는 것이다.

제품 콘솔에 넣기 전에는 각 항목을 공급사 공식 문서의 정책 위치, 지원 OS, 커넥터, 라이선스 조건과 대조해야 한다.

실무 스켈레톤: 준비도 점검 스크립트

아래 파이썬 스켈레톤은 DLP PoC 회의에서 빠진 항목을 점수화하는 예시다.

# dlp_readiness_check.py
# 목적: 특정 벤더 API를 호출하지 않고 DLP 도입 회의에서 빠진 항목을 찾는 점검 스켈레톤이다.
# 입력은 자산 목록, SaaS 관리자 export, 저장소 태그, 보안 티켓, 예외 승인 로그에서 가져온다고 가정한다.

CHECKS = {
    "sensitive_type_taxonomy_defined": 15,
    "data_locations_inventory_done": 15,
    "endpoint_and_cloud_coverage_mapped": 15,
    "data_owner_named": 10,
    "exception_expiry_policy_defined": 10,
    "siem_ticket_route_tested": 10,
    "false_positive_review_sampled": 10,
    "cost_metering_model_estimated": 10,
    "dlp_exception_review_scheduled": 5,
}

sample = {
    "sensitive_type_taxonomy_defined": True,
    "data_locations_inventory_done": True,
    "endpoint_and_cloud_coverage_mapped": False,
    "data_owner_named": True,
    "exception_expiry_policy_defined": False,
    "siem_ticket_route_tested": True,
    "false_positive_review_sampled": False,
    "cost_metering_model_estimated": True,
    "dlp_exception_review_scheduled": False,
}

score = sum(weight for key, weight in CHECKS.items() if sample.get(key))
missing = [key for key in CHECKS if not sample.get(key)]
print({"score": score, "missing": missing})

점수가 낮게 나오면 제품 데모를 더 보는 것보다 데이터 위치 목록과 예외 승인 흐름을 먼저 보강하는 편이 낫다.

특히 endpoint와 cloud coverage가 비어 있으면 보안팀은 정책을 만들 수 있어도 실제 유출 위치를 놓친다.

실무 스켈레톤: 예외 만료 리뷰 쿼리

DLP 예외는 만들 때보다 지울 때가 더 중요하다.

-- dlp_exception_review.sql
-- 목적: 30일이 지난 DLP 예외와 반복 승인자를 찾아 정책 튜닝 회의에 올린다.
-- 실제 테이블명은 티켓 시스템, SIEM, DLP 콘솔 export 스키마에 맞게 바꾼다.

select
  exception_id,
  data_owner,
  policy_name,
  business_reason,
  approved_by,
  created_at,
  expires_at,
  last_event_count
from dlp_exceptions
where expires_at < current_date
   or last_event_count > 20
order by expires_at asc, last_event_count desc;

30일 예외가 계속 누적되면 DLP는 보안 통제가 아니라 우회권 발급 시스템이 된다.

반복 예외는 정책 오탐이거나 승인되지 않은 업무 프로세스라는 신호이므로 분기별 리뷰가 아니라 주간 리뷰로 올리는 편이 안전하다.

공급사별 질문 리스트

질문	Microsoft 365 중심	클라우드 저장소 중심	웹·SaaS 중심	계약 전 증거
지원 위치	Exchange, SharePoint, OneDrive, Teams, Office, endpoint 범위 확인	S3, Cloud Storage, BigQuery, 파일 형식 범위 확인	비관리 SaaS, 브라우저, AI 입력 경로 확인	위치별 정책 생성 화면과 제한 목록
탐지 방식	민감정보 유형, EDM, 라벨, 정규식, 근접 조건 확인	infoType, 사용자 정의 detector, 샘플링, 비식별화 확인	업로드 본문, 파일 첨부, 프롬프트 입력 검사 확인	테스트 파일 20개 이상의 결과표
대응 방식	audit, warn, justify, block, 관리자 알림 확인	발견, 태그, 티켓, 격리, 마스킹 흐름 확인	경고, 세션 제어, 차단, 승인 앱 유도 확인	정책별 사용자 메시지와 이벤트 로그
운영 증거	Purview 감사 로그와 SIEM 연동 확인	버킷 태그, 데이터 카탈로그, 티켓 연동 확인	CASB 로그와 IdP 조건부 접근 연동 확인	사건번호, 승인자, 만료일, 보존 기간
비용 단위	사용자 플랜과 위치별 라이선스 확인	검사 GB, 객체 수, 버킷 수, 재검사 주기 확인	사용자 수, 트래픽, 앱 수, 로그량 확인	견적서의 청구 단위와 무료 평가 조건