Các hành động thực thi của ICO đối với các tổ chức Anh đã tăng mạnh vào năm 2024 và 2025, với tổng số tiền phạt hơn 12 triệu bảng Anh trong hai năm vì những thiếu sót trong các biện pháp bảo mật kỹ thuật. Mô hình trong các thông báo thực thi của ICO là nhất quán: các tổ chức bị vi phạm và không thể chứng minh rằng họ đã triển khai các biện pháp kiểm soát kỹ thuật phù hợp phải đối mặt với kết quả khắc nghiệt nhất. Đối với các nhà phát triển, đây là mối quan tâm nghề nghiệp trực tiếp. Các quyết định bạn đưa ra về mã hóa, ghi nhật ký, kiểm soát truy cập và lưu giữ dữ liệu là các biện pháp kiểm soát kỹ thuật xác định liệu một tổ chức có thể tự bảo vệ mình trước ICO hay không.

Hướng dẫn này được viết cho các nhà phát triển và nhóm kỹ thuật, không phải cho các bộ phận pháp lý hoặc tuân thủ. Nó dịch các yêu cầu của UK GDPR thành các quyết định kỹ thuật cụ thể: triển khai gì, triển khai như thế nào và tại sao mỗi biện pháp tồn tại.

Tóm tắt

  • Điều 32 của UK GDPR yêu cầu “các biện pháp kỹ thuật phù hợp” tương xứng với rủi ro. Đối với hầu hết các ứng dụng xử lý dữ liệu cá nhân, điều này có nghĩa là mã hóa khi lưu trữ và khi truyền, giả danh hóa khi khả thi, kiểm soát truy cập và khả năng phát hiện vi phạm được ghi lại.
  • Các lỗi nhà phát triển phổ biến nhất tạo ra rủi ro GDPR: ghi nhật ký PII trong đầu ra gỡ lỗi, xóa mềm các bản ghi cần phải xóa cứng để thực hiện quyền xóa, và không thực hiện DPA với mọi dịch vụ bên thứ ba chạm vào dữ liệu cá nhân.
  • Tối thiểu hóa dữ liệu là quyết định thiết kế được thực hiện ở cấp độ trường. Nếu bạn không có lý do được ghi lại để thu thập và lưu trữ một trường, đừng thu thập nó.
  • Quyền xóa yêu cầu xóa thực sự, theo tầng qua tất cả các hệ thống bao gồm cả bản sao lưu và bên xử lý bên thứ ba. Xóa mềm không thỏa mãn nghĩa vụ.

UK GDPR vs. EU GDPR: những gì thay đổi đối với nhà phát triển

Sau Brexit, Vương quốc Anh giữ lại khung EU GDPR dưới dạng “UK GDPR” thông qua European Union (Withdrawal) Act 2018. Đối với các nhà phát triển, các yêu cầu kỹ thuật giống hệt nhau. Sự khác biệt là về mặt hành chính: cơ quan giám sát ở Vương quốc Anh là Information Commissioner’s Office (ICO), không phải cơ quan bảo vệ dữ liệu quốc gia của EU, và các chuyển giao xuyên biên giới giữa Vương quốc Anh và EU được điều chỉnh bởi quyết định đầy đủ của Vương quốc Anh (hiện được EU duy trì, mặc dù được xem xét định kỳ).

Hàm ý thực tế là nếu bạn xây dựng phần mềm tuân thủ các yêu cầu kỹ thuật của EU GDPR, nó thỏa mãn các yêu cầu kỹ thuật của UK GDPR. Điều ngược lại cũng đúng. Sự phân kỳ sẽ xảy ra trong các thủ tục thông báo, cơ chế chuyển giao và hướng dẫn thực thi cụ thể của ICO, đôi khi khác về nhấn mạnh so với hướng dẫn EDPB.

Điều 32: Nó thực sự yêu cầu gì

Điều 32 của UK GDPR yêu cầu các bên kiểm soát và xử lý thực hiện “các biện pháp kỹ thuật và tổ chức phù hợp” để đảm bảo mức độ bảo mật phù hợp với rủi ro, có tính đến trạng thái kỹ thuật, chi phí triển khai và bản chất, phạm vi, bối cảnh và mục đích của việc xử lý.

Ngôn ngữ đó có chủ ý linh hoạt. Ý nghĩa thực tế phụ thuộc vào hồ sơ rủi ro của bạn, nhưng Điều 32(1) đưa ra bốn ví dụ cụ thể:

  1. Giả danh hóa và mã hóa dữ liệu cá nhân
  2. Khả năng đảm bảo tính bảo mật, toàn vẹn, khả dụng và khả năng phục hồi liên tục của hệ thống và dịch vụ xử lý
  3. Khả năng khôi phục kịp thời tính khả dụng và quyền truy cập vào dữ liệu cá nhân sau sự cố vật lý hoặc kỹ thuật
  4. Quy trình thường xuyên kiểm tra, đánh giá và thẩm định hiệu quả của các biện pháp bảo mật

“Trạng thái kỹ thuật” không có nghĩa là bạn phải triển khai giải pháp đắt nhất hoặc tiên tiến nhất. Nó có nghĩa là bạn không thể biện minh cho việc sử dụng một phương pháp yếu (như MD5 để băm mật khẩu) khi các phương pháp tốt hơn rõ ràng (như Argon2) đã được thiết lập tốt, có sẵn rộng rãi và không đắt hơn đáng kể để triển khai.

Mã hóa khi lưu trữ

Mật khẩu. Không bao giờ lưu mật khẩu ở dạng văn bản thuần túy, và không bao giờ sử dụng MD5 hoặc SHA-1 để băm mật khẩu. Cả hai đều hoàn toàn không phù hợp. Sử dụng bcrypt với hệ số công việc ít nhất 12, hoặc Argon2id với các tham số được điều chỉnh để mất ít nhất 100ms trên phần cứng máy chủ của bạn. Argon2id là khuyến nghị hiện tại của OWASP và thích hợp hơn cho các triển khai mới.

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});

Mã hóa cơ sở dữ liệu. Bật mã hóa khi lưu trữ ở cấp độ cơ sở dữ liệu. Tất cả các cơ sở dữ liệu và dịch vụ được quản lý chính (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) đều hỗ trợ điều này. Mã hóa dữ liệu trong suốt (TDE) bảo vệ dữ liệu trên đĩa, nhưng không bảo vệ chống lại người dùng cơ sở dữ liệu bị xâm phạm có quyền truy cập truy vấn. Đối với các trường nhạy cảm cao (số bảo hiểm quốc gia, hồ sơ y tế, số tài khoản tài chính), hãy xem xét mã hóa trường ở cấp độ ứng dụng sử dụng AES-256-GCM với dịch vụ quản lý khóa (AWS KMS, Azure Key Vault, HashiCorp Vault). Khóa phải được lưu trữ riêng biệt với dữ liệu mà nó mã hóa.

Quản lý khóa. Không mã hóa cứng khóa mã hóa trong mã ứng dụng hoặc lưu trữ chúng trong cùng cơ sở dữ liệu với dữ liệu chúng bảo vệ. Sử dụng biến môi trường cho quá trình phát triển và dịch vụ quản lý khóa được quản lý cho sản xuất. Xoay khóa định kỳ và đảm bảo ứng dụng của bạn có thể xử lý xoay khóa mà không có thời gian ngừng hoạt động.

Những gì không nên làm. Không lưu trữ dữ liệu cá nhân dạng văn bản thuần túy trong tệp nhật ký, tệp tạm thời hoặc bộ nhớ đệm ứng dụng nơi mã hóa có thể không áp dụng. Kiểm tra mọi đường dẫn mã xử lý dữ liệu cá nhân và đảm bảo nó không vô tình lưu trữ các bản sao không được mã hóa.

Mã hóa khi truyền

Cấu hình TLS. Thực thi TLS 1.2 là tối thiểu, với TLS 1.3 là mặc định khi được hỗ trợ. Tắt hoàn toàn SSLv3, TLS 1.0 và TLS 1.1. Trên 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. Đặt header Strict-Transport-Security với giá trị max-age dài và includeSubDomains. Một max-age ít nhất 31536000 (một năm) là tiêu chuẩn. Gửi lên danh sách tải trước HSTS nếu việc triển khai của bạn cho phép.

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

Nội dung hỗn hợp. Phục vụ bất kỳ tài nguyên nào (hình ảnh, tập lệnh, bảng định kiểu, lệnh gọi API) qua HTTP từ trang HTTPS tạo ra lỗ hổng nội dung hỗn hợp và làm suy yếu bảo mật truyền tải. Cấu hình Chính sách Bảo mật Nội dung để chặn nội dung hỗn hợp và kiểm tra trang của bạn để tìm bất kỳ lượt tải tài nguyên không phải HTTPS nào.

Dịch vụ nội bộ. Mã hóa khi truyền áp dụng cho giao tiếp giữa các dịch vụ nội bộ cũng như lưu lượng truy cập phía người dùng. Kết nối cơ sở dữ liệu, kết nối hàng đợi thông báo và lệnh gọi vi dịch vụ đều phải sử dụng TLS. Nhiều nhà phát triển mã hóa đúng lớp phía người dùng và bỏ qua mạng nội bộ.

Tối thiểu hóa dữ liệu trong mã

Tối thiểu hóa dữ liệu không phải là một khái niệm trừu tượng pháp lý. Đó là quyết định thiết kế được thực hiện từng trường một. Trước khi thu thập bất kỳ phần dữ liệu cá nhân nào, hãy hỏi: ứng dụng có thực sự cần điều này để hoạt động không? Nếu bạn không thể trả lời câu hỏi đó với một trường hợp sử dụng cụ thể, đừng thu thập nó.

Trong thực tế điều này có nghĩa là:

  • Xóa các trường biểu mẫu tùy chọn và có mục đích mơ hồ (“ngày sinh” trên đăng ký bản tin không có yêu cầu xác minh tuổi)
  • Kiểm tra thường xuyên lược đồ cơ sở dữ liệu của bạn và xóa các cột chứa dữ liệu cá nhân không có sử dụng tích cực
  • Đặt khoảng thời gian lưu giữ ở cấp độ lược đồ khi có thể, sử dụng các công việc theo lịch trình để tự động xóa các bản ghi đã hết hạn
  • Tránh thu thập dữ liệu cá nhân nhạy cảm cao (thông tin sức khỏe, chi tiết tài chính, quan điểm chính trị) trừ khi ứng dụng của bạn thực sự cần chúng, vì đánh giá rủi ro Điều 32 tăng theo mức độ nhạy cảm của dữ liệu được xử lý

Nguyên tắc trách nhiệm giải trình của ICO yêu cầu bạn có thể chứng minh rằng bạn đã cân nhắc tối thiểu hóa dữ liệu. Các quyết định thiết kế được ghi lại trong kiến trúc hoặc ghi chú sprint của bạn thỏa mãn điều này. Các quyết định không được ghi lại thì không.

Giả danh hóa

Giả danh hóa thay thế thông tin nhận dạng trực tiếp bằng mã thông báo hoặc định danh không thể xác định cá nhân mà không có quyền truy cập vào khóa hoặc bảng ánh xạ được giữ riêng biệt. Điều 32 liệt kê nó rõ ràng là một biện pháp kỹ thuật được khuyến nghị, và Điều 89 cung cấp các nghĩa vụ giảm cho việc xử lý dữ liệu giả danh hóa cho mục đích nghiên cứu.

Đối với phân tích và theo dõi hành vi, một mẫu phổ biến là băm các định danh người dùng với muối cụ thể theo trang bằng SHA-256 trước khi chuyển chúng sang hệ thống phân tích của bạn:

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()

Muối phải được lưu trữ riêng biệt với dữ liệu phân tích. Nếu không có nó, hàm băm không thể được đảo ngược để xác định cá nhân. Điều này có nghĩa là hệ thống phân tích của bạn chỉ giữ các định danh giả danh, giảm hồ sơ rủi ro vi phạm hệ thống đó.

Giả danh hóa không phải là ẩn danh hóa. Nếu bạn giữ khóa ánh xạ, ICO coi dữ liệu giả danh hóa là dữ liệu cá nhân. Ẩn danh hóa hoàn toàn, nơi việc nhận dạng lại không thể xảy ra ngay cả với thông tin bổ sung có sẵn một cách hợp lý, loại bỏ dữ liệu hoàn toàn khỏi phạm vi GDPR. Đạt được ẩn danh hóa thực sự là khó khăn trong thực tế; hầu hết các triển khai tạo ra dữ liệu giả danh, vẫn thuộc phạm vi GDPR nhưng với rủi ro giảm.

Quyền xóa: Thực hiện đúng cách

Quyền xóa (Điều 17) là một trong những nghĩa vụ GDPR đòi hỏi kỹ thuật nhất để thực hiện đúng. Các yêu cầu là cụ thể:

Xóa cứng, không phải xóa mềm. Đặt cờ is_deleted và lọc nó ra khỏi các truy vấn không thỏa mãn quyền xóa. Dữ liệu phải được thực sự xóa khỏi cơ sở dữ liệu. Xây dựng chức năng xóa cứng cho mọi thực thể giữ dữ liệu cá nhân.

Xóa theo tầng. Xóa bản ghi người dùng là không đủ nếu dữ liệu cá nhân cũng được giữ trong các bảng liên quan (đơn hàng, địa chỉ, nhật ký hoạt động, sở thích, tệp đã tải lên). Lập bản đồ mọi bảng chứa dữ liệu cá nhân được liên kết với định danh người dùng và đảm bảo xóa theo tầng đúng cách, hoặc triển khai công việc xóa rõ ràng loại bỏ tất cả dữ liệu liên quan theo cách nguyên tử.

Bộ xử lý bên thứ ba. Nếu bạn đã gửi dữ liệu cá nhân đến dịch vụ bên thứ ba (nền tảng tiếp thị qua email, CRM, công cụ phân tích, bộ xử lý thanh toán), nghĩa vụ xóa của bạn mở rộng đến việc hướng dẫn bộ xử lý đó xóa dữ liệu. Điều này yêu cầu:

  • Kiểm kê được ghi lại về mọi dịch vụ bên thứ ba nhận dữ liệu cá nhân
  • Cơ chế xóa đã được xác nhận cho từng dịch vụ (lệnh gọi API, phiếu hỗ trợ, xử lý yêu cầu chủ thể dữ liệu tự động)
  • Bằng chứng rằng việc xóa đã hoàn tất

Bản sao lưu. Bản sao lưu là vấn đề xóa thường bị bỏ qua nhất. Nếu bạn thực hiện sao lưu cơ sở dữ liệu hàng ngày với thời gian lưu giữ 90 ngày, yêu cầu xóa được thỏa mãn trong cơ sở dữ liệu trực tiếp sẽ không được thỏa mãn trong các bản sao lưu cho đến khi chúng hết hạn. Lập trường của ICO là các bản sao lưu được khôi phục sau khi xóa không được tái đưa ra dữ liệu cá nhân đã bị xóa. Các phương pháp thực tế bao gồm: loại trừ các bản ghi đã xóa khỏi xuất bản sao lưu khi khả thi, triển khai quy trình xóa dành riêng cho bản sao lưu, hoặc sử dụng mã hóa ở cấp độ trường và xóa khóa (làm dữ liệu không thể đọc được, tiếp cận tiêu chuẩn xóa).

Ngoại lệ. Quyền xóa không phải là tuyệt đối. Bạn có thể giữ dữ liệu cần thiết cho các yêu cầu pháp lý, tuân thủ pháp định (ví dụ: hồ sơ tài chính theo Đạo luật Công ty), hoặc mục đích lợi ích công cộng. Ghi lại ngoại lệ và truyền đạt nó cho chủ thể dữ liệu khi bạn từ chối hoặc thực hiện một phần yêu cầu xóa.

Phát hiện vi phạm và yêu cầu thông báo 72 giờ

Điều 33 của UK GDPR yêu cầu bạn thông báo cho ICO trong vòng 72 giờ kể từ khi biết về vi phạm dữ liệu cá nhân có khả năng gây ra rủi ro cho các cá nhân. Đây không phải là 72 giờ kể từ khi vi phạm xảy ra. Đó là 72 giờ kể từ khi bạn biết. Sự phân biệt này tạo ra động lực trực tiếp để xây dựng khả năng phát hiện vi phạm, vì đồng hồ bắt đầu chạy khi bạn tìm thấy nó.

Những gì cần ghi nhật ký để phát hiện vi phạm. Kiến trúc ghi nhật ký của bạn nên ghi lại:

  • Sự kiện xác thực: đăng nhập thành công và thất bại, thách thức MFA, đặt lại mật khẩu
  • Lỗi ủy quyền: các yêu cầu bị từ chối do kiểm tra quyền
  • Truy cập dữ liệu: ai đã truy cập dữ liệu cá nhân nào và khi nào, đặc biệt là xuất hàng loạt hoặc khối lượng truy vấn bất thường
  • Thay đổi cấu hình: thay đổi quyền người dùng, khóa mã hóa hoặc cài đặt lưu giữ dữ liệu
  • Mẫu bất thường: truy cập từ địa chỉ IP bất thường hoặc vào những thời điểm bất thường, lượt đọc khối lượng cao của các bảng dữ liệu cá nhân

Những gì không nên ghi nhật ký. Không ghi nhật ký các giá trị dữ liệu cá nhân trong nhật ký ứng dụng của bạn. Nhật ký gỡ lỗi ghi lại toàn bộ nội dung yêu cầu, truy vấn cơ sở dữ liệu với các giá trị tham số được thay thế, hoặc dữ liệu biểu mẫu do người dùng nhập tạo ra các kho dữ liệu cá nhân thứ cấp khó quản lý và chính bản thân chúng thuộc phạm vi GDPR. Ghi nhật ký các định danh (ID người dùng, ID phiên, ID yêu cầu) thay vì các giá trị.

1# Sai: ghi lại địa chỉ email thực tế
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Đúng: chỉ ghi lại một định danh
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Lập kế hoạch ứng phó vi phạm. Ghi nhật ký cho phép phát hiện, nhưng bạn cần một quy trình được ghi lại về những gì xảy ra khi bạn phát hiện vi phạm. Ai được thông báo nội bộ? Ai đưa ra quyết định thông báo ICO? Thông báo ICO cần chứa thông tin gì? Xây dựng quy trình này trước khi bạn cần.

Tuân thủ API bên thứ ba

Bên kiểm soát vs bên xử lý. Nếu bạn đang sử dụng dịch vụ bên thứ ba xử lý dữ liệu cá nhân thay mặt bạn (nhà cung cấp email giao dịch, nhà cung cấp cơ sở hạ tầng đám mây, bộ xử lý thanh toán), họ là bộ xử lý dữ liệu và bạn là bên kiểm soát. Bạn chịu trách nhiệm về việc tuân thủ UK GDPR của họ trong bối cảnh đó.

Thỏa thuận xử lý dữ liệu. Bạn phải có Thỏa thuận xử lý dữ liệu (DPA) bằng văn bản với mọi dịch vụ bên thứ ba xử lý dữ liệu cá nhân thay mặt bạn. Hầu hết các nhà cung cấp SaaS lớn (AWS, Mailchimp, Stripe, Twilio, SendGrid) cung cấp DPA tiêu chuẩn. Ký và lưu giữ chúng. Nếu nhà cung cấp không thể cung cấp DPA, bạn không thể sử dụng họ hợp pháp để xử lý dữ liệu cá nhân theo UK GDPR.

Bộ xử lý phụ. DPA của bạn với bộ xử lý nên liệt kê các bộ xử lý phụ của họ (các dịch vụ họ lần lượt sử dụng để xử lý dữ liệu của bạn). Ví dụ, nhà cung cấp email giao dịch của bạn có thể sử dụng cơ sở hạ tầng AWS. Bạn không bắt buộc phải có DPA trực tiếp với các bộ xử lý phụ, nhưng bạn cần biết họ là ai và dữ liệu đang được xử lý về mặt địa lý ở đâu cho mục đích tuân thủ chuyển giao.

Cơ chế chuyển giao. Nếu dịch vụ bên thứ ba xử lý dữ liệu bên ngoài Vương quốc Anh hoặc EU, bạn cần có cơ chế chuyển giao hợp pháp. Đối với các chuyển giao từ Vương quốc Anh, hiện tại đây là các cơ chế đặc thù của Vương quốc Anh (Thỏa thuận chuyển giao dữ liệu quốc tế của Vương quốc Anh, hoặc dựa vào các quyết định đầy đủ của Vương quốc Anh khi có sẵn). Kiểm tra các tùy chọn cư trú dữ liệu và tài liệu chuyển giao của từng dịch vụ.

Kiểm soát truy cập

Nguyên tắc đặc quyền tối thiểu. Người dùng cơ sở dữ liệu được ứng dụng của bạn sử dụng phải có quyền tối thiểu cần thiết: đọc và ghi vào các bảng cụ thể, không có quyền truy cập quản trị. Tạo thông tin xác thực cơ sở dữ liệu riêng biệt cho các dịch vụ đọc nhiều (báo cáo, phân tích) và dịch vụ ghi nhiều (ứng dụng phía người dùng). Điều này giới hạn bán kính vụ nổ của thông tin xác thực bị xâm phạm.

Kiểm soát truy cập dựa trên vai trò. Triển khai RBAC trong ứng dụng của bạn và xem xét các phân công vai trò thường xuyên. Các vai trò có xu hướng tích lũy quyền theo thời gian; kiểm tra định kỳ so với những gì mỗi vai trò thực sự cần phát hiện tình trạng gia tăng đặc quyền.

Nhật ký kiểm tra để truy cập dữ liệu. Đối với dữ liệu nhạy cảm, triển khai ghi nhật ký kiểm tra ở cấp độ lớp ứng dụng ghi lại người dùng đã xác thực nào đã truy cập bản ghi dữ liệu cá nhân nào và khi nào. Điều này tách biệt với nhật ký lỗi ứng dụng của bạn và phải chống giả mạo (chỉ ghi một lần hoặc chỉ thêm vào, với quyền truy cập bị hạn chế từ mã ứng dụng).

Danh sách kiểm tra dành cho nhà phát triển: 10 biện pháp kiểm soát kỹ thuật cần triển khai

  1. Băm mật khẩu. Sử dụng bcrypt (hệ số chi phí 12+) hoặc Argon2id. Xóa ngay lập tức mọi băm mật khẩu MD5 hoặc SHA-1.
  2. Mã hóa khi lưu trữ. Bật TDE ở cấp độ cơ sở dữ liệu và triển khai mã hóa trường AES-256-GCM cho dữ liệu cá nhân nhạy cảm cao với khóa được giữ trong KMS được quản lý.
  3. Cấu hình TLS. Thực thi TLS 1.2 tối thiểu, TLS 1.3 mặc định, HSTS với max-age một năm, không có nội dung hỗn hợp.
  4. Kiểm tra tối thiểu hóa dữ liệu. Xem xét mọi trường trong lược đồ cơ sở dữ liệu của bạn chứa dữ liệu cá nhân. Xóa hoặc ngừng thu thập bất kỳ trường nào không có trường hợp sử dụng được ghi lại và tích cực.
  5. Triển khai xóa cứng. Xây dựng xóa theo tầng được xác minh cho tất cả dữ liệu cá nhân được liên kết với người dùng. Kiểm tra rằng việc xóa thực sự loại bỏ các bản ghi và không chỉ gắn cờ chúng.
  6. Kiểm kê DPA bên thứ ba. Liệt kê mọi dịch vụ SaaS hoặc đám mây nhận dữ liệu cá nhân. Xác nhận sự tồn tại của DPA đã ký cho từng dịch vụ. Xóa bất kỳ dịch vụ nào không thể cung cấp dịch vụ đó.
  7. Vệ sinh ghi nhật ký. Kiểm tra nhật ký ứng dụng của bạn để tìm PII. Xóa các giá trị dữ liệu cá nhân khỏi đầu ra nhật ký ở mọi cấp độ nhật ký. Chỉ ghi nhật ký các định danh.
  8. Ghi nhật ký phát hiện vi phạm. Triển khai ghi nhật ký có cấu trúc cho các sự kiện xác thực, lỗi ủy quyền và truy cập dữ liệu hàng loạt. Thiết lập cảnh báo cho các mẫu bất thường.
  9. Xem xét kiểm soát truy cập. Kiểm tra thông tin xác thực cơ sở dữ liệu và vai trò ứng dụng so với nguyên tắc đặc quyền tối thiểu. Xóa quyền truy cập quản trị khỏi người dùng cơ sở dữ liệu ứng dụng.
  10. Giả danh hóa cho phân tích. Thay thế các định danh người dùng trực tiếp trong các lệnh gọi phân tích và theo dõi bên thứ ba bằng các giá trị được băm HMAC sử dụng bí mật đặc thù theo trang.

Điểm mấu chốt

  • Các yêu cầu kỹ thuật của UK GDPR giống hệt EU GDPR. Sau Brexit, ICO thực thi chúng và bạn cần tuân theo hướng dẫn đặc thù của ICO về thông báo và chuyển giao.
  • Điều 32 yêu cầu các biện pháp kỹ thuật phù hợp tương xứng với rủi ro của bạn. Đối với hầu hết các ứng dụng, điều này có nghĩa là mã hóa mạnh, kiểm soát truy cập, giả danh hóa và phát hiện vi phạm được ghi lại.
  • Tối thiểu hóa dữ liệu là quyết định ở cấp độ trường do các nhà phát triển đưa ra, không phải là một khái niệm trừu tượng pháp lý. Nếu bạn không thể biện minh cho việc thu thập một trường, đừng thu thập nó.
  • Quyền xóa yêu cầu xóa thực sự theo tầng qua tất cả các hệ thống bao gồm cả bản sao lưu và bộ xử lý bên thứ ba. Cờ xóa mềm không thỏa mãn nghĩa vụ.
  • Không ghi nhật ký các giá trị dữ liệu cá nhân. Ghi nhật ký các định danh. Các tệp nhật ký của bạn chính bản thân chúng là kho lưu trữ dữ liệu cá nhân và một trong những vectơ vi phạm thường bị bỏ qua nhất.
  • Có DPA đã ký với mọi dịch vụ bên thứ ba chạm vào dữ liệu cá nhân. Nếu nhà cung cấp không thể cung cấp DPA, bạn không thể sử dụng họ hợp pháp cho mục đích đó.

Câu hỏi thường gặp (FAQ)

UK GDPR có áp dụng nếu tất cả người dùng của tôi ở ngoài Vương quốc Anh không? UK GDPR áp dụng nếu bạn được thành lập tại Vương quốc Anh, bất kể người dùng của bạn ở đâu. Nó cũng áp dụng cho các tổ chức bên ngoài Vương quốc Anh cung cấp hàng hóa hoặc dịch vụ cho người ở Vương quốc Anh hoặc giám sát hành vi của người ở Vương quốc Anh. Nếu bạn là nhà phát triển có trụ sở tại Vương quốc Anh xây dựng cho đối tượng không phải người Anh, UK GDPR áp dụng cho các hoạt động xử lý của bạn.

Mã hóa có bắt buộc theo UK GDPR không? Mã hóa được liệt kê rõ ràng trong Điều 32(1)(a) là một biện pháp được khuyến nghị. Đây không phải là yêu cầu bắt buộc tuyệt đối, vì quy định yêu cầu các biện pháp “phù hợp với rủi ro”. Trong thực tế, đối với bất kỳ ứng dụng nào xử lý dữ liệu cá nhân qua internet, sẽ rất khó biện minh với ICO về việc không mã hóa dữ liệu khi truyền và khi lưu trữ. Coi nó là bắt buộc.

Điều gì được tính là vi phạm dữ liệu cá nhân yêu cầu thông báo ICO? Vi phạm dữ liệu cá nhân là bất kỳ sự phá hủy, mất mát, thay đổi, tiết lộ trái phép hoặc truy cập trái phép đến dữ liệu cá nhân nào đó. Điều này bao gồm một nhóm S3 được cấu hình sai để lộ các bản ghi công khai, một cuộc tấn công lừa đảo cấp cho kẻ tấn công quyền truy cập vào tài khoản email của bạn chứa dữ liệu khách hàng, và xóa ngẫu nhiên các bản ghi không có bản sao lưu. Không phải tất cả các vi phạm đều yêu cầu thông báo ICO: chỉ những vi phạm có khả năng gây ra rủi ro cho các cá nhân. Các vi phạm rủi ro cao cũng yêu cầu thông báo trực tiếp cho các cá nhân bị ảnh hưởng.

Chúng ta cần lưu giữ dữ liệu cá nhân bao lâu? UK GDPR không chỉ định khoảng thời gian lưu giữ. Bạn phải lưu giữ dữ liệu chỉ miễn là cần thiết cho mục đích mà nó được thu thập. Xác định khoảng thời gian lưu giữ cho từng danh mục dữ liệu bạn giữ, ghi lại chúng trong thông báo quyền riêng tư của bạn và triển khai việc xóa tự động. Hồ sơ tài chính thường được lưu giữ sáu năm theo Đạo luật Công ty. Hồ sơ đồng ý tiếp thị nên được giữ cho đến khi đồng ý bị rút lại hoặc hết hạn.

Chúng ta có cần Cán bộ Bảo vệ Dữ liệu không? DPO là bắt buộc đối với cơ quan công quyền, các tổ chức xử lý dữ liệu cá nhân nhạy cảm ở quy mô lớn và các tổ chức thực hiện giám sát hệ thống quy mô lớn. Đối với hầu hết các công ty phần mềm của Vương quốc Anh, DPO không bắt buộc nhưng được khuyên dùng nếu bạn xử lý khối lượng đáng kể dữ liệu cá nhân. ICO cung cấp hướng dẫn cụ thể về ngưỡng này trên trang web của họ.

Mức phạt tối đa cho việc không tuân thủ UK GDPR là bao nhiêu? ICO có thể phát hành các khoản phạt lên đến 17,5 triệu bảng Anh hoặc 4% doanh thu hàng năm toàn cầu (tùy theo mức nào cao hơn) cho các vi phạm nghiêm trọng nhất. Các khoản phạt ở cấp thấp hơn lên đến 8,7 triệu bảng Anh hoặc 2% doanh thu toàn cầu áp dụng cho các vi phạm ít nghiêm trọng hơn. Trong thực tế, hầu hết các khoản phạt của ICO thấp hơn đáng kể so với mức tối đa và được hiệu chỉnh theo mức độ nghiêm trọng của vi phạm, sự hợp tác của tổ chức và các bước thực hiện để khắc phục vấn đề.