ICO对英国组织的执法行动在2024年和2025年急剧增加，两年间因技术安全措施不足而征收的罚款总额超过1200万英镑。ICO执法通知中呈现出一贯的规律：遭受数据泄露且无法证明已实施适当技术控制措施的组织面临最严厉的处理结果。对开发者而言，这是一个直接的职业关切。您在加密、日志记录、访问控制和数据留存方面做出的决策，就是决定一个组织能否在ICO面前为自己辩护的技术控制措施。

本指南专为开发者和工程团队编写，而非法律或合规部门。它将UK GDPR的要求转化为具体的技术决策：实施什么、如何实施，以及每项措施存在的原因。

摘要

  • UK GDPR第32条要求与风险相称的"适当技术措施"。对于大多数处理个人数据的应用程序，这意味着静态和传输中的加密、可行时的假名化、访问控制以及有据可查的违规检测能力。
  • 导致GDPR风险敞口的最常见开发者错误：在调试输出中记录PII、软删除本应为满足删除权而硬删除的记录，以及未能与每个接触个人数据的第三方服务签订DPA。
  • 数据最小化是在字段级别做出的设计决策。如果您没有收集和存储某个字段的书面理由，请勿收集。
  • 删除权要求真正删除，并通过所有系统（包括备份和第三方处理者）进行级联。软删除无法满足该义务。

UK GDPR与EU GDPR：对开发者意味着什么变化

脱欧后，英国通过《2018年欧盟（退出）法》将EU GDPR框架保留为"UK GDPR"。对开发者而言，技术要求完全相同。差异在于行政层面：英国的监管机构是信息专员办公室（ICO），而非欧盟国家数据保护机构；英国与欧盟之间的跨境数据传输受英国充分性决定的约束（目前由欧盟维持，但会定期审查）。

实际含义是：如果您构建的软件符合EU GDPR的技术要求，它同样满足UK GDPR的技术要求，反之亦然。差异将出现在通知程序、传输机制以及ICO具体执法指导方面，后者在侧重点上有时与欧洲数据保护委员会（EDPB）的指导不同。

第32条：实际要求什么

UK GDPR第32条要求数据控制者和处理者实施"适当的技术和组织措施"，以确保与风险相适应的安全级别，同时考虑技术现状、实施成本以及处理的性质、范围、背景和目的。

这一措辞有意保持灵活性。在实践中的含义取决于您的风险状况，但第32条第1款给出了四个具体示例：

  1. 个人数据的假名化和加密
  2. 确保处理系统和服务持续保密性、完整性、可用性和弹性的能力
  3. 在发生物理或技术事故后及时恢复个人数据可用性和访问权限的能力
  4. 定期测试、评估和评价安全措施有效性的流程

“技术现状"并不意味着您必须实施最昂贵或最前沿的解决方案。它意味着当明显更优的方法（如Argon2）已经完善、广泛可用且实施成本并无实质性提升时，您无法为使用弱方法（如MD5密码哈希）进行辩护。

静态加密

密码。 切勿以明文存储密码，切勿使用MD5或SHA-1进行密码哈希处理。两者均完全不适用。请使用工作因子至少为12的bcrypt，或参数调整为在服务器硬件上至少耗时100毫秒的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（一年）的max-age是标准做法。如果您的部署允许，请提交到HSTS预加载列表。

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

混合内容。 从HTTPS页面通过HTTP提供任何资源（图像、脚本、样式表、API调用）会产生混合内容漏洞并削弱传输安全性。配置内容安全策略以阻止混合内容，并检查您的页面是否有任何非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合规

控制者与处理者。 如果您使用第三方服务代表您处理个人数据（交易邮件提供商、云基础设施提供商、支付处理商），他们是数据处理者，您是数据控制者。在该背景下，您对他们遵守UK GDPR负责。

数据处理协议。 您必须与每个代表您处理个人数据的第三方服务签订书面数据处理协议（DPA）。大多数主流SaaS提供商（AWS、Mailchimp、Stripe、Twilio、SendGrid）提供标准DPA。签署并保存这些协议。如果提供商无法提供DPA，您在UK GDPR下不能合法使用他们处理个人数据。

次级处理者。 您与处理者的DPA应列出其次级处理者（他们依次用于处理您数据的服务）。例如，您的交易邮件提供商可能使用AWS基础设施。您不需要与次级处理者直接签订DPA，但为了传输合规目的，您需要了解他们是谁以及数据在地理上在哪里被处理。

传输机制。 如果第三方服务在英国或欧盟以外处理数据，您需要建立合法的传输机制。对于从英国进行的传输，目前是英国特定机制（英国国际数据传输协议，或在可用时依赖英国充分性决定）。检查每个服务的数据驻留选项和传输文档。

访问控制

最小权限原则。 您的应用程序使用的数据库用户应拥有所需的最小权限：对特定表的读写访问，无管理员访问权限。为读取密集型服务（报告、分析）和写入密集型服务（面向用户的应用程序）创建单独的数据库凭据。这限制了凭据被攻破的爆炸半径。

基于角色的访问控制。 在您的应用程序中实施RBAC，定期审查角色分配。角色随时间会累积权限；定期对照每个角色实际需要的内容进行审计可以发现权限蔓延。

数据访问审计日志。 对于敏感数据，在应用程序层实施审计日志，记录哪个经过身份验证的用户在何时访问了哪条个人数据记录。这与应用程序错误日志是分开的，并且应该是防篡改的（一次写入或仅追加，应用程序代码的访问受限）。

开发者检查清单：需要实施的10项技术控制

  1. 密码哈希。 使用bcrypt（成本因子12+）或Argon2id。立即删除任何MD5或SHA-1密码哈希。
  2. 静态加密。 启用数据库级别的TDE，并对密钥存储在托管KMS中的高度敏感个人数据实施字段级AES-256-GCM加密。
  3. TLS配置。 强制实施TLS 1.2最低版本、TLS 1.3默认、一年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不规定具体的留存期。您只能在收集个人数据的目的所必需的时间内保留数据。为您持有的每类数据定义留存期，在隐私声明中记录，并实施自动清除。根据《公司法》，财务记录通常保留六年。营销同意记录应保留至同意被撤回或到期为止。

我们需要数据保护官吗？ DPO对公共机构、大规模处理敏感个人数据的组织以及开展大规模系统性监控的组织是强制性要求。对于大多数英国软件公司而言，DPO并非强制性要求，但如果您处理大量个人数据，则建议配置。ICO在其网站上就这一门槛提供了具体指导。

UK GDPR不合规的最高罚款是多少？ ICO可对最严重的违规行为处以最高1750万英镑或全球年营业额4%（以较高者为准）的罚款。对较轻微违规行为，适用最高870万英镑或全球营业额2%的较低档罚款。实际上，大多数ICO罚款远低于上限，并根据违规的严重程度、组织的配合程度以及为补救问题所采取的措施进行调整。