GDPR 내 역할
1) 기본 정의 및 원칙
컨트롤러: 개인 데이터 (PD) 처리의 목적과 방법을 결정합니다. 합법성, 투명성, 피험자의 권리, 보안 TOM, 프로세서 선택 및 제어에 대한 주요 책임.
프로세서: 컨트롤러가 문서화 한 경우에만 PD를 처리하고 TOM을 제공하며 엔터티 권리 및 사건을 지원하며 기록을 유지 관리하며 감사를 허용합니다.
공동 컨트롤러: 두 명 이상이 공동으로 목표와 방법을 정의합니다. 피험자에 대한 책임과 접촉 지점의 투명한 분배가 필요합니다.
하위 프로세서: 프로세서가 참여한 공급 업체는 컨트롤러의 사전 서면 승인 및 동등한 의무로만 허용됩니다.
황금 규칙: 누가 처리 할 이유와 방법을 결정하는 사람은 컨트롤러입니다. 프로세서 인 "지침에 따라 실행" 하는 사람.
2) 실제로 역할을 정의하는 방법 (의사 결정 트리)
1. 누가 처리의 비즈니스 목표를 설정합니까?
→ 당신입니까? 오히려 컨트롤러.
2. 목적 (분석, 마케팅) 으로 데이터를 재사용 할 수 있습니까?
→ 예 → 컨트롤러 (또는 목표가 일반적인 경우 조인트 컨트롤러).
3. 상대방이 정확한 수단/제한을 표시하고 목표가 도출됩니까?
→ 예 → 프로세서.
4. 양 당사자가 목표를 설정하는 공통 제품/공동 플랫폼이 있습니까?
→ 예 → 조인트 컨트롤러 (필요한 아트. 26 배열).
5. 과제에 클라우드/공급 업체가 포함되어 있습니까?
→ 공급 업체 - 서브 프로세서; 당신은 컨트롤러입니다. 기본 프로세서는 귀하의 허가를 받아야합니다.
3) iGaming 생태계의 역할-예의 행렬
4) 역할 책임 (높은 수준의 RACI)
5) 문서 및 계약
DPA (Data Processing Agreement) -스키마에 필요한 컨트롤러 → 프로세서.
최소: PD 주제/범주, 목표/지침, TOM, 기밀 유지, DSAR/DPIA 지원, 사건 알림, 데이터 삭제/반환, 감사, 하위 프로세서 (목록/동의 메커니즘).
Art. 26 Arrangement (Joint Controller): 책임의 투명한 배포 (알림, DSAR, 연락처), 공공 정책의 역할의 본질.
SCC/UK IDTA + DTIA: 부적절한 경우 비 EEA/영국 전송에 필수적입니다.
RoPA: 컨트롤러 및 프로세서 (자체 세트) 에서 처리 작업 등록.
마케팅/SDK 용어: 재활용, 명확한 역할 및 목표 없음.
6) 중요한 영역과 일반적인 오류
1. 롤 믹싱: "프로세서" 는 자체 목적으로 데이터를 사용합니다. → 실제로 컨트롤러/조인트 컨트롤러입니다.
2. 허가없이 서브 프로세서: 프로세서는 귀하의 동의없이 공급 업체를 추가합니다.
3. "빈" DPA: 명확한 보존/삭제/사고/감사 명령이 없습니다.
4. 불완전한 공동 통제: 예술이 없습니다. 26-불만 및 페널티 위험.
5. 마케팅 SDK: 공급자가 PD를 가져옵니다. 공개 및 합법성을 담당합니다.
6. PSP/은행: 프로세서를 고려하는 것은 실수입니다. 더 자주 이들은 개별 컨트롤러입니다.
7) DPA 미니 템플릿 (문구 조각)
처리 목표와 특성: "프로세서는 컨트롤러의 지시에 따라 KYC 검증 전용 PD를 처리합니다".
지침: "목표를 변경하려면 컨트롤러의 서면 동의가 필요합니다".
서브 프로세서: "프로세서는 사전 서면 권한없이 서브 프로세서를 끌어 들이지 않습니다. 최신 레지스터를 유지 관리하고 게시합니다. "
보안: "프로세서는 부록에 설명 된 것보다 낮지 않은 TOM (암호화, 앨리어싱, 액세스 제어, 로깅) 을 지원합니다".
사건: "프로세서는 과도한 지연없이 컨트롤러에 통지하고 규제 기관 및 엔티티에 알림에 대한 모든 정보를 제공합니다".
삭제/반환: "서비스가 끝나면 프로세서는 PD를 삭제/반환하고 예정대로 백업에서 사본을 삭제합니다".
감사: "컨트롤러는 합리적인 통지와 함께 감사/설문지/외부 보고서 (SOC2/ISO) 를 수행 할 수 있습니다".
8) DPIA/DTIA 및 국경 간
DPIA: 컨트롤러가 시작됩니다. 프로세서는 시스템, 위험, TOM에 대한 정보를 제공합니다.
DTIA: SCC/IDTA-수령인의 집행 환경 평가, 추가 조치 (E2EE, 클라이언트 키, 준 익명화, EC/UK의 키 스토리지).
9) 분산 역할에서 주제권 (DSAR) 과 협력
컨트롤러: 요청을 수락하고, 신원을 확인하고, 수집을 조정하고, 응답합니다 (일반적으로 3 일 30 일).
프로세서: 즉시 지시대로 업로드/삭제를 제공하고 (달리 지시하지 않는 한) 피사체에 직접 응답하지 않습니다.
공동 감독자: 계약에서 응답을위한 "연락 지점" 및 데이터 교환을 지정하십시오.
10) 보안 및 사건: 누가 무엇을하는지
컨트롤러: 사고 정책, DPA/사용자 알림 계획, CAPA 관리.
프로세서: 컨트롤러의 즉각적인 알림, 기술 법의학, 격리, 로그, 알림 지원.
공동 감독자: 합의 된 알림 매트릭스; 단일 통신 회선.
11) 유지, 삭제, 테스트 데이터
컨트롤러: 목표/법률 (AML, 회계) 에 따라 스토리지 기간을 설정하고 정책에 게시합니다.
프로세서: 일정에 따라 삭제/익명화를 구현합니다. 백업 청소; 마스킹/합성없이 테스트 환경에서 PD 사용 금지.
12) 운영 통합 (실습)
CAB/Change: CAB 및 DPA/SCC 편집을 통한 모든 역할/하위 프로세서/영역 변경.
데이터 맵 및 RoPA: 라이브 스트림 맵; 컨트롤러에는 목표와 수신자가 있고 프로세서에는 범주와 작업이 있습니다.
공급 업체 관리: 온 보딩 전 실사 (ISO/SOC2, 침투 테스트, 사고 정책, 데이터 지리).
감사: 체크리스트, 설문지, PII 액세스 샘플 로그, 삭제 로직.
13) 점검표 "역할 정의"
- 누가 목표와 주요 처리 매개 변수를 설정합니까?
- PD를 자체 목적으로 재사용 할 수 있습니까?
- 제 2 자는 별도의 법적 근거가 있습니까?
- 누가 실체 (DSAR) 를 책임지고 있습니까?
- DPA가 필요합니까 (예술 28) 또는 배열 (예술 26) 입니까?
- 하위 프로세서와 일치 메커니즘이 있습니까?
- 국경 간 전송과 어떤 메커니즘 (SCC/IDTA) 이 있습니까?
14) 자주 묻는 질문 (FAQ)
PSP-프로세서 또는 컨트롤러?
일반적으로 별도의 컨트롤러: 자체 목표 (지불 서비스, 사기 방지, 규제보고).
KYC 제공 업체는 모델 교육을 위해 사진을 저장할 수 있습니까
컨트롤러 상태 (별도의 기준 및 공개) 또는 명시적인 동의 및 올바른 법적 근거로만 가능합니다. 그렇지 않으면 금지됩니다.
플레이어를 데려온 계열사는 프로세서입니까?
더 자주 별도의 컨트롤러: 그는 자신의 목적으로 PD를 수집합니다. 공동 캠페인에는 명시적인 역할 할당이 필요합니
클라우드 로깅 서버-누구의 데이터?
로그 처리는 보안을 보장하는 프로세서의 책임입니다. 자체 목적으로 재사용하려면 별도의 근거가 필요합니다 (그렇지 않으면 불가능합니다).
15) 미니 역할 정책 (내부 표준의 스 니펫)
1. 기본적으로 운영자는 플레이어/파트너의 모든 PD 흐름에 대한 컨트롤러 역할을합니다.
2. PD-에 액세스 할 수있는 모든 공급 업체는 프로세서 (DPA) 또는 별도의 컨트롤러 (자체 목적) 로 등록됩니다.
3. 서브 프로세서를 추가하려면 서면 동의 및 레지스트리 업데이트가 필
4. CAB, DPO 및 Legal을 통한 역할/테리토리/목표 변경
5. 컨트롤러에 의해 조정 된 DSAR 및 사고는 프로세서가 SLA에 응답합니다.
16) 구현 로드맵
1-2 주: 데이터 흐름 및 역할 목록; "누가 누구" 매트릭스 초안; RoPA 업데이트.
3-4 주: DPA의 결론/업데이트, 기술. 26 (필요한 경우), 서브 프로세서 레지스트리; 감사 설문지 준비.
2 월: DTIA/SCC/IDTA, 공공 정책 업데이트, 팀 교육.
3 개월 이상: 정기적 인 공급 업체 감사, DSAR 테스트, 사고에 대한 탁상, 제품/마케팅 변경에 대한 역할 감사.
17) 짧은 템플릿 "역할 매트릭스" (예)
TL; DR
우리는 목표와 처리 방법을 통해 역할을 결정합니다. "왜/방법" -컨트롤러; 지시 된 프로세서로 수행; 함께 결정합니다-공동 컨트롤러. 이것을 DPA/art에서 공식화합니다. 26, 우리는 RoPA를 수행하고, 하위 프로세서를 제어하고, DPIA/DTIA, 주제 권리 및 보안을 제공합니다. 명확한 역할 매트릭스 = 규제 위험 감소, 분쟁 지역 감소 및 빠른 감사.