영국 조직에 대한 ICO의 집행 조치는 2024년과 2025년에 급격히 증가하여 2년 동안 기술적 보안 조치 미흡으로 총 1,200만 파운드 이상의 벌금이 부과되었습니다. ICO 집행 통지의 패턴은 일관됩니다. 침해를 당하고 적절한 기술적 통제를 구현했음을 증명할 수 없었던 조직이 가장 가혹한 결과에 직면했습니다. 개발자에게 이것은 직접적인 직업적 관심사입니다. 암호화, 로깅, 접근 제어, 데이터 보존에 관해 내리는 결정이 조직이 ICO 앞에서 자신을 방어할 수 있는지 여부를 결정하는 기술적 통제입니다.

이 가이드는 법무 또는 컴플라이언스 부서가 아닌 개발자와 엔지니어링 팀을 위해 작성되었습니다. UK GDPR의 요구사항을 구체적인 기술적 결정으로 변환합니다. 무엇을 구현할지, 어떻게 구현할지, 각 조치가 왜 존재하는지.

요약

  • UK GDPR 제32조는 리스크에 비례하는 “적절한 기술적 조치"를 요구합니다. 개인 데이터를 처리하는 대부분의 애플리케이션에서 이는 저장 시와 전송 중 암호화, 가능한 경우 가명화, 접근 통제, 문서화된 침해 감지 능력을 의미합니다.
  • GDPR 노출을 만드는 가장 일반적인 개발자 실수: 디버그 출력에 PII를 로깅하는 것, 삭제 권리를 위해 실제로 삭제해야 하는 레코드를 소프트 삭제하는 것, 개인 데이터에 접촉하는 모든 타사 서비스와 DPA를 구현하지 않는 것.
  • 데이터 최소화는 필드 수준에서 이루어지는 설계 결정입니다. 필드를 수집하고 저장할 문서화된 이유가 없으면 수집하지 마십시오.
  • 삭제 권리는 백업 및 타사 처리자를 포함한 모든 시스템에 걸쳐 실제 삭제가 필요합니다. 소프트 삭제는 의무를 충족하지 않습니다.

UK GDPR vs. EU GDPR: 개발자에게 무엇이 달라지는가

브렉시트 이후 영국은 European Union (Withdrawal) Act 2018을 통해 EU GDPR 프레임워크를 “UK GDPR"로 유지했습니다. 개발자에게 기술적 요구사항은 동일합니다. 차이는 행정적입니다. 영국의 감독 기관은 EU 국내 데이터 보호 기관이 아닌 정보감독관사무소(ICO)이며, 영국과 EU 간의 국경을 초월한 전송은 영국 적절성 결정(현재 EU가 유지하고 있지만 정기적으로 검토됨)에 의해 규율됩니다.

실제 의미는 EU GDPR의 기술적 요구사항을 준수하는 소프트웨어를 구축하면 UK GDPR의 기술적 요구사항도 충족한다는 것입니다. 반대도 마찬가지입니다. 차이가 발생하는 곳은 통지 절차, 이전 메커니즘, 그리고 때로는 EDPB 지침과 강조점이 다른 ICO의 특정 집행 지침입니다.

제32조: 실제로 무엇을 요구하는가

UK GDPR 제32조는 관리자와 처리자에게 기술의 현황, 구현 비용, 처리의 성격·범위·맥락·목적을 고려하여 리스크에 적절한 보안 수준을 보장하기 위한 “적절한 기술적 및 조직적 조치"를 구현할 것을 요구합니다.

그 언어는 의도적으로 유연합니다. 실제로 무엇을 의미하는지는 리스크 프로필에 따라 달라지지만, 제32조(1)는 네 가지 구체적인 예를 제시합니다.

  1. 개인 데이터의 가명화 및 암호화
  2. 처리 시스템 및 서비스의 지속적인 기밀성, 무결성, 가용성 및 복원력 보장 능력
  3. 물리적 또는 기술적 사고 발생 후 적시에 개인 데이터의 가용성 및 접근을 복원하는 능력
  4. 보안 조치의 효과성을 정기적으로 테스트, 평가, 검토하는 프로세스

“기술의 현황"은 가장 비싸거나 최첨단 솔루션을 구현해야 한다는 의미가 아닙니다. 명백히 더 나은 접근 방식(예: Argon2)이 잘 확립되고 광범위하게 이용 가능하며 구현 비용이 실질적으로 더 비싸지 않을 때 약한 접근 방식(예: 비밀번호 해싱에 MD5 사용)을 사용하는 것을 정당화할 수 없다는 의미입니다.

저장 시 암호화

비밀번호. 비밀번호를 평문으로 저장하거나 비밀번호 해싱에 MD5 또는 SHA-1을 사용하지 마십시오. 둘 다 완전히 부적합합니다. 최소 작업 계수 12의 bcrypt, 또는 서버 하드웨어에서 최소 100ms가 걸리도록 조정된 매개변수의 Argon2id를 사용하십시오. Argon2id는 OWASP의 현재 권장 사항이며 새로운 구현에 바람직합니다.

1# Argon2id with libsodium (Node.js example)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

데이터베이스 암호화. 데이터베이스 수준에서 저장 시 암호화를 활성화합니다. 모든 주요 데이터베이스와 관리형 서비스(PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL)가 이를 지원합니다. 투명한 데이터 암호화(TDE)는 디스크의 데이터를 보호하지만 쿼리 접근 권한이 있는 손상된 데이터베이스 사용자로부터는 보호하지 않습니다. 고도로 민감한 필드(국가보험번호, 의료 기록, 금융 계좌 번호)의 경우 키 관리 서비스(AWS KMS, Azure Key Vault, HashiCorp Vault)를 사용하는 AES-256-GCM을 통한 애플리케이션 수준의 필드 암호화를 고려하십시오. 키는 암호화하는 데이터와 별도로 저장해야 합니다.

키 관리. 애플리케이션 코드에 암호화 키를 하드코딩하거나 보호하는 데이터와 동일한 데이터베이스에 저장하지 마십시오. 개발에는 환경 변수를, 프로덕션에는 관리형 키 관리 서비스를 사용하십시오. 정기적으로 키를 교체하고 애플리케이션이 다운타임 없이 키 교체를 처리할 수 있는지 확인하십시오.

하지 말아야 할 것. 암호화가 적용되지 않을 수 있는 로그 파일, 임시 파일, 또는 애플리케이션 캐시에 개인 데이터를 평문으로 저장하지 마십시오. 개인 데이터를 처리하는 모든 코드 경로를 확인하고 암호화되지 않은 복사본이 무의식적으로 유지되지 않도록 하십시오.

전송 중 암호화

TLS 구성. TLS 1.2를 최소한으로, 지원되는 경우 TLS 1.3을 기본값으로 적용합니다. SSLv3, TLS 1.0, TLS 1.1을 완전히 비활성화합니다. nginx의 경우:

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. 긴 max-age 값과 includeSubDomains로 Strict-Transport-Security 헤더를 설정합니다. 최소 31536000(1년)의 max-age가 표준입니다. 배포가 허용하는 경우 HSTS 프리로드 목록에 제출하십시오.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

혼합 콘텐츠. HTTPS 페이지에서 HTTP를 통해 리소스(이미지, 스크립트, 스타일시트, API 호출)를 제공하면 혼합 콘텐츠 취약점이 발생하고 전송 보안이 약화됩니다. 혼합 콘텐츠를 차단하도록 Content Security Policy를 구성하고 HTTPS가 아닌 리소스 로드가 없는지 페이지를 검사하십시오.

내부 서비스. 전송 중 암호화는 사용자 대면 트래픽뿐만 아니라 내부 서비스 간 통신에도 적용됩니다. 데이터베이스 연결, 메시지 큐 연결, 마이크로서비스 호출 모두 TLS를 사용해야 합니다. 많은 개발자가 사용자 대면 레이어를 올바르게 암호화하지만 내부 네트워크를 간과합니다.

코드에서의 데이터 최소화

데이터 최소화는 법적 추상화가 아닙니다. 필드별로 이루어지는 설계 결정입니다. 개인 데이터를 수집하기 전에 애플리케이션이 기능하기 위해 이것이 실제로 필요한지 물어보십시오. 특정 사용 사례로 그 질문에 답할 수 없다면 수집하지 마십시오.

실제로 이것은 다음을 의미합니다.

  • 선택적이고 목적이 모호한 양식 필드를 제거합니다(예: 연령 게이팅 요구사항이 없는 뉴스레터 가입에서 “생년월일”)
  • 정기적으로 데이터베이스 스키마를 감사하고 활성 사용 없이 개인 데이터가 포함된 열을 삭제합니다
  • 가능한 경우 스키마 수준에서 보존 기간을 설정하고 예약된 작업을 사용하여 만료된 레코드를 자동으로 제거합니다
  • 애플리케이션이 진정으로 필요하지 않는 한 고도로 민감한 개인 데이터(건강 정보, 금융 세부 정보, 정치적 견해) 수집을 피합니다. 제32조 위험 평가는 처리되는 데이터의 민감도에 따라 확장되기 때문입니다.

ICO의 책임 원칙은 데이터 최소화를 고려했음을 증명할 수 있어야 한다고 요구합니다. 아키텍처 또는 스프린트 노트에 문서화된 설계 결정이 이를 충족합니다. 문서화되지 않은 결정은 충족하지 않습니다.

가명화

가명화는 직접 식별 정보를 별도로 보유된 키 또는 매핑 테이블에 접근 없이는 개인을 식별할 수 없는 토큰이나 식별자로 대체합니다. 제32조는 이를 권장 기술적 조치로 명시적으로 나열하며, 제89조는 연구 목적을 위한 가명화된 데이터 처리에 대한 의무를 줄입니다.

분석 및 행동 추적의 경우 일반적인 패턴은 분석 시스템에 전달하기 전에 사이트별 솔트를 사용하여 SHA-256으로 사용자 식별자를 해시하는 것입니다.

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

솔트는 분석 데이터와 별도로 저장해야 합니다. 솔트 없이는 해시를 역산하여 개인을 식별할 수 없습니다. 이는 분석 시스템이 가명화된 식별자만 보유함을 의미하여 해당 시스템 침해의 위험 프로필을 줄입니다.

가명화는 익명화가 아닙니다. 매핑 키를 보유하고 있으면 ICO는 가명화된 데이터를 개인 데이터로 취급합니다. 합리적으로 이용 가능한 추가 정보로도 재식별이 불가능한 완전한 익명화는 GDPR 범위에서 데이터를 완전히 제거합니다. 실제로 진정한 익명화를 달성하는 것은 어렵습니다. 대부분의 구현은 여전히 GDPR 적용을 받지만 위험이 줄어든 가명화된 데이터를 생성합니다.

삭제 권리: 올바른 구현

삭제 권리(제17조)는 올바르게 구현하기 가장 기술적으로 까다로운 GDPR 의무 중 하나입니다. 요구사항은 구체적입니다.

물리 삭제, 소프트 삭제가 아님. is_deleted 플래그를 설정하고 쿼리에서 필터링하는 것은 삭제 권리를 충족하지 않습니다. 데이터는 실제로 데이터베이스에서 제거되어야 합니다. 개인 데이터를 보유하는 모든 엔티티에 대한 물리 삭제 기능을 구축하십시오.

계단식 삭제. 사용자 레코드를 삭제하는 것은 개인 데이터가 관련 테이블(주문, 주소, 활동 로그, 기본 설정, 업로드된 파일)에도 보유되는 경우 충분하지 않습니다. 사용자 식별자에 연결된 개인 데이터가 포함된 모든 테이블을 매핑하고 삭제가 올바르게 계단식으로 이루어지거나 모든 관련 데이터를 원자적으로 제거하는 명시적 삭제 작업을 구현하십시오.

타사 처리자. 개인 데이터를 타사 서비스(이메일 마케팅 플랫폼, CRM, 분석 도구, 결제 처리자)에 전송했다면, 삭제 의무는 해당 처리자에게 데이터를 삭제하도록 지시하는 것으로 확장됩니다. 이를 위해서는 다음이 필요합니다.

  • 개인 데이터를 수신하는 모든 타사 서비스의 문서화된 인벤토리
  • 각각에 대한 확인된 삭제 메커니즘(API 호출, 지원 티켓, 자동화된 정보 주체 요청 처리)
  • 삭제가 완료되었다는 증거

백업. 백업은 가장 흔히 간과되는 삭제 문제입니다. 90일 보존 기간의 일일 데이터베이스 백업을 수행한다면, 라이브 데이터베이스에서 충족된 삭제 요청은 백업이 만료될 때까지 백업에서 충족되지 않습니다. ICO의 입장은 삭제 후 복원된 백업이 삭제된 개인 데이터를 재도입해서는 안 된다는 것입니다. 실용적인 접근법에는 가능한 경우 백업 내보내기에서 삭제된 레코드를 제외하거나, 백업별 제거 프로세스를 구현하거나, 필드 수준 암호화를 사용하고 키를 삭제하는 것(데이터를 읽을 수 없게 만들어 삭제 표준에 가까워짐)이 포함됩니다.

예외. 삭제 권리는 절대적이지 않습니다. 법적 청구, 법정 준수(예: 회사법에 따른 재무 기록), 또는 공공 이익 목적에 필요한 데이터를 보유할 수 있습니다. 예외를 문서화하고 삭제 요청을 거부하거나 부분적으로 이행할 때 정보 주체에게 전달하십시오.

침해 감지와 72시간 통지 요건

UK GDPR 제33조는 개인에게 위험을 초래할 가능성이 있는 개인 데이터 침해를 인지한 후 72시간 이내에 ICO에 통지할 것을 요구합니다. 이는 침해가 발생한 후 72시간이 아닙니다. 인지한 때부터 72시간입니다. 이 구분은 침해 감지 능력을 구축하는 직접적인 인센티브를 만듭니다. 발견했을 때부터 시계가 움직이기 때문입니다.

침해 감지를 위해 로깅할 것. 로깅 아키텍처는 다음을 캡처해야 합니다.

  • 인증 이벤트: 성공 및 실패한 로그인, MFA 챌린지, 비밀번호 재설정
  • 권한 부여 실패: 권한 검사로 인해 거부된 요청
  • 데이터 접근: 누가 어떤 개인 데이터에 언제 접근했는지, 특히 대량 내보내기 또는 비정상적인 쿼리 양
  • 구성 변경: 사용자 권한, 암호화 키, 또는 데이터 보존 설정 변경
  • 비정상적인 패턴: 비정상적인 IP 주소에서 또는 비정상적인 시간에 접근, 개인 데이터 테이블의 고용량 읽기

로깅하지 말아야 할 것. 애플리케이션 로그에 개인 데이터 값을 로깅하지 마십시오. 전체 요청 본문을 기록하는 디버그 로그, 매개변수 값이 대체된 데이터베이스 쿼리, 또는 사용자가 입력한 양식 데이터는 관리하기 어렵고 자체적으로 GDPR 범위에 있는 이차 개인 데이터 저장소를 만듭니다. 값 대신 식별자(사용자 ID, 세션 ID, 요청 ID)를 로깅하십시오.

1# 잘못된 방법: 실제 이메일 주소를 로깅
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# 올바른 방법: 식별자만 로깅
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

침해 대응 계획. 로깅은 감지를 가능하게 하지만 침해를 감지했을 때 무슨 일이 일어나는지에 대한 문서화된 프로세스가 필요합니다. 내부적으로 누가 통지받나요? 누가 ICO 통지 결정을 내리나요? ICO 통지에는 어떤 정보가 포함되어야 하나요? 필요하기 전에 이 프로세스를 구축하십시오.

타사 API 컴플라이언스

관리자 vs 처리자. 개인 데이터를 귀하를 대신하여 처리하는 타사 서비스(트랜잭션 이메일 제공업체, 클라우드 인프라 제공업체, 결제 처리자)를 사용하는 경우, 그들은 데이터 처리자이고 귀하는 관리자입니다. 그 맥락에서 UK GDPR 준수에 대한 책임은 귀하에게 있습니다.

데이터 처리 계약. 귀하를 대신하여 개인 데이터를 처리하는 모든 타사 서비스와 서면 데이터 처리 계약(DPA)을 체결해야 합니다. 대부분의 주요 SaaS 제공업체(AWS, Mailchimp, Stripe, Twilio, SendGrid)는 표준 DPA를 제공합니다. 서명하고 보관하십시오. 제공업체가 DPA를 제출할 수 없는 경우 UK GDPR에 따라 개인 데이터 처리에 합법적으로 사용할 수 없습니다.

하위 처리자. 처리자와의 DPA는 하위 처리자(귀하의 데이터를 처리하기 위해 순차적으로 사용하는 서비스)를 나열해야 합니다. 예를 들어, 귀하의 트랜잭션 이메일 제공업체는 AWS 인프라를 사용할 수 있습니다. 하위 처리자와 직접 DPA를 체결할 필요는 없지만, 이전 컴플라이언스 목적으로 그들이 누구인지와 데이터가 지리적으로 어디서 처리되는지를 파악해야 합니다.

이전 메커니즘. 타사 서비스가 영국 또는 EU 외부에서 데이터를 처리하는 경우 법적 이전 메커니즘이 필요합니다. 영국으로부터의 이전에는 현재 영국별 메커니즘(영국 국제 데이터 이전 계약, 또는 이용 가능한 경우 영국 적절성 결정 의존)이 필요합니다. 각 서비스의 데이터 거주지 옵션과 이전 문서를 확인하십시오.

접근 통제

최소 권한 원칙. 애플리케이션이 사용하는 데이터베이스 사용자는 최소한의 필요 권한(특정 테이블에 대한 읽기 및 쓰기, 관리 액세스 없음)을 가져야 합니다. 읽기 집중 서비스(보고, 분석)와 쓰기 집중 서비스(사용자 대면 애플리케이션)에 대한 별도의 데이터베이스 자격증명을 만드십시오. 이렇게 하면 손상된 자격증명의 폭발 반경을 제한합니다.

역할 기반 접근 통제. 애플리케이션에 RBAC를 구현하고 역할 할당을 정기적으로 검토하십시오. 역할은 시간이 지남에 따라 권한을 축적하는 경향이 있습니다. 각 역할이 실제로 필요한 것과 비교한 정기적인 감사는 권한 증가를 포착합니다.

데이터 접근 감사 로그. 민감한 데이터의 경우, 어떤 인증된 사용자가 어떤 개인 데이터 레코드에 언제 접근했는지를 기록하는 애플리케이션 레이어의 감사 로깅을 구현하십시오. 이는 애플리케이션 오류 로그와 별도이며 조작 방지(애플리케이션 코드로부터 제한된 접근을 가진 쓰기 전용 또는 추가 전용)여야 합니다.

개발자 체크리스트: 구현할 10가지 기술적 통제

  1. 비밀번호 해싱. bcrypt(비용 계수 12+) 또는 Argon2id를 사용하십시오. MD5 또는 SHA-1 비밀번호 해싱을 즉시 제거하십시오.
  2. 저장 시 암호화. 데이터베이스 수준 TDE를 활성화하고 관리형 KMS에 키를 보유한 고도로 민감한 개인 데이터에 대한 필드 수준 AES-256-GCM 암호화를 구현하십시오.
  3. TLS 구성. TLS 1.2를 최소한으로, TLS 1.3을 기본값으로, 1년 max-age의 HSTS, 혼합 콘텐츠 없음을 적용하십시오.
  4. 데이터 최소화 감사. 개인 데이터를 보유하는 데이터베이스 스키마의 모든 필드를 검토하십시오. 문서화된 활성 사용 사례 없이 필드를 제거하거나 수집을 중단하십시오.
  5. 물리 삭제 구현. 사용자에 연결된 모든 개인 데이터에 대한 검증된 계단식 삭제를 구축하십시오. 삭제가 실제로 레코드를 제거하고 단순히 플래그를 지정하지 않는지 테스트하십시오.
  6. 타사 DPA 인벤토리. 개인 데이터를 수신하는 모든 SaaS 또는 클라우드 서비스를 나열하십시오. 각각에 대한 서명된 DPA 존재를 확인하십시오. DPA를 제공할 수 없는 서비스를 제거하십시오.
  7. 로깅 위생. PII에 대한 애플리케이션 로그를 감사하십시오. 모든 로그 수준에서 로그 출력에서 개인 데이터 값을 제거하십시오. 식별자만 로깅하십시오.
  8. 침해 감지 로깅. 인증 이벤트, 권한 부여 실패, 대량 데이터 접근에 대한 구조화된 로깅을 구현하십시오. 비정상적인 패턴에 대한 알림을 설정하십시오.
  9. 접근 통제 검토. 최소 권한 원칙에 맞서 데이터베이스 자격증명과 애플리케이션 역할을 감사하십시오. 애플리케이션 데이터베이스 사용자로부터 관리 액세스를 제거하십시오.
  10. 분석을 위한 가명화. 분석 및 타사 추적 호출의 직접 사용자 식별자를 사이트별 비밀을 사용한 HMAC 해시 값으로 교체하십시오.

주요 포인트

  • UK GDPR의 기술적 요구사항은 EU GDPR과 동일합니다. 브렉시트 이후 ICO가 이를 집행하며 통지 및 이전에 대한 ICO별 지침을 따라야 합니다.
  • 제32조는 리스크에 비례하는 적절한 기술적 조치를 요구합니다. 대부분의 애플리케이션에서 이는 강력한 암호화, 접근 통제, 가명화, 문서화된 침해 감지를 의미합니다.
  • 데이터 최소화는 법적 추상화가 아닌 개발자가 필드 수준에서 내리는 결정입니다. 필드 수집을 정당화할 수 없다면 수집하지 마십시오.
  • 삭제 권리는 백업 및 타사 처리자를 포함한 모든 시스템에 걸쳐 계단식 실제 삭제가 필요합니다. 소프트 삭제 플래그는 의무를 충족하지 않습니다.
  • 개인 데이터 값을 로깅하지 마십시오. 식별자를 로깅하십시오. 로그 파일 자체가 개인 데이터 저장소이며 가장 흔히 간과되는 침해 벡터 중 하나입니다.
  • 개인 데이터에 접촉하는 모든 타사 서비스와 서명된 DPA를 보유하십시오. 제공업체가 DPA를 제출할 수 없다면 그 목적에 합법적으로 사용할 수 없습니다.

자주 묻는 질문 (FAQ)

모든 사용자가 영국 외에 있는 경우에도 UK GDPR이 적용됩니까? UK GDPR은 사용자가 어디에 있는지에 관계없이 영국에 설립된 경우에 적용됩니다. 또한 영국에 있는 사람들에게 상품이나 서비스를 제공하거나 영국에 있는 사람들의 행동을 모니터링하는 영국 외 조직에도 적용됩니다. 비영국 청중을 위해 구축하는 영국 기반 개발자라면 UK GDPR이 처리 활동에 적용됩니다.

UK GDPR에 따라 암호화는 의무적입니까? 암호화는 제32조(1)(a)에 권장 조치로 명시적으로 나열되어 있습니다. 규정이 “리스크에 적절한” 조치를 요구하기 때문에 절대적인 필수 요건은 아닙니다. 실제로 인터넷을 통해 개인 데이터를 처리하는 애플리케이션의 경우 전송 중과 저장 시 데이터를 암호화하지 않는 것을 ICO에 정당화하기는 매우 어렵습니다. 필수로 취급하십시오.

ICO 통지가 필요한 개인 데이터 침해는 무엇입니까? 개인 데이터 침해는 개인 데이터의 우발적이거나 불법적인 파괴, 손실, 변경, 무단 공개, 또는 접근입니다. 여기에는 공개적으로 레코드를 노출한 잘못 구성된 S3 버킷, 고객 데이터가 포함된 이메일 계정에 공격자가 접근을 허용한 피싱 공격, 백업 없이 레코드를 실수로 삭제하는 것이 포함됩니다. 모든 침해가 ICO 통지를 요구하는 것은 아닙니다. 개인에게 위험을 초래할 가능성이 높은 것만입니다. 고위험 침해는 영향 받은 개인에게 직접 통지도 요구합니다.

개인 데이터를 얼마나 오래 보존해야 합니까? UK GDPR은 보존 기간을 명시하지 않습니다. 수집된 목적에 필요한 만큼만 데이터를 보존해야 합니다. 보유하는 각 데이터 범주의 보존 기간을 정의하고, 개인 정보 보호 공지에 문서화하고, 자동화된 제거를 구현하십시오. 재무 기록은 일반적으로 회사법에 따라 6년 동안 보존됩니다. 마케팅 동의 기록은 동의가 철회되거나 만료될 때까지 보관해야 합니다.

데이터 보호 책임자가 필요합니까? DPO는 공공 기관, 대규모로 민감한 개인 데이터를 처리하는 조직, 대규모 체계적 모니터링을 수행하는 조직에 의무적입니다. 대부분의 영국 소프트웨어 회사의 경우 DPO는 의무적이지 않지만 상당한 양의 개인 데이터를 처리하는 경우 권장됩니다. ICO는 웹사이트에서 이 임계값에 대한 구체적인 지침을 제공합니다.

UK GDPR 비준수의 최대 벌금은 얼마입니까? ICO는 가장 심각한 위반에 대해 최대 1,750만 파운드 또는 전 세계 연간 매출액의 4%(더 높은 쪽)의 벌금을 부과할 수 있습니다. 870만 파운드 또는 전 세계 매출액의 2%의 하위 벌금은 덜 심각한 침해에 적용됩니다. 실제로 대부분의 ICO 벌금은 최대값보다 훨씬 낮으며 침해의 심각성, 조직의 협력, 문제를 해결하기 위한 조치에 맞게 조정됩니다.