통제 항목
Control
개념
위험 하나를 줄이려고 정해 둔 개별 관리 조치로, 지켰는지 아닌지를 한 문장 단위로 확인할 수 있게 쪼개 놓은 것입니다.
등장 배경
기업 고객이 계약 전에 던지는 질문은 대개 "보안은 괜찮습니까" 한 줄입니다. 답하는 쪽에서는 난감합니다. 괜찮다고 말하면 근거가 없고, 무엇을 하고 있는지 늘어놓으면 듣는 쪽이 그게 충분한지 판단할 기준이 없습니다. 서버에 암호를 걸었다는 말과 퇴사자 계정을 정리한다는 말은 종류가 다른데 한 자리에 섞여 나옵니다.
실제로 이런 대화가 계약을 몇 달씩 붙잡아 두곤 했습니다. 고객사 보안 담당자가 스무 개쯤 되는 질문지를 보내면 받은 쪽은 질문마다 관련된 사람을 찾아다니며 답을 모읍니다. 같은 질문이 다음 고객에게서 또 오고 그때마다 처음부터 다시 모읍니다.
통제 항목은 이 문제를 쪼개는 방식으로 풀었습니다. 보안이라는 큰 말 대신 지켰는지 아닌지로 갈리는 문장 수십 개로 나눕니다. 퇴사자 계정을 마지막 근무일에 잠근다, 운영 데이터베이스 접근은 두 사람의 승인을 받는다처럼 적습니다. 이렇게 두면 답이 달라집니다. 괜찮다는 주장 대신 항목 100개 중 몇 개를 어떻게 지키고 있는지가 나오고, 고객은 자기가 중요하게 보는 항목만 골라 확인할 수 있습니다.
작동 방식
위험 하나에 조치 하나를 붙여 문장으로 적고, 그 문장이 지켜졌는지를 주기마다 확인합니다. 한 항목은 보통 다섯 가지를 담습니다.
- 막으려는 위험입니다. 퇴사자가 퇴사 후에도 데이터를 볼 수 있는 상황처럼, 실제로 일어나면 곤란한 일을 먼저 적습니다.
- 실제로 하는 조치입니다. 마지막 근무일에 모든 시스템 계정을 잠근다처럼 행동으로 적습니다. 노력하겠다는 표현은 확인할 수 없어 쓰지 않습니다.
- 주기입니다. 사건이 생길 때마다 하는 것인지 분기마다 하는 것인지를 정합니다. 주기가 없으면 언제 안 지켰는지도 정할 수 없습니다.
- 책임자입니다. 이 항목이 지켜지는지 보는 사람을 한 명으로 지정합니다. 팀 이름으로 적으면 아무도 보지 않습니다.
- 남는 기록입니다. 조치를 했다는 것을 나중에 보여 줄 수 있는 흔적이 어디에 어떤 형태로 남는지 적습니다.
항목은 성격에 따라 세 갈래로 나뉩니다. 일이 생기지 않게 막는 쪽, 생긴 일을 알아채는 쪽, 알아챈 다음 처리하는 쪽입니다. 권한을 필요한 사람에게만 주는 것은 막는 쪽, 접속 기록으로 이상한 접근을 찾아내는 것은 알아채는 쪽, 사고가 났을 때 몇 시간 안에 누구에게 알릴지 정해 둔 절차는 처리하는 쪽입니다. 셋이 다 있어야 하는 이유는 막는 것만으로는 뚫렸을 때 알 방법이 없기 때문입니다.
확인하는 방법도 둘로 갈립니다. 사람이 분기마다 목록을 열어 보는 방식과 시스템이 자동으로 막거나 기록하는 방식인데, 뒤쪽이 낫습니다. 사람이 분기마다 점검하는 항목은 그 사이 석 달이 비어 있지만, 승인 없이는 접근이 되지 않게 막아 두면 어긴 순간이 없습니다. 감사 자리에서도 사람이 옮겨 적은 표보다 시스템이 남긴 기록이 훨씬 강하게 인정됩니다.
쓰이는 곳
인증을 준비할 때, 새 도구나 기능을 붙일 때, 고객의 보안 질문지에 답할 때 이 단위로 일합니다.
첫째, 인증 준비의 기본 단위입니다. SOC 2나 ISO 27001, 국내의 ISMS-P 같은 제도는 수십에서 백여 개의 항목을 묶은 기준표를 주고, 회사는 항목마다 우리는 이렇게 한다를 적어 냅니다. 제도가 여럿이어도 묻는 내용은 절반 넘게 겹칩니다. 그래서 두 번째 인증은 훨씬 빠르고, 어느 항목이 어느 항목에 해당하는지 대응표를 만들어 두면 같은 자료를 형식만 바꿔 냅니다.
둘째, 새 시스템을 붙일 때 확인 목록으로 씁니다. 기능을 만들 때마다 보안을 처음부터 고민하지 않고 이미 정해 둔 항목 중 어디에 걸리는지를 봅니다. 외부 업체의 도구를 붙인다면 협력사 보안 점검이 따라붙습니다. 고객 데이터가 그 업체로도 흘러가기 때문에 우리가 지키기로 한 항목을 그쪽도 지키는지 확인해 둬야 합니다.
셋째, 고객 질문지에 답하는 자리입니다. 항목이 정리돼 있으면 스무 개짜리 질문지가 며칠이 아니라 한두 시간 일이 됩니다. 질문 대부분이 이미 가진 항목의 다른 표현이기 때문입니다.
실무 용례
"이 항목은 분기 점검으로 잡혀 있는데 자동으로 막는 쪽으로 바꾸죠."
사람이 주기적으로 확인하는 대신 시스템이 상시로 막게 해서 빈 구간을 없애자는 제안입니다.
"그 기능은 새 통제 항목이 필요합니다. 기존 목록에 걸리는 게 없어요."
지금 정해 둔 조치로는 이번 변경에서 생기는 위험을 덮지 못한다는 뜻입니다.
"항목은 있는데 증적이 없어요. 심사에서는 없는 걸로 봅니다."
정해 두고 실제로 지켰더라도 보여 줄 기록이 남지 않으면 인정되지 않는다는 말입니다.
페이지덱이 첫 기업 고객을 받으면서 태오가 맡은 일이 이 목록을 만드는 것이었습니다. 시작은 문서가 아니라 질문이었습니다. 운영 데이터베이스에 접근할 수 있는 사람을 세어 보니 열한 명이었고 그중 넷은 반년 넘게 들어간 적이 없었습니다. 접근 권한은 분기마다 검토해 쓰지 않는 계정을 회수한다는 문장이 그 자리에서 만들어지고, 넷을 회수한 기록이 첫 증적이 됐습니다.
규원이 이 목록을 볼 때 확인하는 것은 개수가 아닙니다. 항목마다 책임자가 한 사람으로 적혀 있는지, 그리고 지난 분기에 실제로 돈 흔적이 있는지입니다. 이름이 비어 있거나 기록이 없는 항목은 목록에는 있지만 회사에는 없는 항목입니다.
흔한 오해
문서를 쓰면 통제가 생긴다고 여기는 경우가 가장 많습니다. 인증 준비가 문서 작업으로 시작되고, 정책 문서를 다 쓰고 나면 일이 끝난 것처럼 보이기 때문입니다. 그러나 심사원이 보는 것은 문서가 아니라 그 문장대로 움직인 흔적입니다. 접근 권한을 분기마다 검토한다고 적어 두고 지난 네 분기 동안 검토한 기록이 없으면, 항목이 없는 것보다 나쁜 상태가 됩니다. 하겠다고 적어 놓고 안 한 것이라 지적이 그대로 남습니다.
항목이 많을수록 안전하다고 읽는 것도 흔합니다. 목록이 길면 꼼꼼해 보이고, 기준표에 있는 항목을 전부 가져다 붙이고 싶어집니다. 하지만 지키지 못하는 항목은 위험을 줄이지 않으면서 지켜야 할 것만 늘립니다. 실제로 준비가 늦어지는 회사는 항목이 모자라서가 아니라, 감당할 수 있는 양을 넘겨 적어 두고 절반만 도는 상태로 심사를 맞는 경우가 많습니다. 우리 위험에 맞는 항목을 고르고 그것만 확실히 돌리는 편이 낫습니다.
자주 헷갈리는 용어
| 용어 | 무엇인가 | 통제 항목과의 차이 |
|---|---|---|
| 증적 | 정해 둔 조치를 실제로 지켰다는 것을 보여 주는 기록 | 항목은 하기로 한 약속이고 증적은 한 결과입니다. 심사에서 항목은 목록으로 제출하고 증적은 기록으로 제출하며, 둘 중 하나만 있으면 인정되지 않습니다 |
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16