SaaS 보안 검토 체크리스트 2026, 새 업무 도구에 고객정보와 파일을 넣기 전 확인할 항목
SaaS 보안 검토 체크리스트 2026, 새 업무 도구에 고객정보와 파일을 넣기 전 확인할 항목
새 SaaS를 살 때 팀은 보통 가격, 기능, 사용 편의성부터 봅니다. 하지만 실제 운영에서 더 오래 남는 것은 데이터와 권한입니다. 무료체험 중에 고객정보를 올리고, Google Drive나 Slack을 연결하고, 자동화 도구에 계정을 붙이고, 파일 공유 링크를 열어 둔 뒤에야 "이 도구를 계속 써도 되는가"를 묻는 경우가 많습니다.
그래서 SaaS 보안 검토는 대기업 보안팀만의 절차가 아닙니다. 작은 팀도 Google Workspace, Microsoft 365, Slack, Dropbox, Atlassian, Zapier, Make, Notion 같은 업무 도구를 새로 쓰기 전에는 최소한 데이터 종류, 접근권한, 인증, 외부 공유, 감사 로그, 해지 시 회수 방법을 확인해야 합니다.
이 글은 보안 컨설팅, 법률 자문, 개인정보보호 자문이 아닙니다. 작은 팀이 새 SaaS를 구매하거나 무료체험에서 유료 전환하기 전에 빠뜨리기 쉬운 운영 항목을 줄이는 체크리스트입니다. 실제 적용 전에는 각 서비스의 관리자 콘솔, 계약 조건, 보안 문서, 내부 정책을 다시 확인해야 합니다.
공식 문서 확인 기준은 2026년 6월 19일입니다.
먼저 결론부터 보면
새 SaaS에 고객정보, 파일, 회의록, 자동화 연결을 넣기 전에는 아래 14개 항목을 한 표에 남기는 편이 안전합니다.
| 항목 | 검토 질문 |
|---|---|
| 사용 목적 | 어떤 업무 문제를 해결하는가 |
| 데이터 종류 | 고객정보, 파일, 계약서, 결제정보, 회의록이 들어가는가 |
| 데이터 위치 | 어느 국가 또는 리전에서 보관되는가 |
| 계정 기준 | 개인 메일이 아니라 회사 계정으로 가입했는가 |
| 관리자 | owner와 backup admin이 최소 2명인가 |
| 인증 | MFA, SSO, SCIM을 쓸 수 있는가 |
| 권한 | admin, member, guest, 외주 권한이 나뉘는가 |
| 외부 공유 | 링크 공유, 게스트 초대, 공개 페이지를 제한할 수 있는가 |
| 앱 연결 | Google Drive, Slack, CRM, 결제, 자동화 도구와 연결되는가 |
| 감사 로그 | 누가 로그인, 공유, 삭제, 설정 변경을 했는지 볼 수 있는가 |
| DLP·보호 | 민감 데이터 이동을 제한하거나 라벨링할 수 있는가 |
| 보존·삭제 | 해지 후 데이터 내보내기와 삭제 절차가 있는가 |
| 알림 | 결제, 로그인, 권한 변경, 사용량 알림을 누가 받는가 |
| 재검토일 | 30일 후 계속 쓸지 다시 볼 날짜가 있는가 |
핵심은 "이 서비스가 안전한가"를 추상적으로 묻는 것이 아닙니다. "우리 팀 데이터가 어디에 들어가고, 누가 접근하고, 문제가 생겼을 때 무엇을 확인할 수 있는가"를 묻는 것입니다.
새 SaaS를 사도 되는지 결정하는 절차는 SaaS 구매 승인 체크리스트에서 다뤘습니다. 이미 쓰는 SaaS 권한 회수는 팀 SaaS 계정 권한 감사 체크리스트에서 다뤘습니다. 이번 글은 그 중간 단계인 "새 도구에 데이터를 넣기 전 보안 검토"입니다.
보안 검토가 필요한 SaaS의 기준
모든 도구에 무거운 심사를 붙이면 팀이 움직이지 못합니다. 대신 아래 조건 중 하나라도 해당하면 최소 보안 검토를 거치는 식으로 기준을 잡는 편이 현실적입니다.
- 고객 이름, 전화번호, 이메일, 주문정보, 상담 이력이 들어갑니다.
- 계약서, 견적서, 세금계산서, 내부 문서, 회의록이 저장됩니다.
- Google Drive, OneDrive, Dropbox, Slack, Teams, CRM, 쇼핑몰, 결제 도구와 연결됩니다.
- 외부 링크 공유, 게스트 초대, 공개 페이지 기능이 있습니다.
- 자동화 도구가 다른 SaaS의 데이터를 읽거나 씁니다.
- 관리자 계정이 퇴사자, 외주, 개인 메일에 묶일 수 있습니다.
- 로그, 감사 기록, 데이터 내보내기 기능이 플랜마다 다릅니다.
- AI 기능이 업로드한 문서나 대화 내용을 처리합니다.
반대로 단순한 디자인 샘플, 공개 자료 수집, 팀 외부 데이터가 없는 일회성 도구라면 가벼운 승인으로 충분할 수 있습니다. 검토의 무게는 서비스 이름이 아니라 데이터와 권한의 크기로 정해야 합니다.
1단계: 데이터 종류를 먼저 분류하기
SaaS 보안 검토는 기능표보다 데이터 표에서 시작해야 합니다. 어떤 데이터가 들어가는지 모르면 SSO, DLP, 감사 로그를 켤지 말지도 판단하기 어렵습니다.
| 데이터 종류 | 예시 | 최소 확인 |
|---|---|---|
| 공개 데이터 | 공개 블로그 글, 공개 상품 설명 | 일반 계정 관리 |
| 내부 문서 | 회의록, 운영 매뉴얼, 제안서 | 외부 공유 제한, 로그 |
| 고객정보 | 이름, 연락처, 상담 이력, 주문정보 | 접근권한, 내보내기, 삭제 절차 |
| 계약·결제 정보 | 계약서, 견적서, 인보이스, 카드 관련 메모 | owner, 보존 기간, 다운로드 위치 |
| 자동화 연결 | Gmail, Slack, CRM, 쇼핑몰, 결제 API | 연결 계정 owner, 로그, 권한 회수 |
| 민감 업무 정보 | 인사, 보안, 장애, 내부 재무 자료 | 별도 승인, 최소 권한, 보존 정책 |
작은 팀은 처음부터 복잡한 데이터 등급 체계를 만들기보다 "고객정보가 들어가는가", "파일이 들어가는가", "다른 SaaS와 연결되는가" 세 질문만 먼저 고정해도 실수가 줄어듭니다.
2단계: Google Workspace 연결은 Context-Aware Access와 DLP 관점으로 보기
Google Workspace를 중심 계정으로 쓰는 팀은 새 SaaS가 Google Drive, Gmail, Calendar, OAuth 앱 연결을 요구하는지 확인해야 합니다. Google 공식 문서는 Context-Aware Access가 사용자 신원, 위치, 기기 보안 상태, IP 주소 같은 조건을 기준으로 Workspace 앱 접근을 제어할 수 있다고 설명합니다.
출처: Google Workspace Admin Help – About Context-Aware Access
Google은 데이터 보호 규칙과 Context-Aware Access 조건을 결합해 특정 조건에서 민감 콘텐츠 전송을 제한할 수 있다고도 안내합니다. 예를 들어 위치, 기기 상태, IP 조건에 따라 DLP 규칙이 적용되도록 구성할 수 있습니다.
출처: Google Workspace Admin Help – Combine data protection rules with Context-Aware Access conditions
Google Workspace 연결 검토표에는 아래 질문을 넣습니다.
| 항목 | 확인 질문 |
|---|---|
| OAuth 앱 | 어떤 권한 범위를 요청하는가 |
| Drive 접근 | 전체 Drive인지 특정 파일·폴더인지 |
| Gmail 접근 | 읽기, 보내기, 라벨 변경 권한이 있는가 |
| 외부 공유 | 새 도구가 공개 링크를 만들 수 있는가 |
| 기기 조건 | 회사 기기와 개인 기기를 구분할 수 있는가 |
| DLP | 고객정보나 계약서 이동을 제한할 수 있는가 |
Google 계정을 중심으로 새 SaaS를 붙이면 입사자와 퇴사자 관리가 쉬워질 수 있지만, 권한 범위를 보지 않으면 한 번의 OAuth 승인으로 파일과 메일 접근권한이 과하게 열릴 수 있습니다.
3단계: Microsoft 365는 보안 기본값, DLP, 민감도 레이블을 같이 보기
Microsoft 365를 쓰는 팀은 Teams, SharePoint, OneDrive, Outlook과 새 SaaS 연결을 함께 봐야 합니다. Microsoft의 business security best practices 문서는 회사 데이터 보호를 위해 Microsoft Purview Data Loss Prevention, 민감도 레이블, 파일 공유 설정, Teams 보안 기능 등을 점검 항목으로 제시합니다.
출처: Microsoft Learn – Microsoft 365 for business security best practices
Microsoft Purview의 sensitivity labels 문서는 조직 데이터에 분류와 보호를 적용할 수 있다고 설명합니다.
출처: Microsoft Learn – Learn about sensitivity labels
Microsoft 365 보안 검토에서는 아래를 확인합니다.
- 새 SaaS가 SharePoint, OneDrive, Teams 파일에 접근하는가?
- 사용자가 개인 계정으로 Microsoft 로그인할 수 있는가?
- MFA 또는 조건부 접근 정책이 필요한 데이터인가?
- 민감도 레이블이 적용된 파일을 외부 도구에 업로드해도 되는가?
- Teams 메시지, 파일, 회의 데이터가 외부 앱으로 이동하는가?
- 감사 로그에서 로그인, 파일 작업, Teams 활동을 확인할 수 있는가?
Microsoft 공식 문서는 Microsoft 365 활동을 unified audit log로 모니터링하고 조사할 수 있다고 안내합니다. 다만 감사 데이터는 기능, 라이선스, 설정 상태에 따라 범위가 달라질 수 있으므로 도입 전 확인이 필요합니다.
출처: Microsoft Learn – Audit log activities
4단계: Slack은 메시지 보존, 앱 연결, audit logs를 같이 보기
Slack은 단순한 채팅 도구처럼 보이지만 실제로는 고객 대화, 내부 의사결정, 파일, 외부 협력사 채널, 자동화 알림이 모이는 곳입니다. Slack 공식 보안 페이지는 Slack이 audit logs, native DLP, Enterprise Key Management, 보존 정책, eDiscovery 같은 보안·거버넌스 기능을 제공한다고 설명합니다.
Slack Help의 audit logs 문서는 Enterprise 조직의 보안과 오용 방지를 위해 변경과 사용 기록을 볼 수 있고, CSV 내보내기와 Audit Logs API를 사용할 수 있다고 안내합니다.
출처: Slack Help – Audit logs in Slack
Slack을 새 SaaS와 연결하기 전에는 아래를 봅니다.
| 항목 | 검토 질문 |
|---|---|
| 앱 권한 | 새 앱이 어떤 채널과 파일에 접근하는가 |
| 외부 채널 | 고객사·외주와 공유되는 채널에 앱이 들어가는가 |
| 메시지 보존 | 보존 기간과 삭제 정책을 알고 있는가 |
| 게스트 | multi-channel guest와 외부 사용자를 구분했는가 |
| audit logs | 앱 설치, 권한 변경, 파일 다운로드를 추적할 수 있는가 |
| 알림 owner | 자동화 실패와 보안 알림을 누가 받는가 |
Slack은 자동화 도구와 연결될 때 특히 조심해야 합니다. Zapier나 Make가 Slack 메시지를 읽거나 특정 채널에 쓰도록 만들면 편하지만, 고객정보와 내부 파일 링크가 자동으로 다른 시스템으로 흘러갈 수 있습니다.
5단계: Dropbox는 외부 공유와 team activity를 먼저 확인하기
Dropbox를 새로 도입하거나 다른 SaaS와 연결할 때는 저장공간보다 공유 상태를 먼저 봐야 합니다. Dropbox Help는 Admin console의 Activity 섹션에서 팀 활동을 확인하고 보고서를 만들 수 있다고 안내합니다.
출처: Dropbox Help – View team activity in the admin console
Dropbox는 외부 공유 활동을 모니터링하고 외부 공유 콘텐츠를 관리하는 공식 문서도 제공합니다.
출처: Dropbox Help – Monitor team sharing activity
Dropbox 보안 검토표는 아래처럼 잡습니다.
| 항목 | 확인 질문 |
|---|---|
| team folder | 업무 문서가 개인 폴더에 남지 않는가 |
| external sharing | 외부 링크와 협력사 폴더를 제한할 수 있는가 |
| admin report | 다운로드, 공유, 로그인 활동 보고서를 볼 수 있는가 |
| guest access | 외부 사용자를 누가 초대하고 회수하는가 |
| 데이터 내보내기 | 해지 전 파일을 어디로 옮길 수 있는가 |
| 중복 도구 | Google Drive, OneDrive와 역할이 겹치지 않는가 |
파일 공유 운영 기준은 팀 파일 공유 보안 체크리스트와 함께 봐야 합니다. 새 SaaS가 Dropbox 파일을 가져가거나 링크를 만들 수 있다면 파일 보안 검토 대상입니다.
6단계: Atlassian은 Guard, audit log, data residency를 확인하기
Jira, Confluence, Bitbucket 같은 Atlassian 도구는 개발·프로젝트 기록이 오래 쌓입니다. Atlassian 공식 문서는 Atlassian Guard가 회사 전체 Atlassian 계정과 앱에 적용할 수 있는 가시성과 보안 설정을 제공한다고 설명합니다. SSO도 Guard의 주요 기능으로 안내됩니다.
출처: Atlassian Support – Understand Atlassian Guard
Atlassian은 data residency 문서에서 Atlassian Administration의 Data management, Data residency에서 앱의 데이터 위치를 볼 수 있다고 안내합니다.
출처: Atlassian Support – Understand data residency
Atlassian 검토 항목은 아래와 같습니다.
- Jira와 Confluence 중 어느 제품에 데이터가 들어가는가?
- 외주 개발자, 고객사, 파트너가 접근하는 프로젝트가 있는가?
- SSO, 2단계 인증, 사용자 프로비저닝이 필요한가?
- 감사 로그에서 조직 활동과 앱별 설정 변경을 볼 수 있는가?
- 데이터 리전과 보존 기준을 확인했는가?
- Marketplace app이 추가 데이터를 읽는가?
Atlassian은 업무 흐름이 깊게 들어가면 나중에 빼기 어렵습니다. 처음 도입할 때 프로젝트 접근권한, 외부 사용자, 앱 연결, 데이터 위치를 같이 검토해야 합니다.
7단계: Zapier와 Make는 자동화 연결 계정이 핵심이다
Zapier와 Make 같은 자동화 도구는 "작업을 줄여 주는 도구"이면서 동시에 여러 SaaS의 데이터를 이동시키는 통로입니다. Zapier Help는 SAML SSO가 Zapier 접근을 기존 identity provider와 연결하는 방식이라고 설명합니다.
출처: Zapier Help – Set up single sign-on with SAML
Zapier는 SCIM API로 팀원 provisioning과 de-provisioning을 관리할 수 있다고도 안내합니다.
출처: Zapier Help – Provision user accounts with SCIM
Make Help Center의 audit logs 문서는 조직·팀 수준에서 누가 무엇을 언제 변경했는지 볼 수 있고, 연결, webhook, key, team, data store, 2FA enforcement 같은 이벤트가 기록된다고 설명합니다.
출처: Make Help Center – Audit logs
자동화 도구 보안 검토표에는 아래를 넣어야 합니다.
| 항목 | 확인 질문 |
|---|---|
| 연결 계정 | 개인 Gmail, 개인 Slack이 연결되어 있지 않은가 |
| 데이터 흐름 | 어떤 SaaS에서 어떤 SaaS로 데이터가 이동하는가 |
| 비밀값 | API key, webhook URL, OAuth token을 누가 관리하는가 |
| owner | Zap, scenario, workflow owner가 퇴사하면 누가 넘겨받는가 |
| 로그 | 실패, 변경, 연결 재인증 기록을 볼 수 있는가 |
| 중단 절차 | 문제가 생기면 전체 자동화를 누가 끌 수 있는가 |
자동화 도구 선택 자체는 노코드 자동화 도구 비교에서 볼 수 있습니다. 이번 보안 검토에서는 기능 수보다 데이터 흐름과 연결 계정 owner가 더 중요합니다.
8단계: Notion 같은 문서 도구는 게스트, SSO, audit log를 분리해서 보기
문서 도구는 도입이 쉽지만 고객정보, 회의록, 내부 전략, 외부 공유 페이지가 한곳에 섞이기 쉽습니다. Notion Help는 audit log가 Enterprise 조직 owner에게 보안·안전 관련 활동 정보를 제공한다고 설명합니다.
Notion은 SAML SSO 설정 문서에서 Entra ID, Google, Okta, OneLogin 같은 identity provider 연동 절차를 안내합니다.
출처: Notion Help – Set up Identity Provider for SAML SSO
문서 도구 보안 검토에서는 아래를 확인합니다.
- 워크스페이스에 누구나 join할 수 있는 invite link가 켜져 있는가?
- 외부 게스트가 내부 문서 구조를 과하게 볼 수 있는가?
- 공개 페이지가 검색엔진에 노출될 수 있는가?
- SSO와 SCIM이 필요한 규모인가?
- 감사 로그와 보존 정책이 필요한 데이터인가?
- 퇴사자 계정의 페이지 소유권과 공유 권한을 회수할 수 있는가?
문서 도구는 "가볍게 메모만 하자"에서 시작해 팀 지식 저장소가 되기 쉽습니다. 고객정보나 계약 메모가 들어가는 순간부터는 파일 공유 도구와 같은 수준으로 검토해야 합니다.
새 SaaS 보안 검토표 예시
작은 팀은 아래 표를 그대로 복사해 구매 승인서에 붙여도 됩니다.
| 구분 | 기록할 내용 |
|---|---|
| 도구명 | 서비스명과 공식 URL |
| 요청 팀 | 사용할 팀과 담당자 |
| 서비스 owner | 운영 책임자 |
| backup admin | 비상 접근 담당자 |
| 데이터 종류 | 고객정보, 파일, 회의록, 자동화 연결 여부 |
| 연결 서비스 | Google, Microsoft, Slack, Dropbox, CRM, 결제 도구 |
| 인증 방식 | MFA, SSO, SCIM 가능 여부 |
| 권한 구조 | admin, member, guest, external user 구분 |
| 외부 공유 | 공개 링크, 게스트, 공유 페이지 제한 방법 |
| 로그 | 로그인, 파일, 앱 연결, 설정 변경 로그 확인 방법 |
| DLP·라벨 | 민감 데이터 보호 기능 여부 |
| 데이터 위치 | 리전, data residency, 하위 처리자 문서 확인 여부 |
| 해지·회수 | export, delete, ownership transfer 절차 |
| 30일 재검토 | 실제 사용량과 보안 설정 재점검일 |
이 표는 완벽한 보안 심사표가 아니라 "아무것도 안 보고 쓰기 시작하는 상황"을 막는 최소 장치입니다.
공개 전에 묻는 10가지 질문
SaaS 보안 검토를 길게 하기 어렵다면 마지막에 아래 10개 질문만이라도 묻는 편이 좋습니다.
- 고객정보나 내부 파일이 들어가는가?
- 개인 계정이 아니라 회사 계정으로 가입했는가?
- owner와 backup admin을 정했는가?
- MFA 또는 SSO를 적용할 수 있는가?
- 퇴사자·외주 계정을 회수하는 방법이 있는가?
- 외부 링크와 게스트 초대를 제한할 수 있는가?
- 앱 연결과 자동화 데이터 흐름을 설명할 수 있는가?
- 감사 로그나 활동 보고서를 볼 수 있는가?
- 해지 전 데이터를 내보내고 삭제할 수 있는가?
- 30일 후 계속 쓸지 다시 확인할 날짜가 있는가?
이 10개 질문에 답하지 못하면 구매나 유료 전환을 늦추는 것이 낫습니다. 특히 고객정보, 결제정보, 계약서, 내부 파일이 들어가는 도구라면 기능이 좋아 보여도 owner와 로그가 먼저입니다.
같이 보면 좋은 글
- SaaS 구매 승인 체크리스트
- 팀 SaaS 계정 권한 감사 체크리스트
- 팀 2단계 인증·SSO 체크리스트
- 팀 파일 공유 보안 체크리스트
- SaaS 결제수단·관리자 인수인계 체크리스트
- SaaS 갱신 캘린더 체크리스트
새 SaaS 보안 검토의 목표는 도구 도입을 막는 것이 아닙니다. 나중에 "누가 승인했는지", "어떤 데이터가 들어갔는지", "어떻게 끌 수 있는지"를 모르는 상태를 막는 것입니다. 작은 팀일수록 복잡한 정책보다 한 장짜리 검토표가 더 오래 갑니다.
About The Author
