GDPR의 데이터 보호 개념과 정의

비록 데이터 보호법이 수십 년 동안 존재했음에도 불구하고, 근본적인 개념 중 일부는 아직 논란의 여지가 있다. 기술 분야의 발전과 기업 운영 방식의 변화는 종종 가장 근본적인 데이터 보호 개념의 정의에 대한 유연성을 테스트하게 된다. 그럼에도 불구하고 1995년 Data Protection Directive에 의해 수립된 핵심 데이터 보호 개념은, 자주 제기되는 문제 중 일부를 명확히 하기 위한 제한적인 수정안과 함께 GDPR에서도 본질적으로 동일하다.

예를 들어, 개인의 온라인 행동에 관한 프로필을 생성하기 위해 인터넷 프로토콜(IP) 주소 및 쿠키를 사용하면 IP 주소 및 쿠키가 개인 데이터인지 여부에 대한 광범위한 논쟁이 있었다. 이 문제는 명시적으로 온라인 식별자가 포함된 개인 데이터의 새로운 정의에서 다루어 졌다. 핵심 개념에 대한 또 다른 도전은 아웃소싱의 성장과 서비스 제공 업체의 자율 수준 향상이었다. 입법자들은 컨트롤러와 프로세서 사이의 경계에 대한 의문점에도 불구하고 이 정의를 변경하지 않기로 결정했다.

이번 글에서는 개인 데이터, 특수 범주 또는 민감한 개인 데이터, 컨트롤러, 프로세서 및 처리에 대한 GDPR의 핵심 데이터 보호 개념을 살펴본다.

개인 데이터

개인정보 또는 개인 데이터(오래전에는 데이터(Data)와 정보(Information)을 가공여부에 따라 다르게 보았고, 지금도 여전히 그런 해석을 적용하기도 하지만, 개념적으로나 실무적으로 개인정보와 개인 데이터는 동일하게 본다.)의 개념은 데이터 보호법의 핵심이며, 그 정의는 의도적으로 광범위하다. 이것은 기술이 진화함에 따라 해석상의 어려움을 야기했다. 그럼에도 불구하고 개인 데이터 개념에 대해 제29조 작업반(WP29)이 2007년 6월 ‘Opinion 4/2007’에서 규정한 개인 데이터 정의의 4가지 구성 요소는 GDPR에서 동일하게 유지되며, 그래서 WP29의 견해는 개인 데이터의 정의를 이해하는 데 여전히 중요하다.

유럽 연합 당국은 식별 가능한 개인에 관한 모든 정보를 포함하도록 개인 데이터의 개념에 대해 광범위하게 규정하기를 지향했다. 이 정의는 전체적으로 미국의 많은 주 데이터 침해 법령보다 훨씬 광범위하다. 이를 바탕으로 개념은 상당한 양의 정보를 포함한다. 심지어 그러한 정보와 식별 가능한 개인 간의 연관성이 희박한 경우에도 마찬가지이다.

GDPR에서 ‘개인 데이터’의 정의는 다음과 같다.

Opinion 4/2007에서 WP29는 개인 데이터의 의미를 구성하는 아래 4개의 구성 요소를 설정했다.

모든 정보(any information)

‘정보’ 개념의 3가지 측면은 정보가 개인 데이터로 간주될 시기를 정의하는 데 도움이 된다. 이것들은 본질, 내용 그리고 형식이다.

본질

개인에 관한 모든 유형의 서술(객관적이든 주관적이든)은 개인 데이터로 간주될 수 있다. 예를 들어, 고용주가 직원에 대해 가지고 있는 고용 기록에는 여러 유형의 객관적 및 주관적 서술이 포함될 수 있다. 객관적인 서술의 예로는 ‘[직원]이 컴퓨터 과학 학위를 가지고 있다’ 또는 ‘[직원]이 IT 부서의 책임자이다’라는 것들이다. 주관적인 서술은 누군가의 의견이나 평가를 표현하는 것이다. 주관적인 서술의 한 예는 ‘[직원]은 좋은 일꾼이며 승진을 원한다’이다.

참고로, 개인정보로 간주되기 위해 정보가 사실일 필요는 없다.

내용

개인 데이터의 내용은 모든 종류의 정보를 포함하며 개인의 사생활 및 가족생활에 대한 좁은 해석을 의미하는 정보에 국한되지 않는다. 유럽 연합 법원(CJEU)은 개인 및 가족생활의 개념을 널리 해석해야 한다고 규정했다. 따라서 개인정보에는 개인의 사생활 및 개인이 수행한 활동에 대한 정보가 포함된다. 이 활동은 개인의 개인 생활만큼이나 전문직 또는 공공 분야의 활동과 관련될 수 있다. 개인의 근무지 연락처 정보는 집 주소 또는 개인 전화번호와 동일한 방식으로 개인 데이터가 된다. Recital 30에서는 IP 주소, 쿠키 또는 무선 주파수 태그와 같은 ‘온라인 식별자’를 구성하는 정보를 사용하여 개인의 프로필을 만들고 식별하여 개인 데이터로 간주되는 콘텐츠의 범위를 보여준다.

형식

개인 데이터의 개념에는 어떤 형태로든 사용할 수 있는 정보가 포함된다. GDPR은 자동화된 방법으로 처리된 정보에 명시적으로 적용되지만 제2조 (1)항은 ‘서류 정리 시스템의 일부분’에 대해서도 수동 수단으로 처리하는 것을 포함한다. 예를 들어, 정보는 교육 목적을 위해 전화 통화를 기록하는 여행사의 고객 서비스 부서에서 보관된 테이프, 사람의 전자 은행 기록을 기록하는 컴퓨터의 메모리, 병원 클리닉의 이력 종이, 또는 CCTV에 기록된 이미지를 포함한다. Recital 15는 GDPR이 기술 중립적인 의도로 작성되었음을 명확히 하지만, ‘서류 정리 시스템’이 수작업으로 처리될 때는 불분명하다.

관련성(relating to)

개인 데이터가 되려면 정보가 개인에 대한 것이어야 한다. 개인과 정보 간의 관계가 항상 쉽게 성립되는 것은 아니다. 정보가 개인과 관련이 있는지 여부는 분명하지 않다.

객체, 프로세스 또는 이벤트와 관련된 정보는 특정 상황에서 개인정보를 구성할 수 있다. 예를 들어, 객체는 개인에 속할 수 있다(예: 개인이 자동차를 소유). 소유주가 일부 세금을 납부할 의무가 있는지 여부를 판단하기 위해 소유자의 자산으로 간주되는 경우, 자동차 구매 가격에 대한 정보는 개인 데이터일 수 있다. 자동차의 기술적 정보(예: 마일리지 또는 고장 횟수)는 소유자에게 청구서를 발행할 목적으로 정비소에서 처리하는 경우 개인정보로 간주될 수 있다.

Opinion 4/2007에서 WP29는 또한 개인 데이터가 개인에 관련이 되려면, ‘내용’ 요소, ‘목적’ 요소 또는 ‘결과’ 요소의 3가지 요소 중 하나가 적용되어야 한다고 간주했다.

‘내용’ 요소는 정보가 가장 일반적인 의미의 개인에 관한 정보일 때 존재한다. 예를 들어, 시험 성적은 학생과 분명히 관련된다. ‘목적’ 요소의 존재 여부는 특정 방식으로 개인을 평가, 고려 또는 분석하기 위해 정보가 처리되는지 여부에 달려 있다. ‘결과’ 요소는 특정 정보의 처리가 개인의 권리와 이익에 영향을 미칠 때 존재한다.

이러한 요소를 누적해서 적용할 필요는 없다. 그러나 동일한 정보도, 다른 개인과 관련하여 다른 요소를 기반으로 하는 개인 데이터일 수도 있고 아닐 수도 있다.

식별되거나 식별 가능성(identified or identifiable)

Opinion 4/2007에서 WP29는 자연인이 아직 식별되지는 않았지만 그것을 할 수 있을 때, ‘식별 가능’하다고 말한다. 사람은 이름으로 직접 식별될 수 있지만 식별 번호나 IP 주소와 같이 간접적으로 식별될 수도 있다.(우라 나라에서도 IP 주소를 개인정보로 판단한 판례가 있다) 또한 ‘다른 정보 조각들과 결합된 정보도, 해당 정보 조각들을 데이터 컨트롤러가 보유하는지 여부에 상관없이, 개인을 타인과 구별할 수 있게 하기’ 때문에 개인은 식별될 수 있다. WP29에서 제공하는 예는 웹 트래픽 감시 도구를 사용하여 컴퓨터의 동작과 컴퓨터 뒤의 사용자를 식별할 수 있다. 그 근거에 따르면, ‘개인’의 개성은 어떤 결정을 그 사람의 것으로 간주하기 위해 함께 조합된다’.

정보 수집 및 결합을 가능하게 하는 낮은 저장 비용과 초고속 프로세싱에 따른 빅데이터의 등장으로 이러한 유형의 퍼즐 맞추기 식의 직소 식별이 가능해지고 식별 가능성 요소가 데이터 컨트롤러에 대한 과제로 대두되고 있다. 그렇다면 식별 가능성의 한계점은 어디까지일까? 이것에 대한 가이드가 다음과 Recital 26에 나와 있다.

따라서 신원 확인에 대한 가상의 가능성만으로는 충분하지 않고, 정보를 식별하게 만드는 데 충분한 합리적인 가능성이어야 한다. WP29는 개인을 구별할 가능성이 없거나 무시할 수 있을 때, 그 사람을 식별할 수 있는 것으로 간주해서는 안 되며, 그 정보는 개인 데이터가 아니라고 인식했다.

일부 컨트롤러들은 특정 요소는 식별 가능한 개인과 연결되면 개인 데이터가 될 수도 있지만, 데이터 세트에 있는 개인의 대부분을 식별할 가능성이 없다면, 데이터 세트는 개인 데이터를 구성하지 않는다고 주장해왔다. 일반적인 시나리오는 CCTV(closed-circuit television)를 사용하는 것으로, 식별은 수집된 자료 중 극소수에서만 발생한다. 그러나 WP29는 이 정보가 개인정보로 취급되어야 한다는 입장을 항상 견지하고 있다. 왜냐하면 처리의 근본 목적은 개인이 필요하다고 생각할 때 개인을 지목하고 식별하는 것이기 때문이다. 처리 목적이 정확하게 그(것)들을 식별하는 것이라는 측면에서, 개인을 식별할 수 없다고 주장하는 것은 용어상의 모순일 것이다.

CJEU는 식별 가능성의 넓은 범위를 확인하였고, 특정 상황에서 동적 IP 주소가 개인 데이터를 구성할 수 있다고 판결했다. 패트릭 브레이어(Patrick Breyer) 대 독일연방공화국(Bundesrepublik Deutschland) 사건에서 독일 연방 사법 재판소는 해적당(Pirate Party) 당원 패트릭 브레이어가 제기한 사건에 대해 CJEU에 2가지 질문을 제기했다. 그는, 독일 연방 정부가 운영하는 웹 사이트의 각 연결에 대해 기기에 새로운 번호가 할당되도록 한 경우에도, 웹 사이트의 데이터를 올바른 수신자에게 전송할 수 있도록 기기의 동적 IP 주소를 수집하고 사용하는 것에 대해 문제를 제기하였다. 정부는 이러한 행위를 범죄 예방, 특히 서비스 거부 공격으로 정당화했다.

그러나 CJEU는 동적 IP 주소가 인터넷 서비스 제공 업체(ISP)가 보유한 데이터와 연결되는 시간과 같은 ‘간접적으로 식별될 수 있는’ 개인정보를 구성할 수 있다는 견해를 가지고 있다. 제3자가, 웹사이트 제공자가 보유하고 있는 동적 IP 주소와 함께 사용되어 웹사이트 사용자를 식별할 수 있는 정보를 보유한 환경에서, 그러한 IP 주소가 개인 데이터를 구성한다고 판단했다. 이 경우 연방 정부는 그러한 추가 정보를 얻기 위해 제3자로서 자연스럽게 ISP에 가게 되고, 독일 법은 사이버 공격이 발생하는 경우 합법적으로 이를 수행할 수 있는 메커니즘을 제공했기 때문에, 다양한 정보의 조각이 개인을 식별할 수 있도록 조합되는 가능성이 생겼다.

한 가지 중요한 점은 데이터의 익명성에 관한 것이다. GDPR은 익명의 정보, 즉 식별되거나 식별 가능한 자연인과 관련이 없는 정보이거나, 데이터 주체가 더 이상 식별할 수 없도록 익명으로 처리된 개인 데이터에는 적용되지 않는다.

그러나 위에 설명된 이유로 인해 특히 단일 조직 내에서 완전한 익명화가 어렵다. 가명화(pseudonymisation)는 절충적인 중간 지대를 제공하므로 데이터 최소화 요구 사항을 충족시키는 데 일정 부분 도움이 되는 반면, GDPR에 따라 조직의 의무에서 가명 데이터를 제거하지는 않는다. 가명은 다음과 같이 정의된다.

비즈니스가 개별 행동 패턴을 보거나 일반 고객의 특성을 발견하기 위해 고객 데이터베이스를 분석하기를 원한다면, 해당 개인의 실제 신원에 관심이 없는 경우, 이름과 이메일 같은 확실한 식별자를 간단한 참조 번호로 대체하여 데이터를 가명으로 만들 수 있다. 프로젝트를 진행하는 직원은 해당 개인이 누구인지는 알지 못하지만 회사는 여전히 이러한 개별 기록을 연결하여, 결론적으로는 해당 개인으로 다시 연결할 수 있다. 보기에는 데이터베이스가 익명으로 처리되지만, 데이터 보호 용어로는, 단지 가명으로 처리된다. 이는 이것이 여전히 개인정보이며 GDPR의 대상이라는 것을 인식하는 것이 중요하다. 그러나 GDPR은 가명화를 개인정보 최소화를 위한 중요한 보호 조치로 홍보하고, 처리의 원래 목적과 새로운 목적의 호환성을 결정하는 데 도움을 줄 수 있는 추가적인 보호조치로 인식하고 있다.

통계 목적으로 데이터를 집계하면 비 개인 데이터가 될 가능성이 있다. 그러나 샘플 크기가 충분히 크지 않은 경우 컨텍스트로(예를 들어, k-익명화에서 k값이 작은 경우) 개인을 식별이 가능할 수 있으므로 이러한 방식으로 익명화 데이터를 처리할 때는 항상 주의해야 한다.

자연인(natural person)

개인 데이터의 정의는 단순히 ‘자연인’을 의미하기 때문에, 거주 국가에 상관없이 보편적으로 ‘자연인’에게 적용되는 보호는 물론, 영토 범위에 대해 제3조의 규정이 적용된다. GDPR은 자연인의 개념을 정의하지 않고, 회원국의 법률에 맡겨 두고 있다. 그러나 Recital 27은 회원국이 이 분야에서 규칙을 제정하더라도 표준 계약 기밀 조항을 통해 보호받을 수 있는 사망자 또는 조직 데이터의 개인 데이터에는 GDPR이 적용되지 않는다고 규정하고 있다.

민감한 개인 데이터

GDPR은 특정 유형의 개인 데이터를 특정 보호를 받을 수 있는 개인 데이터의 ‘특수 범주’로 식별한다. 이러한 범주의 특성은 개인의 기본 권리와 자유에 중대한 위험을 초래할 수 있음을 의미한다. 이들은 ‘인종 또는 민족적 출신, 정치적 견해, 종교적 또는 철학적 신념, 노동조합 가입 및 유전자 정보 처리, 자연인을 고유하게 식별하기 위한 생체 인식 데이터, 자연인의 성생활 또는 성적 취향’이다.

유전 데이터는 ‘특히 자연인의 생물학적 시료 분석을 통해 얻어지는, 자연인의 생리학이나 건강에 관한 고유한 정보를 제공하는 자연인의 유전적 특성 또는 유전적 특성과 관련된 개인 데이터’로 정의된다. 건강에 관련된 데이터의 의미에 대한 추가적인 가이드가 제공되며, 넓은 의미로 해석되어야 할 문구가 명확하게 제시되어 있다. 이는 건강 상태에 대한 정보를 밝히는 건강관리 서비스 제공을 포함하여, 자연인의 육체적 또는 정신적 건강과 관련된 개인 데이터를 의미하며, ‘데이터 주체의 건강 상태와 관련된 모든 데이터를 포함한다. 여기에는 데이터 주체의 과거, 현재 또는 미래의 육체적 또는 정신적 건강 상태’가 포함되며, 아래 사항들을 포함한다.

Recital은 또한 ‘사진 처리는 자연인의 고유한 식별 또는 인증을 허용하는 특정 기술적 수단을 통해 처리될 때만 생체 인식 데이터의 정의에 의해 다루어지므로 개인 데이터의 특수 범주를 처리하는 것으로 시스템적으로 간주되어서는 안 된다’고 서술한다. 그러나 사진도 역시 개인의 건강 상태에 대한 정보로 간주될 수 있는 사람의 인종적 출신, 종교적 신념 또는 특정 신체장애를 밝힐 수 있기 때문에 Recital이 이를 명확히 정리하지는 못한다.

컨트롤러(Controller) 및 프로세서(Processor)

컨트롤러 및 프로세서의 개념은 Directive에 의해 수립되었으며 GDPR에서도 근본적으로 유사하다. 우리나라 개인정보보호법의 위수탁 관계와 일면 유사해 보이지만 절대 혼동하거나 혼용해서는 안 된다. 컨트롤러와 프로세서는 직관적이거나 상호 배타적이지 않다. 실제로 이러한 개념의 적용은 비즈니스 환경의 진화하는 특성, 아웃소싱의 고도화 및 조직이 IT 시스템을 중앙 집중화하는 경향으로 인해 점차 복잡해졌다. 그러나 데이터 주체의 권리와 자유를 보호하는 데 필수적인 요소이고, GDPR에 따라 발생하는 법적 의무 할당을 결정하는 데 핵심적인 요소로 남아 있다.

데이터 컨트롤러는, 단독으로 또는 공동으로, 개인 데이터 처리의 목적과 수단을 결정하는, 자연인 또는 법인, 공공 기관, 에이전시 또는 기타 단체이다. 즉, 데이터 컨트롤러는 개인 데이터와 관련한 주요 의사 결정자이다. 결과적으로 GDPR을 준수해야 하는 대부분의 책임은 데이터 컨트롤러의 몫이다. 예를 들어, 데이터 컨트롤러는 데이터 주체에 다음 사항을 확인하는 정보를 제공할 의무가 있다. 처리가 합법적인 근거를 지키며, 데이터 주체의 권리가 존중됨을 보장하고, 위험도가 높은 처리의 경우 데이터 보호 영향 평가를 수행하고, 적절한 데이터 보안을 보장하며, 개인정보 위반 시 DPA(Data Protection Authority) 또는 데이터 주체에 대한 통지 필요 여부에 대한 결정을 해야 한다.

프로세서는 GDPR에 따라 일부 의무가 있다(예: 국제 데이터 이전이 GDPR을 준수하는지 확인하고, 적절한 보안을 유지하며, 데이터 유출이 있는 경우 데이터 컨트롤러에 알리는 등). 그러나 이는 매우 부차적인 것으로, GDPR에 따라 대부분의 책임을 지는 컨트롤러의 문서화된 지침에 대해서만 개인정보를 처리하도록 계약한다. 대부분의 경우 데이터 컨트롤러가 DPA의 집행 조치의 첫 번째 대상이 될 것이므로, 개인 데이터를 처리하는 당사자의 상태를 결정하는 것이 중요한 문제이다.

실제로 컨트롤러의 주요 측면은 개인 데이터가 수집, 저장, 사용, 변경 및 공개되는 목적을 결정하는 것이다. 대조적으로, 프로세서는 컨트롤러의 직원이 아닌 컨트롤러 대신 개인 데이터를 처리하는 사람이다.

컨트롤러의 개념과 정의

데이터 컨트롤러의 가장 중요한 역할은 데이터 보호법을 준수할 책임자와 개인이 자신의 권리를 행사할 수 있는 방법을 결정하는 것이다. 즉, 컨트롤러는 책임을 할당하는 역할을 한다. 당사자는 하나의 트랜잭션에서 컨트롤러가 될 수 있고 다른 서버에서는 프로세서가 될 수 있으므로, 컨트롤러가 어느 당사자인지 결정하는 것이 주요한 데이터 보호 책임 및 의무를 할당하는 데 중요하다. 이것은 또한 어떤 감독 당국이 데이터 처리 활동을 감독할 책임이 있는지 결정할 것이다. GDPR이 회원국들에게 추가 법안을 시행할 재량권을 부여하는 경우에는 컨트롤러의 위치가 관련될 수도 있다.

‘컨트롤러’는 GDPR에서 다음과 같이 정의된다.

따라서 데이터 컨트롤러는 다음의 3가지 구성 요소에 따라 정의된다.

다시 말하지만, 컨트롤러 및 프로세서는 Directive와 동일하므로, WP29의 Opinion을 참고하여 해석하는 것이 도움이 된다.

첫번째 구성 요소: 자연인, 법인 또는 다른 단체

데이터 컨트롤러는 법인이거나 자연인일 수 있다. Opinion 1/2010은 누가 데이터 컨트롤러가 될 수 있는지에 대한 정의가 광범위함에도 불구하고, 회사나 단체가 임명한 개인이 아니라 컨트롤러를 회사 또는 단체로 간주하는 것이 바람직하다고 권고한다. 이것은 데이터 주체가 보다 신뢰성 있는 주체 앞에서 자신의 권리를 행사할 수 있도록 하기 위함이다.

조직 또는 법인체 내의 개인이 데이터 보호법 준수 또는 개인 데이터 처리를 보장하기 위해 조직에 의해 임명된 경우, 그 임명이 사람을 데이터 컨트롤러로 전환시키지 않는다. 왜냐하면 이 역할을 수행하면서 그들은 법적 주체를 대리하여 행동하기 때문이다. 개인이 데이터 컨트롤러의 범위와 제어 범위 밖에서 개인 데이터를 처리하는 경우에는 물론 그렇지 않다.

두 번째 구성 요소: 단독 또는 공동

다른 조직, 단체 또는 ‘자연인’은 동일한 개인 데이터 세트의 데이터 컨트롤러일 수 있다. Opinion 1/2010은 데이터 처리의 현실성의 복합성이 ‘공동으로’는 ‘함께 있는 것’ 또는 ‘혼자가 아님’으로 해석될 수 있음을 의미한다. 공동 처리는 반드시 동시에 발생할 비율이 동일할 필요는 없다.

다른 조직은 동일한 개인 데이터 집합의 컨트롤러일 수 있다. 그렇다고 해서 항상 공동 데이터 컨트롤러가 된다는 의미는 아니며, 데이터가 어떻게 전달되는지에 따라 다르다. 예를 들어, 여행사를 통해 휴가를 예약하고 여행사 직원이 선택한 항공사와 호텔에 해당 정보를 전달한 경우, 해당 항공사와 호텔은 동일한 데이터를 별도로 보유하고 있다. 그들은 각각 데이터를 보유하는 기간과 개인에게 특별 제안을 제공하는 데 사용하는지 여부를, 다른 두 단체와 관련 없이 결정한다. 항공사와 호텔은 공동 컨트롤러가 아니지만, 휴가 예약이 공유 데이터베이스에 직접 입력되고 당사자들이 통합 마케팅 활동을 수행하는 여행사와 공유 웹 사이트를 설정하는 것에 동의하는 경우는 공동 컨트롤러가 될 것이다.

공동 관리가 발생할 수 있는 또 다른 일반적인 상황은 기업 그룹 내에 있다. 모회사는 직원 또는 고객 레코드를 위한 중앙 데이터베이스를 포함하여 자회사에 중앙집중식 IT 서비스를 제공할 수 있다. 각 자회사는 데이터를 사업 목적으로 보유하기 때문에 직원 및 고객의 데이터에 대한 컨트롤러 역할을 한다. 예를 들어, 모회사가 데이터에 대해 자체적으로 독립적인 작업을 수행하는 경우, 그룹 전체의 직원 회전율을 비교하면 자회사와 공동 컨트롤러가 될 수 있다.

공동 통제에는 여러 가지 형태가 있다. 그룹 내 시나리오는 특히 복잡할 수 있다. 직원들이 종종 그룹을 구성하는 법인 간의 경계선에 집중하지 않고, 회사 그룹의 목적을 전체적으로 생각할 때가 많고, 사실상 시간이 지남에 따라 공동 관리인으로 변할 위험이 있기 때문이다. GDPR은 공동 컨트롤러가 투명성 있는 방식으로 GDPR 준수에 대한 각자의 책임을 결정해야 하며, ‘핵심은 복잡한 데이터 처리 환경에서도… 이러한 규칙의 위반에 대한 데이터 보호 규칙과 책임의 준수가 명확히 할당됨을 보장하는 것이다.’라는 WP29의 서술의 법적 기반이 된다. GDPR, 조항 26 (1); WP 169 의견 1/2010은 ‘컨트롤러’와 ‘프로세서’의 개념에 관한 것이다.

이것이 적용될 수 있는 구체적인 예는, 데이터 주체에게 공정한 처리 고지를 할 책임이다. 공동 컨트롤러 중 하나만이 데이터 주체와 직접적인 관계가 있는 경우, 모든 컨트롤러를 대신하여 해당 컨트롤러가 관련 정보를 발행하는 것이 논리적일 것이다. 개인을 더욱 보호하기 위해 공동의 컨트롤러는 데이터 주체에 가용한 ‘합의의 본질’을 만들어야 한다. 데이터 주체는 각각의 컨트롤러에 GDPR에 따라 자신의 권리를 행사할 수 있다.

세 번째 구성 요소: 개인 데이터 처리의 목적과 수단 결정

실제로 컨트롤러 정의의 핵심은 실체가 처리의 목적과 수단을 ‘결정’하는지 여부이다. 사실, 제28조 10항은 프로세서가 목적 및 처리 수단을 결정함으로써 GDPR을 침해한다면, 프로세서는 그 처리와 관련하여 컨트롤러로 간주될 것이라고 말하고 있다. 이것은 법적인 맥락이 컨트롤러를 식별하는 데 관련이 있을 수 있지만, 사실적인 요소 또는 상황이 결정적일 수 있다는 정의의 또 다른 주요 측면을 보여준다. 처리의 이유와, 누가 처리를 시작하고 주도했는지가 중요하며, 당사자의 역할에 대한 계약상 지정이 실제 상황과 다른 경우, 데이터 보호법에 따라 당사자의 실제 지위를 결정하는 데 결정적이지는 않다.

WP29는 컨트롤러가 누구인지 알아내려고 할 때 실용적인 관점을 선호한다. 데이터 컨트롤러의 개념은 실제 영향이 있는 책임을 할당하기 위한 기능적인 것임을 명심해야 한다. Opinion 1/2010은 ‘효과성을 보장해야 하는 필요성은, 통제와 관련하여 예측 가능성을 보장하기 위해 실용적인 접근 방식이 취해져야 할 것을 요구한다. 이와 관련하여, 데이터 보호법의 적용을 안내하고 단순화하기 위해, 경험 법칙과 실질적인 가정이 필요하다.’고 언급하고 있다.

이것은 복잡한 데이터 처리 체계가 될 수 있는 것을 다루는, 덜 법률적이고 상업적으로 접근하기 쉬운 방법을 알려준다.

제어의 출처 식별

Opinion 1/2010 은 컨트롤러가 제어의 출처로 식별될 수 있는 여러 가지 상황을 제시한다.

목적 및 처리 수단의 결정

컨트롤러는 처리의 목적과 수단, 즉 처리 활동의 이유와 방법을 결정한다. 예를 들어, 어떤 클라우드 서비스 공급자를 고객 정보를 저장하기 위한 데이터베이스로 사용할지 결정하는 회사를 가정해보면, 그 회사는 컨트롤러이고 클라우드 서비스 데이터베이스 공급자는 프로세서이다.

평가 시, ‘처리의 목적과 수단’의 결정을 내리는 데 관련된 세부적인 수준이 그 사람이 컨트롤러로 간주되기 위한 한계점을 충족시키는지 여부를 고려하는 것이 중요하다. Opinion 1/2010은 복잡한 상황에 대한 실용적인 접근 방식을 취하고 합리적인 결론에 도달하기 위해 묻는 질문을 간략히 보여준다(처리가 진행되는 이유와, 처리에 참여하는 당사자의 역할은 무엇입니까?) Opinion은 ‘프로세서가 주로 목적에 따라 제공되는 일반 지침보다 더 많이 작동할 수 있으며, 수단과 관련하여 세부 사항에 깊이 관여하지 않을 수도 있다’라고 허용한다. 즉, 프로세서 자체가 컨트롤러가 되지 않고, 컨트롤러를 대신하여 처리를 수행하는 방법에 대한 재량권이 있을 수 있다. 그러나 이 결과는 프로세서가 전체 처리를 담당하는 다른 당사자를 가리킬 수 있는 경우에만 가능하다.

유럽 ​​법률에 따른 컨트롤러 역할의 정의에 대한 최초의 제안을 고려할 때, Opinion 1/2010은 ‘수단’이 개인정보를 처리하는 기술적 방법뿐만 아니라 처리 방법도 나타내고 있고, 이는 어떤 데이터가 처리되어야 하는지, 어떤 제3자가 이 데이터에 접근할 수 있는지, 그리고 데이터가 언제 삭제되어야 하는지에 대한 질문을 포함한다. 예를 들어, 클라우드 기반으로 고객 데이터베이스를 제공하는 업체는 컨트롤러에 서비스를 제공하는 것 이외의 목적으로 저장된 데이터를 사용하는지? 관계가 끝나면 컨트롤러가 고객 정보가 삭제된다는 보장은 무엇인지? 와 같은 질문들이 그것이다.

특정 기술적 및 조직적 결정을 프로세서에 위임할 수도 있다. 예를 들어, 프로세서는 사용할 소프트웨어 유형에 대해 조언할 수 있다. Opinion 1/2010에서는 ‘처리의 목적을 결정하는 것이 어쨌든 컨트롤로서의 자격을 촉발시키는 반면, 결정 수단이 본질적 요소에 관한 것이라면 통제 수단을 내포하게 될 것’이라고 계속 말하고 있다.

‘수단의 핵심 요소’는 처리의 핵심에서 의사 결정을 가리킨다. 컨트롤러는 목적 또는 수단의 결정에 대한 가장 중요한 결정을 직접 한다는 전제하에, 처리의 기술적 측면과 조직적 측면에 대한 결정을 프로세서에 위임할 수 있다. 물론 컨트롤러는 데이터 처리 목적을 달성하는 데 사용된 수단에 대해 완전히 알고 있어야 하지만, 더 중요한 것은 ‘처리의 적법성의 핵심에 필수적이고 실질적인 질문은 컨트롤러의 몫’이라는 것이다. 예를 들어, 데이터의 저장 기간을 결정하거나 어떤 다른 당사자가 데이터에 접근할지를 결정하는 것은 컨트롤러의 일이다.

프로세서의 개념과 정의

프로세서는 개인 데이터 처리에 보다 밀접하게 관여할 수 있지만, 컨트롤러에 대한 책임을 할당할 수 있는 권한은 없다. 경우에 따라 처리 메커니즘(즉, 수단)은 서비스 제공 업체(예: 연금 계획 관리자 또는 인프라를 서비스로 제공하는 클라우드 제공 업체)에 의해 전적으로 결정될 수 있지만, 전체적으로 목적은 여전히 ​​고객(컨트롤러)에 의해 결정된다.

GDPR은 프로세서를 ‘컨트롤러를 대신하여 개인 데이터를 처리하는 자연인 또는 법인, 공공 기관, 에이전시 또는 기타 단체’로 정의한다.

따라서 사람이 데이터 프로세서가 되기 위해서는 2가지 기본 요소가 있어야 한다.

데이터 프로세서의 존재 여부는 처리 활동의 전부 또는 일부를 외부 조직이나 개인에게 위임하는 컨트롤러의 결정에 달려 있다. 프로세서의 역할은 조직의 ‘특정 상황에서의 구체적인 활동’에 기인한다.

컨트롤러는 기술적 또는 조직적 문제에 관한 한, 처리 수단 결정을 프로세서에 위임할 수 있다. 이 부분은 GDPR이 프로세서에 직접 부과한 의무에 반영된다. 그 의무는 보안, 기록 유지, 규정 위반 사실을 컨트롤러에 알리고 GDPR의 5장에 설정된 국제 데이터 이전 제한을 준수하는지 확인하는 의무를 포함한다. 이것은 프로세서가 자신의 임무 수행 방식에 있어 종종 매우 넓은 재량권을 가지고 있음을 인식하지만, 이러한 의무는 모두 ‘방법’과 관련된다. 처리와 관련하여 합법적인 근거를 확보하고 데이터 주체의 권리를 존중하는 등 목적과 관련된 의무는 데이터 컨트롤러에만 부과된다.

이에 대한 더 깊은 인식은 제28조 (10)항에 있다. 명령의 범위를 넘어 처리의 핵심이나 처리의 핵심 수단을 결정하는(예: 연금 계획 관리자가 연금 계획 회원의 세부 정보를 사용하여 다른 금융 상품을 시장에 판매하기로 결정한 경우) 프로세서는 그 처리와 관련하여 컨트롤러로 간주되어야 한다. 이것은 GDPR에 따라 예상되는 프로세서의 의무 범위를 즉각적으로 증가시키고, 해당 활동에 대한 잠재적 책임을 증가시키기 때문에 중요하다.

GDPR에서는 프로세서가 컨트롤러의 지침에 대해서만 개인 데이터를 처리하고 컨트롤러와 프로세서 간의 관계를 규율하는 계약 또는 법적 구속력을 서면으로 작성해야 한다고 요구하고 있다. 계약서에는 데이터 처리의 성격과 목적, 개인 데이터 유형 및 데이터 주체 범주가 명시되어야 한다. 이전에 많은 클라우드 제공 업체가 자신의 플랫폼에서 호스팅되는 내용을 모르거나 관심이 없는 중립 플랫폼 제공 업체로 제시되었기 때문에, 비 유럽 경제 지역(EEA) 프로세서를 사용하는 컨트롤러가 이 요구 사항을 설명해야 할 수 있다. 제28조는 처리 계약서에 대한 상세한 내용을 정리하고 있으며, 프로세서의 의무를 다음과 같이 규정하고 있다.

서비스 제공 업체가 계약 조건을 준비한다는 사실 자체가 컨트롤러라는 것을 의미하지는 않는다.

현대 아웃소싱의 복잡한 구조는 컨트롤러가 두 개 이상의 프로세서로 처리 작업을 하청하거나 데이터 프로세서가 두 개 이상의 하청 업체(“다층 하도급 계약자”)에게 전적으로 또는 부분적으로 하청을 제공할 수 있음을 의미한다. 제28조는 다음을 요구함으로써 이 가능성을 규제한다.

컨트롤러와 프로세서의 역할 구분 시 고려 요소

Opinion 1/2010은 당사자의 역할을 결정하는 데 도움이 되는 다음 기준을 제시한다.

처리(Processing)

처리는 GDPR에 의해 다음과 같이 정의된다.

자동화 여부를 불문하고, 수집, 기록, 조직, 구조화, 저장, 개조 또는 변경, 검색, 협의, 사용, 전송에 의한 공개, 유포 또는 이용 허용, 정렬 또는 조합, 제한, 삭제 또는 파기 등과 같이, 개인 데이터 또는 개인 데이터 집합에 대해 수행되는 모든 작업.

이러한 광범위한 정의로 인해 GDPR에 정의된 ‘처리’에 미치지 않는 개인 데이터가 포함된 사용을 식별하기가 어렵다. 그러나 GDPR의 제2조 (1)항은 적용 범위를 정의함으로써 GDPR이 의미하는 개인 데이터 처리에 대한 제한을 설명한다. 제2조에 따르면 다음 조건이 GDPR에 적용되는 개인 데이터 처리에 적용되어야 한다. (1) 처리가 자동화된 방법으로 전체적 또는 부분적으로 수행되어야 한다. (2) 처리가 자동화된 수단이 아닌 경우, 파일 시스템의 일부를 구성하거나 파일 시스템의 일부를 구성하도록 의도된 개인 데이터와 관련되어야 한다. 파일링 시스템은 특정 기준에 따라 액세스할 수 있는 개인 데이터의 구조화된 집합을 말한다.

데이터 주체(Data Subject)

‘데이터 주체’와 같은 핵심 개념이 자체적으로 정의되어 있지 않다는 것이 놀라울 수 있지만, 그렇게 놀랄 일은 아니다. 대신, 개인 데이터의 정의 내에서 부수적으로 정의되며, ‘식별되거나 식별 가능한 자연인’을 데이터 주체로 간주한다.

Recital 14는 아래와 같이 GDPR의 보호가 법인에까지 미치지 않는다는 것을 분명히 한다.

자연인으로서의 사망자는 데이터 주체가 될 수 있지만, 회원국이 이 분야에서 규칙을 제정할 수는 있음에도 불구하고, GDPR 자체는 고인의 개인 데이터에 적용되지 않는다. 다만 사망자의 의료관련 정보는 사망 이후에도 의료정보로 취급되어 관리된다.

맺음말

GDPR의 근본적인 개념을 이 짧은 글로 다 이해하기는 어렵지만, 한번 이해하고 나면 주어진 사례가 GDPR의 대상이 되는지, 해당 사례에서 어떤 역할(컨트롤러 또는 프로세서)을 하는지, GDPR 준수에 대한 추가 지침을 어디에서 찾을지 여부를 결정하는 데 도움이 된다.