[티로] SOC 2 Type 2 인증 취득 안내

티로가 SOC 2 Type 2 인증을 취득했습니다. 미국 공인회계사회(AICPA) 기준에 따라 미국 감사법인 Sensiba LLP가 티로의 보안 통제를 감사했고, 티로는 다섯 개 신뢰 서비스 기준 전체에 대해 적정의견을 받았습니다.

앞서 ISO/IEC 27001:2022 인증을 안내드리며, 티로는 인증을 취득 시점의 성과가 아니라 지속적인 개선의 과정으로 본다고 말씀드렸습니다. 이번 인증은 그 다음 단계입니다.

지난 안내에서 티로가 고객 데이터를 어떻게 보호하는지에 대해 설명드렸습니다. 음성은 처리 후 즉시 폐기하고, 고객의 대화를 AI 모델 학습에 쓰지 않으며, 저장과 전송 구간을 모두 암호화하고, 최소 권한 원칙으로 접근을 제한하고, 모든 접근과 변경을 기록한다는 내용이었습니다.

이 설명은 티로가 스스로 밝힌 운영 방식입니다. 이번에 달라진 것은, 같은 내용을 티로가 아니라 외부 감사인이 확인했다는 점입니다. 그것도 특정 시점의 설계가 아니라 감사 기간 내내 실제로 그렇게 운영되었는지를 확인했습니다.

보안에서 가장 어려운 부분은 통제를 만드는 일이 아니라 그것이 매일 지켜지고 있음을 증명하는 일입니다. 문서에 적힌 대로 운영되는 통제와 문서에만 남아 있는 통제의 차이는 평소에 드러나지 않다가 사고가 났을 때 한꺼번에 드러납니다. SOC 2 Type 2는 그 간극을 감사합니다.

Type 1과 Type 2는 무엇이 다른가

SOC 2에는 두 가지 유형이 있습니다.

Type 1은 설계를 봅니다. 특정 시점을 기준으로 통제가 적절하게 설계되어 있고 실제로 존재하는지를 평가합니다. 접근 권한 정책이 마련되어 있는지, 배포 승인 절차가 정의되어 있는지, 백업 체계가 갖춰져 있는지를 확인하는 방식입니다. 스냅샷에 가깝습니다.

Type 2는 운영을 봅니다. 설계에 더해, 정해진 감사 기간 내내 그 통제가 실제로 작동했는지까지 평가합니다. 정책이 있는지가 아니라 그 정책이 지난 몇 개월 동안 매번 지켜졌는지를 묻습니다.

이 차이는 검증 방식에서 분명하게 드러납니다. 감사인은 정책 문서를 읽는 것으로 끝내지 않고, 감사 기간에 실제로 일어난 일에서 표본을 뽑습니다. 그 기간에 부여되고 회수된 접근 권한, 프로덕션에 반영된 코드 변경, 수행된 백업과 복구 시험, 탐지되고 처리된 보안 이벤트를 하나씩 꺼내어 통제가 정해진 대로 작동했는지 대조합니다. 표본 중 하나라도 통제를 벗어나면 그 사실이 예외 사항으로 보고서에 그대로 기록됩니다.

결과물도 다릅니다. Type 2 감사의 산출물은 인증서 한 장이 아니라, 통제마다 감사인이 무엇을 시험했고 결과가 어땠는지가 적힌 감사 보고서입니다. 고객의 보안 검토 담당자는 이 문서를 직접 읽고 자사의 점검 항목에 하나씩 대조할 수 있습니다. 통과 여부를 전달받는 것이 아니라 판단의 근거를 넘겨받는 방식입니다.

이 점이 ISO/IEC 27001과 SOC 2가 서로를 대체하지 못하는 이유이기도 합니다. ISO 27001이 정보보호 관리체계라는 틀이 국제 표준에 부합하는지를 인증한다면, SOC 2 Type 2는 그 틀 안의 개별 통제가 특정 기간 동안 어떻게 작동했는지를 증거와 함께 서술합니다. 하나는 체계의 적합성을, 다른 하나는 운영의 이력을 증명합니다.

다섯 개 기준을 모두 적용한 이유

SOC 2는 다섯 개의 신뢰 서비스 기준(Trust Services Criteria) 가운데 적용 범위를 선택할 수 있습니다. 필수 항목은 보안 하나뿐이고, 나머지 네 개는 서비스의 성격에 따라 선택합니다. 많은 기업이 보안 하나만, 또는 여기에 한두 개를 더해 감사를 받습니다.

티로는 다섯 개 전체를 적용했습니다. 회의와 대화를 기록하는 서비스에서는 각 기준이 모두 고객의 실제 걱정과 맞닿아 있기 때문입니다. 각 기준이 무엇을 보는지, 그리고 티로 같은 서비스에서 그것이 무엇을 의미하는지 하나씩 설명드립니다.

1. 보안(Security) — 시스템이 무단 접근으로부터 보호되는가

다섯 개 기준의 토대가 되는 공통 기준입니다. 물리적·논리적 접근 통제, 변경 관리, 위험 평가, 이상 탐지, 사고 대응, 위탁업체 관리까지 정보보호의 기본 골격 전체가 여기에 포함됩니다.

회의록에는 조직의 의사결정, 고객과의 대화, 내부 논의, 앞으로의 계획이 담깁니다. 단일 문서 한 건이 유출되는 것과 회의 기록 전체에 접근할 수 있게 되는 것은 피해의 규모가 다릅니다. 그래서 티로에서 보안은 "고객 데이터에 닿을 수 있는 경로를 몇 개까지 줄였는가"의 문제이고, 감사인이 시험한 것도 그 경로마다 통제가 걸려 있었는지, 그리고 그 통제가 감사 기간 내내 유지되었는지였습니다.

2. 가용성(Availability) — 약속한 수준으로 서비스를 쓸 수 있는가

시스템이 합의된 수준으로 운영되고 접근 가능한지를 봅니다. 모니터링, 장애 대응, 백업과 복구 시험, 용량 관리가 여기에 해당합니다.

회의 기록 서비스에서 가용성은 다른 서비스와 성격이 조금 다릅니다. 대부분의 서비스는 장애가 끝나면 하려던 일을 다시 할 수 있지만, 회의는 다시 열리지 않습니다. 그 순간 기록되지 않으면 그 대화는 복구할 방법이 없습니다. 고객이 티로를 켜고 회의를 시작하는 순간, 티로는 그 회의를 놓치지 않을 책임을 함께 맡습니다. 가용성을 감사 범위에 넣은 것은 그 책임을 외부 검증의 대상으로 두겠다는 뜻입니다.

3. 처리 무결성(Processing Integrity) — 처리가 완전하고 정확하게 이루어지는가

시스템의 처리가 완전하고, 정확하며, 적시에 이루어지고, 승인된 범위에서 수행되는지를 봅니다. 데이터가 안전하게 보관되었는지가 아니라, 그 데이터를 다루는 처리 자체가 제대로 되었는지를 보는 기준입니다.

회의록은 만들어진 순간보다 나중에 더 자주 쓰입니다. 몇 주 뒤 의사결정의 근거로 인용되고, 참석하지 않은 사람에게 회의의 유일한 기록으로 전달됩니다. 그때 원본과 다른 내용이 담겨 있다면 그것은 편의 기능의 오류가 아니라 신뢰의 문제입니다. 회의 기록 서비스에서 결과의 정확성은 보안만큼 중요한 신뢰의 조건이며, 처리 무결성을 감사 범위에 포함한 것은 그 판단에 따른 결정입니다.

4. 기밀성(Confidentiality) — 기밀 정보가 지정된 범위 안에서만 다뤄지는가

기밀로 지정된 정보가 정해진 범위 안에서만 접근되고, 보유 기간이 끝나면 안전하게 폐기되는지를 봅니다. 개인정보인지 여부와 관계없이, "이 정보는 제한된 범위에서만 다뤄져야 한다"고 지정된 모든 정보가 대상입니다.

회의 내용의 상당수는 개인정보가 아니지만 기밀입니다. 아직 공개되지 않은 계획, 진행 중인 계약 조건, 조직 내부의 논의가 그렇습니다. 이런 정보는 유출뿐 아니라 사내에서 의도보다 넓게 공유되는 것만으로도 문제가 됩니다. 그래서 기밀성 기준에서는 노트의 공유 범위가 설정한 대로 지켜지는지, 권한이 회수되면 접근도 함께 끊기는지, 하위 처리자에게 전달되는 범위가 계약으로 제한되어 있는지, 그리고 보유 기간이 지난 데이터가 실제로 폐기되는지를 봅니다.

5. 개인정보 보호(Privacy) — 개인정보가 고지한 대로 다뤄지는가

개인정보의 수집, 이용, 보관, 제공, 폐기가 고지한 내용과 일치하게 이루어지는지를 봅니다. 다섯 개 기준 중 유일하게 별도의 개인정보 처리 원칙 체계를 함께 따르는 기준입니다.

회의 기록 서비스에서 개인정보는 계정 정보에 그치지 않습니다. 참석자의 이름, 음성, 발언 내용 자체가 개인정보에 해당할 수 있고, 그중에는 티로와 직접 계약하지 않은 외부 참석자의 정보도 포함됩니다. 기밀성이 "누가 볼 수 있는가"를 본다면, 개인정보 보호는 "무엇을 위해 수집했고, 고지한 목적을 벗어나지 않았으며, 요구가 있을 때 열람과 삭제가 실제로 이행되는가"를 봅니다. 고객의 대화를 AI 모델 학습에 사용하지 않는다는 원칙 역시 이 기준 아래에서 감사인의 확인 대상이 됩니다.

감사 결과

감사 보고서에는 다섯 개 기준 모두가 티로 시스템에 적용 가능하며 제외된 기준이 없다는 점이 명시되어 있습니다. 티로는 통제의 설계뿐 아니라 감사 기간 동안의 운영 효과성까지 포함해 적정의견(Unqualified Opinion)을 받았고, 감사 기간 종료 시점을 기준으로 최근 12개월간 서비스에 중대한 보안 사고가 발생하지 않았다는 사실도 보고서에 함께 기재되어 있습니다.

증거가 남는 방식으로 운영한다는 것

감사를 통과하려면 통제가 있는 것만으로는 부족하고, 그 통제가 작동했다는 기록이 남아 있어야 합니다. 티로가 인증 준비를 문서를 갖추는 일이 아니라 운영을 증거가 남는 방식으로 다시 설계하는 일로 접근한 이유입니다.

1. 운영 환경과 개발 환경을 계정 단위로 분리했습니다. 개발 환경에서는 고객 데이터에 접근할 수 없고, 계정 사이의 경계는 조직 차원의 정책으로 강제됩니다. 덕분에 팀은 고객 데이터와 완전히 격리된 환경에서 자유롭게 실험할 수 있습니다.

2. 모든 계정의 감사 로그를 별도의 보안 계정 한 곳으로 모읍니다. 로그는 암호화되어 저장되고 위변조 여부를 검증할 수 있으며, 로그를 생성하는 쪽과 보관하는 쪽의 권한을 분리해 사고 시 로그가 지워지지 않도록 했습니다.

3. 프로덕션으로 가는 코드에는 반드시 승인이 필요합니다. 주 브랜치로 직접 반영하는 경로를 차단하고, 승인 없는 병합은 플랫폼이 기술적으로 막습니다. 어떤 코드를 누가 검토해야 하는지도 저장소마다 지정되어 있습니다.

4. 인프라의 대부분을 코드로 관리합니다. 티로 서비스 전체 인프라의 약 80%가 IaaC(Infrastucture as a Code)로 정의되어 있어 모든 변경이 코드 리뷰를 거치고 이력이 남습니다. 같은 구성을 언제든 재현할 수 있다는 점 자체가 운영이 통제되고 있다는 증거가 됩니다.

5. 상시 탐지와 기기 통제를 함께 운영합니다. 클라우드 환경의 위협 탐지와 취약점 검사, 웹 방화벽이 24시간 동작하고, 구성원의 업무용 기기와 계정은 단일 인증 체계와 관리 도구로 통제됩니다.

이 통제들의 상태는 컴플라이언스 플랫폼을 통해 상시 점검되며, 설정이 기준에서 벗어나면 감사 기간이 아니어도 즉시 드러납니다.

인증 이후에도 계속되는 것

SOC 2 Type 2는 지난 감사 기간에 대한 평가입니다. 다음 기간의 신뢰는 다음 기간의 운영 기록으로만 증명됩니다.

티로는 외부 보안 전문 기업인 티오리(Theori), 카오스랩스(KAOS Labs)와 계약해 정기적으로 침투 테스트를 수행하고 있습니다. 표면적인 점검이 아니라 소스 코드와 인프라 구성까지 열람할 수 있는 조건으로 진행하며, 발견된 취약점은 조치하고 재점검합니다. 또한 CIS Controls v8.1, NIST AI RMF, NIST CSF에 대한 통제 매핑을 완료해, 하나의 정보보호 관리체계 위에서 여러 프레임워크를 함께 운영하고 있습니다.

보안 환경은 계속 변하고 있습니다. 최근 여러 사례들에서 살펴볼 수 있듯 AI 모델의 성능이 빠르게 발전하면서 보안 위협 역시 더 정교해지고 있으며, 티로는 이러한 변화에 맞춰 서비스 인프라와 운영 체계를 지속적으로 점검하고 있습니다.

앞으로도 티로는 고객이 안심하고 회의를 기록하고 활용할 수 있도록, 보안 리스크를 지속적으로 점검하고 더 안전한 서비스 환경을 만들어가겠습니다.

Tiro Trust Center

티로는 Trust Center를 통해 취득한 인증과 준수 프레임워크, 서브프로세서 목록을 공개하고 있습니다. SOC 2 감사 보고서 원문에는 감사인이 수행한 통제별 시험 절차와 결과가 담겨 있어, 비밀유지계약 체결 후 신뢰 센터의 요청 절차를 통해 제공해 드리고 있습니다.

보안 검토나 벤더 심사를 진행 중이시라면 신뢰 센터에서 필요한 자료를 요청하시거나, partners@theplato.io로 문의해 주세요.

인증 정보

감사 보고서 전문은 비밀유지계약 체결 후 Tiro Trust Center에서 요청하실 수 있습니다.

앞으로도 티로는 고객이 안심하고 회의를 기록하고 활용할 수 있도록, 보안 리스크를 지속적으로 점검하고 더 안전한 서비스 환경을 만들어가겠습니다.