'ISMS'에 해당되는 글 8건

최근 국내외 보안 사고의 상당수는 기업 내부가 아닌 외부 협력사, 위탁사, 서비스 제공자를 경유해 발생하고 있다. 클라우드 서비스, SaaS, 외주 개발, 운영 위탁 등 공급망 구조가 복잡해지면서 서드파티(Third Party)는 기업 보안 수준을 결정하는 핵심 요소가 되었다. 이에 따라 정보보안 및 개인정보보호 관점에서 체계적인 서드파티 리스크 관리가 필수적인 관리 영역으로 자리 잡고 있다.

서드파티 리스크 관리란 기업이 거래·계약 관계에 있는 외부 조직이 보유·처리·접근하는 정보자산으로 인해 발생할 수 있는 보안 및 개인정보 침해 위험을 식별, 평가, 통제하는 일련의 관리 활동을 의미한다. 이는 단순한 계약 관리가 아니라 정보보호 관리체계(ISMS) 및 개인정보 보호 관리체계(ISMS-P)의 핵심 통제 요소 중 하나로 다뤄진다.

ISMS 및 ISMS-P에서는 외부자 및 외부위탁 관리에 대해 명시적으로 요구사항을 제시하고 있다. ISMS 기준에서는 외부자 보안, 외부위탁 시 정보보호 요구사항 정의 및 이행 점검을 요구하며, ISMS-P에서는 개인정보 처리 위탁 시 수탁자 관리·감독, 재위탁 통제, 안전성 확보 조치를 필수적으로 요구한다.

실무적으로 서드파티 리스크 관리는 다음 단계로 수행된다.

• 서드파티 식별 및 분류
  모든 외부 협력사를 동일하게 관리하는 것은 현실적으로 불가능하다. 개인정보 처리 여부, 중요 정보 접근 여부, 시스템 연계 수준 등을 기준으로 고위험·중위험·저위험 서드파티로 분류하는 것이 일반적이다.
  이는 개인정보 보호법 제26조의 위탁 개념 및 ISMS 위험 기반 접근 방식과 일치한다.
• 사전 보안성 검토 및 평가
  신규 계약 또는 시스템 연계 이전에 보안성 평가를 수행한다. 보안 정책 보유 여부, 접근통제, 로그 관리, 암호화 적용 여부, 침해사고 대응 체계 등을 체크리스트 또는 설문 방식으로 확인한다.
  공공기관의 경우 KISA 개인정보 영향평가 가이드와 보안성 검토 지침을 참고하는 사례가 많다.
• 계약 및 법적 통제 수단 확보
  보안 및 개인정보 보호 요구사항은 반드시 계약서에 명시되어야 하며, 기술적·관리적 보호조치, 사고 발생 시 책임, 재위탁 제한, 점검 권한 등을 포함해야 한다.
  개인정보 보호법 시행령 제28조의 위탁 관련 조항은 계약서 반영의 법적 근거가 된다.
• 운영 중 모니터링 및 정기 점검
  계약 체결 이후에도 정기적인 보안 점검, 증적 제출 요구, 현장 점검 또는 서면 점검을 통해 통제를 유지해야 한다. 고위험 서드파티의 경우 연 1회 이상 점검이 권장된다.
  이는 ISMS-P 심사 시 주요 확인 항목으로 활용된다.
• 사고 대응 및 종료 관리
  서드파티에서 보안 사고 또는 개인정보 유출이 발생할 경우 보고 체계, 공동 대응 절차, 계약 해지 및 접근권한 회수까지 포함한 종료 프로세스가 사전에 정의되어 있어야 한다.

실무 가이드

서드파티 리스크 관리는 단순히 심사 대응을 위한 형식적 문서 관리가 아니라, 실제 사고 예방과 책임 최소화를 위한 실질적 통제 수단이다. 특히 개인정보 유출 사고 발생 시 위탁 여부, 관리·감독의 적정성은 기업의 법적 책임 판단에 직접적인 영향을 미친다.

최근 ISMS-P 심사에서는 서드파티 목록의 완전성, 위험 기반 분류의 타당성, 점검 결과에 따른 후속 조치 여부까지 종합적으로 확인하는 경향이 강화되고 있다. 따라서 보안 담당자와 개인정보보호 담당자는 계약·구매·사업 부서와의 협업 체계를 구축하고, 전사 관점의 서드파티 관리 프로세스를 수립할 필요가 있다.

정리

공급망 보안 환경에서 서드파티 리스크 관리는 선택이 아닌 필수 관리 영역이다. 위험 기반 분류, 사전 평가, 계약 통제, 운영 중 점검, 사고 대응까지 전 주기를 포괄하는 관리 체계를 구축해야 한다. 이는 ISMS-P 준수뿐 아니라 실제 보안 사고 예방과 기업 신뢰도 유지를 위한 핵심 기반이 된다.

최근 발표된 ISMS-P 인증심사 강화 방안을 보면서 개인적으로 여러 가지 생각이 들었습니다. 제도의 취지와는 별개로, 실제 현장에서 이 방안들이 얼마나 현실적으로 작동할 수 있을지에 대해서는 다소 의문이 드는 부분들이 있기 때문입니다.

우선 가장 기본적인 전제부터 짚고 싶습니다. ISMS는 기술보안 수준을 평가하는 제도가 아니라 정보보호 관리체계에 대한 인증심사입니다. 조직에 정보보호 관리체계가 수립되어 있는지, 그 체계가 문서로만 존재하는 것이 아니라 실제로 운영되고 있는지, 그리고 계획한 활동들이 일관되게 이행되고 있는지를 확인하는 것이 ISMS 심사의 본질입니다. 취약점 점검이나 모의해킹 역시 마찬가지입니다. 중요한 것은 점검을 얼마나 고도화된 방식으로 수행했는지나 몇 개의 취약점을 찾아냈는지가 아니라, 점검 계획을 수립했고 그 계획에 따라 점검을 수행했으며, 도출된 위험을 어떻게 관리하고 있는지입니다. 즉 기술 그 자체보다는 관리체계 관점에서의 계획, 이행, 개선 여부가 핵심입니다.

그럼에도 불구하고 이번 강화 방안에서는 심사 과정에서 취약점 점검이나 모의해킹을 직접 수행하겠다는 내용이 포함되어 있습니다. 이 부분은 담당자 관점에서 여러 가지 현실적인 고민을 낳습니다. 심사 과정에서 해당 활동을 수행한다면, 심사 전에 비용을 들여 동일한 점검을 진행해야 할 당위성은 자연스럽게 약해질 수밖에 없습니다. 심사 비용은 분명 증가할 가능성이 높은데, 그렇다면 심사에서 수행할 점검과는 별도로 사전에 또 한 번 취약점 점검이나 모의해킹을 진행할 기업이 과연 얼마나 될지 의문입니다. 결국 기업 입장에서는 어차피 한 번은 심사 과정에서 수행하게 될 활동에 대해 두 번 비용을 지출해야 하는 구조가 될 수 있습니다.

또 하나의 현실적인 문제는 조치 기간이 긴 취약점에 대한 이행점검입니다. 실무를 해보면 취약점 조치가 단기간에 끝나지 않는 경우가 훨씬 많고, 이 때문에 외부 컨설팅 계약을 할 때도 심사 이후 이행점검을 계약 범위에 포함시키는 경우가 일반적입니다. 그렇다면 심사와 함께 수행되는 취약점 점검에서 과연 이행점검까지 책임지고 이어질 수 있을지에 대해서는 여전히 의문이 남습니다.

모의해킹과 관련해서는 우려가 더 큽니다. 기존에도 모의해킹은 운영환경에서 수행하는 것을 권고해 왔던 만큼, 심사 시 진행되는 모의해킹 역시 운영환경에서 수행하려는 방향으로 갈 가능성이 높습니다. 이 과정에서 모의해킹 중 서비스 장애가 발생하거나 실제 서비스에 문제가 생겼을 경우, 그 책임과 손해배상은 누가 부담하게 될까요. 국가가 책임을 져주는 것도 아닐 텐데, 이에 대한 명확한 기준이나 보호장치 없이 심사 과정에 모의해킹을 포함시키는 것은 현업 담당자에게 상당한 부담으로 다가옵니다. 개인적으로는 이러한 취약점 점검이나 모의해킹은 ISMS 인증심사와는 분리하여 별도의 제도나 심사로 운영하는 것이 더 적절하다고 생각합니다.

또 하나 짚고 싶은 부분은 기존의 서면 및 샘플링 중심 심사에서 코어시스템 중심의 현장실증 심사로 강화하겠다는 방향입니다. 취지 자체는 이해하지만, 현실적으로 가능한지에 대해서는 의문이 듭니다. 최초 인증 기준으로 심사기간이 5일이라고는 하지만 실제로는 첫날 서비스 설명, 마지막 날 결과 정리와 보고서 작성, 4일차 오후 결함 초안 정리 등을 감안하면 실질적인 심사 시간은 2.5일에서 3일 정도에 불과합니다. 이 제한된 시간 안에서 샘플링을 넘어 강화된 점검을 한다는 것은 사실상 모든 것을 다 본다는 의미로 해석될 수밖에 없는데, 과연 이게 가능할지 의문입니다.

심사원 입장에서도 부담은 큽니다. 저 역시 온프레미스 환경과 AWS 환경 위주로 업무를 해왔기 때문에, Azure나 GCP가 메인 서비스인 기업을 심사하면서 구체적인 기술 구현까지 깊이 있게 점검하는 것은 쉽지 않습니다. 모든 심사원이 모든 기술 스택에 대해 동일한 수준의 이해를 갖는 것은 현실적으로 불가능하며, 그럼에도 불구하고 기술 중심 점검을 강화한다면 심사의 일관성과 형평성 문제로 이어질 가능성도 충분히 있습니다.

요즘의 흐름을 보면 ISMS는 보안 관리가 체계적으로 이루어지고 있는지를 샘플링을 통해 검증하는 제도임에도 불구하고, 마치 모든 기술적 보안 수준이 완벽해야만 통과할 수 있는 심사처럼 인식되고 있는 것 같습니다. ISMS는 어떤 항목이 샘플링 대상이 될지 모르기 때문에 결국 모든 영역을 체계적으로 준비하게 만드는 제도이지, 모든 기술 구현의 완성도를 요구하는 심사는 아닙니다. 그럼에도 클릭 수를 높이기 위한 자극적인 보도나 정책 실패를 지적하기 위한 일부 언론과 정치권의 시선에 주무부처인 과학기술정보통신부나 개인정보보호위원회가 지나치게 끌려가고 있는 것은 아닌지, 개인적으로는 그런 우려도 듭니다.

ISMS-P 인증심사 강화의 취지 자체를 부정하는 것은 아닙니다. 다만 제도의 본질과 현장의 현실을 함께 고려하지 않으면, 결국 인증을 받는 기업과 이를 준비하는 담당자, 그리고 심사를 수행하는 심사원 모두에게 부담만 가중되는 방향으로 흘러갈 가능성이 크다고 생각합니다. 앞으로 구체적인 세부 방안이 어떻게 마련될지 지켜보면서, 현업에 실질적인 도움이 되는 방향으로 제도가 정착되기를 기대해 봅니다.

많은 IT 기반 스타트업이 빠르게 성장하며 임직원 100~150여 명을 넘어서는 순간, 자연스럽게 ISMS(정보보호관리체계) 인증 심사 의무 대상자가 됩니다. 이때부터 기업은 본격적으로 정보보안 조직 구성 또는 담당자 채용을 고민하게 되죠.

보안을 업으로 하는 사람으로서, 사실 사업 초기부터 보안조직이 꾸려졌으면 하는 바람이 있습니다. 실제로 임직원 30명 남짓의 초기 단계부터 보안조직을 갖춘 스타트업을 경험하기도 했습니다. 하지만 이는 흔치 않은 경우이며, 대부분의 기업은 성장을 거듭한 후에야 비로소 보안의 중요성을 실감하게 됩니다.

현실적인 보안조직 구성, 몇 명부터 시작해야 할까?

물론 인원이 많을수록 좋다는 것은 부인할 수 없는 사실입니다. 회사가 커질수록 보안 업무는 기하급수적으로 늘어나니까요. 하지만 규모가 작더라도 필수적으로 운영해야 할 솔루션, 인증, 대외 협력 업무 등이 있기 때문에 1인 체제는 현실적으로 어렵습니다.

최소한의 인원 구성은 3명입니다. 이는 조직장 1명, 기술보안 담당자 1명, 관리보안 담당자 1명을 의미합니다. 이 3명은 각각의 영역을 담당하면서도 서로 유기적으로 협력해야 합니다. 만약 조금 더 회사의 보안 수준을 강화하고 이를 내재화하고자 한다면 5명 정도가 필요합니다. 5명이 된다면 두 개의 팀으로 분리해 업무를 전문화하는 것도 좋은 방법이 될 것입니다.

이때 중요한 점은, 적은 인원으로 효율적인 조직을 운영하기 위해 각각의 구성원이 최소한 5년 차 이상, 가능하다면 8년 차 이상의 경력을 가진, 자율적으로 업무를 이끌어갈 수 있는 역량을 갖춘 인재여야 한다는 것입니다.

조직의 역할과 포지션 확장 방안

이 정도 규모의 기업에서 조직장이 조직 관리만 하는 것은 현실적으로 불가능합니다. 조직장 역시 한 명의 실무자가 되어야 하며, 동시에 모든 업무를 아우르는 큰 그림을 그릴 수 있어야 합니다.

조직장의 경력에 따라 다르겠지만, 솔루션 운영과 같이 손이 많이 가는 세부 업무보다는 정보보호 기획, 규정, 컴플라이언스 관리와 같은 전략적인 업무를 조직 관리와 병행하는 것이 효과적입니다.

가장 필수적인 두 개의 포지션은 '기술보안(솔루션 운영 관리)' 담당자와 '관리보안' 담당자입니다. 이 두 포지션을 중심으로 조직을 확장해 나가는 것을 추천합니다.

기술보안 영역의 확장

초기에는 정보보호 솔루션 운영 업무에 집중합니다. 그러나 기업이 성장함에 따라 다음과 같이 역할과 전문성을 확장해야 합니다.

• 웹/앱/클라우드 보안 담당: 비즈니스 서비스의 안정성을 확보하기 위해 웹 애플리케이션 방화벽(WAF), 소스코드 보안 약점 분석(SAST), 침투 테스트 등을 담당합니다. 클라우드를 적극적으로 사용한다면 클라우드 환경의 보안 취약점을 관리하고 CSPM(Cloud Security Posture Management) 같은 솔루션을 도입·운영해야 합니다.
• 인프라/네트워크 보안 담당: 사내 IT 인프라와 네트워크의 안전성을 책임집니다. 방화벽, 침입방지시스템(IPS), 서버 보안 솔루션 등을 관리하고, 시스템 취약점을 분석하고 보완하는 업무를 수행합니다.
• 보안관제(SOC) 및 위협 분석 담당: 침해사고에 대한 24시간 모니터링 및 분석을 전담합니다. 보안정보 및 이벤트 관리(SIEM) 솔루션을 활용해 이상 징후를 탐지하고, 최신 위협 정보를 분석하여 조직의 방어 체계를 강화합니다.

관리보안 영역의 확장

인증 취득 또는 유지 업무를 시작으로 관리보안은 다음과 같이 세분화하고 전문화될 수 있습니다.

• 법규 및 컴플라이언스 관리 담당: ISMS-P, 개인정보보호법, 전자금융거래법 등 국내외 보안 법규를 준수하는 역할을 맡습니다. 법규 개정에 따른 내부 규정을 업데이트하고, 관련 부서와 협력하여 정책을 적용하는 업무를 수행합니다.
• 개인정보보호 및 프라이버시 담당(CPO): 개인정보의 수집, 이용, 파기 등 라이프사이클 전체를 관리합니다. **개인정보영향평가(PIA)**를 수행하고, 유출 사고 예방 및 대응 계획을 수립합니다. 개인정보보호 교육을 기획하고 진행하는 역할도 담당합니다.
• 보안 감사 및 리스크 관리 담당: 보안 정책 및 절차의 준수 여부를 정기적으로 점검하고, 보안 시스템의 운영 현황을 평가합니다. 내/외부 감사를 총괄하고, 기업의 비즈니스 목표에 영향을 미칠 수 있는 보안 리스크를 식별하고 평가하는 업무를 수행합니다.

보안팀의 성공적인 안착을 위한 조건

성공적인 보안조직 구성을 위해서는 단순히 인력 충원을 넘어, 조직 문화와 협업 체계를 함께 구축해야 합니다.

1. 보안은 모두의 책임이라는 인식 제고: 보안팀이 단순히 규제나 통제를 강요하는 부서가 아니라, 비즈니스가 안전하게 성장할 수 있도록 돕는 파트너라는 인식을 조직 전체에 심어주는 것이 중요합니다. 개발, IT 인프라, 사업 부서와 정기적인 소통 채널을 마련하여, 보안이 비즈니스를 지원하는 핵심 가치임을 증명해야 합니다.
2. 측정 가능한 성과 지표(KPI) 설정: 보안 업무의 성과를 객관적으로 증명하기 위해 **보안 지표(Security KPI)**를 설정하고 관리해야 합니다. 예를 들어, 취약점 패치율, 보안 교육 이수율, 침해사고 발생 건수, 보안 솔루션 도입 및 운영 성과 등을 지표로 삼아 보안팀의 기여도를 가시화할 수 있습니다.
3. 지속 가능한 성장 모델 구축: 보안 조직은 급변하는 IT 환경과 위협에 대응하기 위해 끊임없이 학습하고 발전해야 합니다. 구성원들이 최신 기술과 트렌드를 습득할 수 있도록 교육 지원, 세미나 참여, 기술 공유 문화 등을 조성하는 것이 필수적입니다. 또한, 새로운 보안 솔루션 도입이나 기술적 위험 평가를 통해 선제적으로 위험에 대응하는 역량을 키워야 합니다.

마무리하며...

스타트업의 보안조직은 단순히 규제 준수를 넘어, 기업의 성장과 비즈니스 연속성을 위한 필수적인 투자입니다. 최소한의 인원으로 시작하되, 각 구성원의 전문성과 역량을 최대한 활용하고, 전사적인 협업 문화를 구축하는 것이야말로 스타트업의 성공을 위한 중요한 열쇠가 될 것입니다.

저는 10년 넘는 시간동안 중소기업에서 보안 업무를 맡아온 보안 담당자입니다. 중소, 중견, 대기업 계열사, 자회사 참 많은 기업을 경험했는데요 최근 '우리나라 보안이 체크리스트 점검 방식에 치중되어 있다'는 기사를 보았는데, 너무나 공감하면서도 한편으로는 씁쓸함을 감출 수 없었습니다. 오늘은 솔직한 제 경험을 바탕으로, 왜 많은 보안 담당자들이 '체크리스트'에 매달릴 수밖에 없는지 이야기해 보려 합니다.

1. 보안은 '비용'인가, '투자'인가?

보안 업계에서는 늘 "보안은 투자의 개념으로 봐야 한다"고 말합니다.
하지만 현실의 경영진들은 보안을 여전히 '비용'으로 인식하는 경우가 많습니다.
'사고가 났을 때 더 큰 손해를 막는 것'이라는 논리도, "아직 사고 난 적 없는데? 그동안 쓴 돈은 다 낭비였던 거 아니야?"라는 한마디에 힘을 잃습니다.

이런 인식은 자연스럽게 인력 충원이나 솔루션 도입에 인색한 결과로 이어집니다. 최소한의 인원으로, 최소한의 예산으로 최대의 효과를 내야 하는 현실 속에서 '진정한 보안 강화'는 늘 후순위로 밀려납니다.

2. 고립된 섬, 보안팀

보안 담당자들은 내부 직원들에게서도 이중적인 시선을 받습니다.
"보안팀 때문에 일 못하겠다"는 불만은 일상다반사입니다.
같은 동료들을 못 믿는다는 오해를 받기도 합니다.
하지만 정작 사고가 발생하면 모든 책임은 보안팀에게 돌아옵니다.
평소에는 협조에 소극적이다가도, 문제가 터지면 '보안팀은 도대체 뭘 한 거냐'는 비난을 듣는 것이 우리의 현실입니다.

3. 규제와 현실 사이의 간극

규제 기관은 모든 기업에 일원화된 잣대를 들이밉니다.
심지어 클라우드 환경에서 "사설 IP가 고정되어 있지 않다"며 ISMS 인증 심사에서 지적하는 심사원을 이해시키느라 반나절을 보낸 적도 있습니다.
기술적 특성을 고려하지 않은 채, 자신들의 좁은 지식 안에서 획일적인 규제를 적용하려는 시도는 현장에서 큰 어려움을 낳습니다.

4. 체크리스트에 매달릴 수밖에 없는 이유

이런 상황에서 모든 규제는 '체크리스트'와 '증적' 제출을 요구합니다. 
법에서 요구하는 증적을 제대로 갖추지 못하면 과태료는 물론, 언론 기사로 인해 회사 이미지에 큰 타격을 입게 됩니다.

따라서 보안 담당자의 최우선 과제는 더 이상 '회사의 보안 수준 향상'이 아닙니다.
'규제기관의 요구사항을 잘 맞추는 것'이 되어버렸습니다.
1~2명의 보안 담당자가 대부분인 중소기업에서는 법적 증적을 만드느라 한 달, 일 년이 훌쩍 지나갑니다.
정말 필요한 보안 활동은 야근을 감수해야만 간신히 해낼 수 있는 상황입니다.

이것은 기업의 '보안 불감증'과 '타이트한 규제'가 만들어낸 안타까운 결과라고 생각합니다.
타이트한 법규는 있고, 인력과 시간은 부족하니, 결국 '법 조항을 체크리스트로 만들어서 그것만이라도 지키자'는 선택을 할 수밖에 없는 것입니다.

마치며

저는 이 문제가 해결되려면, 경영진에 대한 정기적인 보안 교육이 의무화되고, 기업의 규모나 특성에 맞는 유연한 규제가 필요하다고 생각합니다. 언젠가 보안 담당자가 단순히 체크리스트를 채우는 사람이 아닌, 기업의 핵심 경쟁력을 지키는 '보안 전문가'로 존중받는 날이 오기를 바라봅니다.

SKT 가명정보 정지처분 취소 소송에 대해 대법원이 “가명정보 처리 시 정보주체의 동의를 받을 필요가 없다”고 최종 판단했다는 소식은, 정보보안담당자로서도 깊이 고민할 수밖에 없는 주제입니다.

가명정보는 개인정보보호법에 의해 일정 수준의 보호는 받되, 정보주체의 직접 식별이 어렵도록 처리된 데이터입니다. 이 가명정보를 동의 없이 활용할 수 있다는 대법원의 판단은, AI나 데이터 산업 발전을 뒷받침하는 측면에서 분명 의미 있는 진전입니다.

저 역시 가명정보의 활용이 미래 기술 경쟁력 확보에 매우 중요하다는 점에는 전적으로 동의합니다. 그리고 **기밀성(confidentiality)**과 가용성(availability) 중, 민감정보나 고유식별정보를 제외한 대부분의 정보에 대해서는 가용성을 더 중요하게 생각하는 보안담당자의 입장에서도 이 판결을 무조건 부정하지는 않습니다.

하지만 한 가지, 간과되어선 안 될 문제가 있습니다.

분석 현장에서의 현실: 재식별 위험은 정말 통제되고 있는가?

제가 직접 근무했던 회사, 그리고 ISMS 인증 심사를 위해 방문했던 여러 기업들의 사례를 돌아보면, 가명정보를 활용하는 부서가 '재식별 가능성'을 원천 차단한 상태에서 업무를 수행하는 경우는 거의 드물었습니다.

예를 들어,

• 분석 대상 데이터와 보유 중인 원본 데이터의 연결 가능성
• 분석 환경에서의 접근 통제 미흡
• 업무 편의성 등을 이유로 한 최소한의 비식별 조치

이런 상황이 복합적으로 작용하면서, 실제로는 “형식상 가명처리”된 데이터가 “사실상 준식별정보”로 운용되는 경우도 적지 않았습니다.

정보주체의 권리와 책임의 균형

그렇기 때문에, 이번 판결이 “가명정보이기만 하면 동의 없이 자유롭게 활용할 수 있다”는 일방적인 면책의 근거로 사용되는 상황이 우려스럽습니다. 특히나,

• 데이터가 수집된 맥락
• 정보주체의 자기결정권
• 활용 범위의 명확성

이런 요소들이 고려되지 않고, 단지 기술적 ‘가명처리’가 되어 있다는 이유만으로 정보주체의 동의권이 원천 배제된다면, 이는 개인정보 보호법이 말하는 ‘균형 있는 보호와 활용’에서 벗어나는 것이 아닐까요?

활용을 위한 보안이 아닌, 보안을 위한 활용으로

우리는 기술의 진보를 위해 ‘활용’을 이야기하지만, 그것은 언제나 신뢰를 전제로 해야 합니다.

가명정보의 활용을 장려하고 싶다면,

• 재식별 방지를 위한 엄격한 보안통제
• 분석환경의 설계와 분리
• 조직의 책임 있는 데이터 거버넌스

이런 것들이 먼저 실현되어야 하지 않을까 생각합니다.

마무리하며

이 판결을 부정하려는 것은 아닙니다. 다만 현장의 경험과 현실적 위험을 고려할 때, 가명정보 활용의 전면적 자유화에는 신중함이 필요하다고 느껴집니다.
보안은 자유를 제한하기 위한 것이 아니라, 자유를 지속 가능하게 하기 위한 기반입니다. 이 점을 모두가 함께 기억해주었으면 합니다.

※ 이 글은 ChatGPT를 통해 초안을 작성하였으나, 보안 및 개인정보보호 분야 실무자의 검수를 거쳐 게시한 글입니다.
     환각 효과나 허위 정보에 대한 우려는 하지 않으셔도 됩니다.

※ 참고. ChatGPT를 통해 정리한 본 사건의 개요

보안 = ISMS?

그 인식이 스타트업을 위험하게 만든다

(본 글은 ChatGPT를 통해 작성했으나 충분한 검수를 거쳤기 때문에 환각효과에 대한 우려는 하지 않으셔도 됩니다)

스타트업에서 정보보안 담당자로 일하면서 자주 듣는 말이 있습니다.
“ISMS 인증 통과했잖아요. 더 이상 보안은 안 해도 되는 거 아닌가요?”

이 질문이 처음엔 단순한 오해로 들리다가, 시간이 지나면서 문제의 본질이 보이기 시작했습니다.
보안을 'ISMS 인증'으로만 이해하는 시각이 기업 전체의 보안 리스크를 키우고 있다는 사실입니다.

ISMS는 ‘시작’이지 ‘끝’이 아니다

ISMS 인증은 정보보호 관리체계를 일정 수준 이상 갖췄다는 형식적인 증명일 뿐입니다.
그 자체가 보안을 완성해주는 만능 도구는 아닙니다.

하지만 많은 조직, 특히 스타트업에서는 ISMS를 마치 졸업장처럼 여기곤 합니다.
이 때문에 아래와 같은 왜곡된 인식이 생깁니다.

• 인증범위에 포함된 시스템만 관리하면 된다
• 내부 시스템은 인증범위 밖이므로 신경 쓰지 않아도 된다
• 외부에서 문제가 되지 않으면 내부 문제는 중요하지 않다
• 감사나 심사에 걸리지 않으면 괜찮다

결국, 형식은 갖췄지만 실질적 보안 수준은 제자리, 심지어는 오히려 약해질 수도 있습니다.

보안은 인증이 아니라 리스크 기반 의사결정이다

보안의 본질은 인증서가 아니라, 기업의 위험을 어떻게 인식하고 통제할 것인가입니다.

• 인증 범위에 포함되지 않은 내부 개발시스템에서 취약점이 발견되면?
• 사내 도구나 백오피스 시스템에서 개인정보가 유출되면?
• 협력사와 API 연동된 서비스에서 인증은 받았지만 실제 통제가 되지 않으면?

이런 리스크는 ISMS 심사 대상이 아니어도 실제 사고로 이어질 수 있습니다.

실제로 많은 스타트업은 보안 조직이 작은 반면, 개발 속도는 매우 빠릅니다.
그러다보니 ISMS로 체크되지 않는 영역은 무방비로 방치되는 경우가 많습니다.

인증은 보안을 위한 최소 기준일 뿐, ‘면죄부’가 아니다

많은 스타트업에서 보안 리소스가 한정적이다보니
“ISMS 인증 받았으니, 이제 보안은 끝났다”는 유혹에 빠지기 쉽습니다.

하지만 현실은 정반대입니다.
ISMS는 보안을 위한 시작점이며, 그 이상으로 확장되지 않으면 오히려 리스크를 고착화시킬 수 있습니다.

• 인증심사에서 지적되지 않더라도 실제 해커는 그 경계를 구분하지 않습니다
• 인증 범위 밖의 시스템이 공격당하면, 결국 전체 서비스 신뢰가 무너집니다
• 인증은 외부 신뢰를 위한 증표, 내부 신뢰를 위한 노력은 별도로 필요합니다

스타트업 보안 담당자가 할 수 있는 3가지

1. 보안 범위의 재정의
   • 인증 범위 중심이 아닌, 전체 서비스 흐름과 데이터 흐름 기준으로 보안 범위 재설정
2. 임직원 인식 개선
   • “ISMS는 인증이지만, 보안은 업무”라는 메시지를 지속적으로 전달
   • 특히 경영진 대상 브리핑에서 “ISMS는 시작일 뿐”임을 반복 설명
3. 리스크 기반 우선순위 수립
   • 내부 시스템이라도 개인정보·인증정보 처리 등 위험도가 높은 자산을 선제 관리
   • 인증과 무관하게 로그, 접근권한, 암호화 등의 기본 보안 조치 시행

마무리하며

보안을 ‘ISMS 인증’에만 기대는 것은 시험공부만 하고 진짜 실무는 손도 안 대는 상황과 다르지 않습니다.

ISMS는 외부에 보여주기 위한 기준일 수 있지만, 보안은 내부를 지키기 위한 실제 활동입니다.

스타트업이 성장할수록, 보안의 역할은 더 커지고 ‘형식’보다 ‘실질’에 집중해야 진짜 안전을 확보할 수 있습니다.

이 글은 ChatGPT를 통해 작성되었으나 충분한 검수를 거쳤기 때문에 환각효과에 대한 우려는 하지 않으셔도 괜찮습니다.

최근 SKT 유심 해킹 사고 이후 또다시 정보보호 인증 제도의 실효성에 대한 논란이 일고 있습니다. 마치 ISMS 인증을 받은 기업이라면 이런 사고가 절대 발생하지 않아야 한다는 기대가 깔린 듯합니다. 그러나 ISMS 인증은 완벽한 보안을 보장하는 제도가 아닙니다.

세줄 요약

• ISMS 인증은 '최소한의 정보보호 체계'를 갖추었는지에 대한 확인이지, '완전한 보안'을 인증하는 것이 아님
• 인증을 통해 중소기업·중견기업의 보안 수준이 실질적으로 향상된 것은 부인할 수 없음
• 기업 맞춤형 완전보안 인증을 하려면 수개월 소요되는 PIA 수준의 검토가 필요하나, 현실적으로 불가능에 가까움

인증제도의 본질: 최소 기준을 정립하는 것

ISMS 인증의 목적은 기업이 정보보호 관리체계를 ‘갖추었는가’를 객관적으로 평가하는 것입니다. 이는 ‘보안 사고가 나지 않을 것이다’라는 보장이 아닌, 기본적인 보안 거버넌스, 정책, 조직, 기술적 통제 수준을 최소한 이상으로 구성했는가에 대한 판단입니다.

쉽게 말해, 건물의 내진설계 기준을 충족했다고 해서 지진 피해가 0이 되는 건 아닌 것처럼, ISMS 인증은 ‘기본방어선’을 갖췄는지를 판단하는 기준선일 뿐입니다.

ISMS, 중소기업 보안 수준을 끌어올린 숨은 공신

실제로 ISMS 인증 제도가 본격화되기 전, 다수의 중소·중견 기업은 보안 문서도 없고 권한관리도 느슨하며 로그 점검조차 하지 않는 환경이 많았습니다. 그러나 인증 요건에 따라 관리체계를 수립하고 보호조치를 도입하면서 기업 전반의 보안 수준이 상승한 것은 누구도 부인할 수 없습니다.

많은 기업들이 "인증 준비가 아니었다면 여전히 USB로 민감정보를 옮기고 있었을 것"이라는 말을 할 정도로, ISMS는 보안의 시작선 역할을 해내고 있습니다.

PIA 수준의 정밀한 심사? 현실적 어려움이 크다

누군가는 말합니다.
“진짜 실효성 있는 인증이 되려면 몇 달 동안 해당 기업의 시스템을 정밀 진단해야 하는 것 아니냐?”고.

맞는 말입니다. 하지만 그러한 인증 방식은 개인정보영향평가(PIA)처럼 몇 달의 시간이 소요되고, 해당 기업의 업무 이해, 조직문화, 기술적 구성 요소 등 전반에 걸친 밀착 분석이 필요합니다.

이는 대기업 몇 곳에 한정적으로나 가능한 수준의 정밀 심사이며, 수천 개의 기업이 동시에 인증을 준비하고 갱신하는 현실에서는 적용이 거의 불가능합니다. 인증 비용과 인력 자원, 시간 모두에서 막대한 부담이 발생하기 때문입니다.

인증의 진짜 가치는 '기준'에 있다

ISMS 인증의 가치는 ‘무결함 보안’의 증명이 아닌, 공통의 기준을 마련하고 이를 통해 기업 스스로 보안의 흐름을 체계화하는 데 있습니다. 인증을 통해 보안의 언어를 맞추고, 기본적인 조치가 누락되지 않도록 시스템화한다는 점에서 실효성은 분명합니다.

물론 앞으로는 인증 기준을 더욱 정교화하고, 인증 기업의 사후 관리 강화도 함께 논의되어야 할 것입니다. 그러나 그 전에도 분명히 말할 수 있는 것은 “인증이 없던 시절보다 훨씬 더 나아졌다”는 사실입니다.

마무리하며

보안 사고는 아무리 잘 준비된 조직에서도 발생할 수 있습니다. 그러나 그 가능성을 줄이고, 사고의 여파를 최소화하려면 기본 체계가 반드시 필요합니다. ISMS 인증은 완벽함의 증거가 아니라, 바로 그 ‘기본 체계’를 갖췄다는 작은 증표입니다. 그리고 그 작은 증표는, 우리 보안 생태계에 아주 큰 변화를 만들어내고 있습니다.

이 글을 검색해서 들어오신 분이시라면

올해 ISMS와 PIMS가 통합된다는 소식은 들으셨을 겁니다.

구체적인 내용은 발표되지 않았지만 통합만큼은 확정되었죠...

저와 함께 공부하던 사람들한테 통합때문에 시험이 없지 않을까라고 얘기는 했지만

그게 정말 현실이 되어버렸네요...

2018년에는 ISMS 및 PIMS 인증심사원 자격검정이 없습니다.

다만, 기존 심사원들의 자격 통합만 진행될 예정이라고 합니다.

자세한 내용은 KISA ISMS 홈페이지의 공지사항을 확인하시면 되겠습니다.

공지사항 바로가기