보안 점검표

회사 안 서버에 자료를 두던 시절에는 확인할 것이 적었습니다. 도구를 사서 우리 기계에 설치하면 자료는 우리 건물 안에 있었고, 보안은 우리가 알아서 챌 문제였습니다. 그런데 웹으로 쓰는 제품을 쓰기 시작하면서 상황이 뒤집혔습니다. 우리 회사 계약서와 인사 자료가 남의 회사 서버에 올라가고, 그 회사가 그걸 어떻게 다루는지는 볼 수 없습니다.

그래서 고객사 보안 담당자는 매번 같은 곤란에 놓였습니다. 실무팀이 "이 도구 쓰겠습니다" 하고 올리면 승인해야 하는데 근거가 없었습니다. 영업 담당자에게 물으면 "보안은 철저합니다" 라는 답이 왔습니다. 그 말로는 사고가 났을 때 왜 승인했는지 설명할 수 없습니다. 담당자는 승인을 미루거나 반대했고, 조건이 다 맞은 거래가 이 자리에서 멈췄습니다.

보안 점검표는 그 대화를 문항으로 바꿉니다. 철저하냐고 묻는 대신 저장 위치가 어디인지, 오갈 때 암호화하는지, 직원 중 누가 고객 데이터를 볼 수 있는지를 하나씩 묻습니다. 답이 문서로 남으니 승인한 사람은 무엇을 근거로 승인했는지 댈 수 있고, 파는 쪽도 말을 바꿀 수 없습니다. 확인을 신뢰에서 기록으로 옮긴 장치입니다.

문항 수는 회사마다 다릅니다. 40개쯤인 곳도 있고 300개를 넘는 곳도 있습니다. 묻는 내용은 대체로 일곱 묶음입니다.

1. 조직과 정책 — 보안 책임자가 누구인지, 정책 문서가 있는지, 직원이 보안 교육을 받는지를 묻습니다. 회사가 이 일을 사람에게 맡겨 뒀는지 절차로 만들어 뒀는지를 보는 자리입니다.
2. 접근 통제 — 직원 중 누가 고객 데이터를 볼 수 있고, 그 권한을 언제 주고 언제 회수하는지입니다. 퇴사자 계정을 며칠 안에 지우는지 같은 문항이 여기 들어갑니다.
3. 데이터 저장 — 서버가 어느 나라에 있는지, 저장할 때와 오갈 때 암호화하는지, 백업을 어디에 얼마나 두는지입니다. 국내 고객사는 저장 위치를 특히 많이 봅니다.
4. 개발 보안 — 코드를 배포하기 전에 무엇을 확인하는지입니다. 애플리케이션 보안이 이 묶음의 이름으로, 코드와 서비스가 공격에 견디게 만드는 일 전반을 가리킵니다.
5. 사고 대응 — 유출이 생기면 몇 시간 안에 알리는지, 알리는 경로가 무엇인지입니다. 시간을 숫자로 적어야 하는 문항이라 답을 준비해 두지 않으면 막힙니다.
6. 협력사 — 우리가 쓰는 외부 서비스가 무엇이고 그쪽에 고객 데이터가 넘어가는지입니다. 고객 데이터를 다루는 하위 업체 명단을 요구하는 경우가 많습니다.
7. 인증 보유 — SOC 2나 ISMS-P 같은 인증이 있는지입니다. SOC 2 는 서비스 회사의 보안 통제를 외부 감사인이 검증하는 미국 기준이고 ISMS-P 는 국내 인증입니다. 인증이 있으면 관련 문항 상당수를 보고서 한 부로 대신할 수 있습니다.

문항은 대개 예·아니오와 설명을 함께 요구합니다. 아니오가 곧 탈락은 아닙니다. 언제까지 하겠다는 계획을 붙이면 넘어가는 경우가 많고, 아무 설명 없는 예가 오히려 검토자를 멈춰 세웁니다.

문서를 만드는 쪽은 고객사입니다. 정보보안 담당자가 사내 표준 양식을 들고 있고, 도입 검토가 올라오면 그것을 그대로 보냅니다. 그래서 같은 제품을 파는 우리가 고객사마다 다른 양식을 받습니다. 문항 절반은 어디서나 겹치고 나머지가 그 회사 사정에 따라 다릅니다.

채우는 쪽은 파는 쪽이지만 영업 담당자 혼자 할 수 없습니다. 답을 아는 사람이 개발과 보안이기 때문입니다. 세일즈 엔지니어가 이 일을 맡는 것이 보통입니다. 세일즈 엔지니어는 고객의 기술 질문에 답하고 제품을 시연하는 역할로, 지난 답변을 모아 둔 문서를 관리하면서 새 문항만 개발팀에 넘깁니다. 이 답변 모음이 없으면 같은 질문에 매번 처음부터 답하게 되고 한 번 주고받는 데 2주가 지나갑니다.

읽는 쪽은 셋입니다. 고객사 정보보안 담당자가 문항별로 답을 보고, 법무가 계약서의 보안 조항과 어긋나지 않는지 맞춰 보고, 구매가 승인 근거로 철해 둡니다. 세 사람이 보는 눈이 달라서 답변은 짧고 사실만 적는 쪽이 낫습니다. 설명이 길면 법무가 그 문장을 계약서에 넣자고 요구합니다.

"계약 조건은 다 맞췄고 보안 점검표 180문항만 남았습니다. 답변에 열흘 정도 걸릴 것 같습니다."

남은 절차가 무엇이고 며칠이 걸리는지 보고하는 말입니다.

"이 문항은 아직 아니오인데, 다음 분기에 적용 예정이라고 적어서 보냈습니다."

없는 것을 있다고 하지 않고 계획으로 넘기는 처리입니다.

"SOC 2 보고서 있으시면 이 묶음 스물세 문항은 건너뛰셔도 됩니다."

인증이 문항을 대신할 수 있다는 안내입니다.

페이지덱에서는 구성원 200명이 넘는 고객사와의 계약에서 거의 매번 이 문서가 옵니다. 수아가 받아 태오에게 넘기고, 태오는 답변 모음에서 찾아 채운 뒤 새 문항만 따로 표시합니다. 새 문항이 다섯 개를 넘으면 그 주에 규원까지 들어가는 회의를 한 번 잡습니다. 정책을 새로 정해야 하는 문항이 섞여 있기 때문입니다.

답변 모음은 반년에 한 번 손봅니다. 제품이 바뀌면 지난 답이 사실과 어긋나고, 그 상태로 제출하면 나중에 계약 위반으로 돌아옵니다.

형식적인 절차라서 대충 채워 보내면 넘어간다고 보는 경우가 많습니다. 문항이 많고 비슷한 것이 반복되니 그렇게 느껴집니다. 다만 읽는 쪽은 답변을 서로 맞춰 봅니다. 2번 묶음에서 권한을 엄격히 관리한다고 적고 6번 묶음에서 외부 업체 명단을 비워 두면 그 어긋남이 그대로 보입니다. 한 번 답이 미덥지 않다고 판단되면 그때부터 문항이 늘어나고, 처음 열흘이면 끝났을 절차가 한 달로 늘어납니다.

인증이 있으면 점검표는 안 채워도 된다고 보는 것도 흔합니다. 감사를 받은 보고서가 있으니 그것으로 갈음될 것처럼 보입니다. 하지만 인증이 대신하는 것은 겹치는 문항까지입니다. 그 고객사가 다루는 자료의 성격에서 나온 문항, 예를 들어 특정 국가에 자료를 두지 말아 달라는 요구는 어떤 보고서에도 답이 없습니다. 인증을 근거로 제출을 미루면 검토자는 우리가 답하기 어려운 문항을 피한다고 읽고, 남은 문항 검토가 더 까다로워집니다.