制定数据加密指南

以下为在组织内对客户数据、支付信息与日志实施加密的治理指南。内容聚焦政策、标准、流程与职责，并对技术实现提出可操作建议，参考 NIST、PCI DSS 与行业通行做法。请根据组织适用监管环境（如 GDPR、PIPL、PCI DSS v4.0）进行本地化细化。

一、范围与数据分类
- 数据域与敏感度分级：
  - 客户数据：PII（姓名、地址、电话、邮箱、身份证件号、用户标识等）。将高敏感 PII（如身份证件号、地理位置、财务信息）标为“机密”或“受限”。
  - 支付信息：PAN（主账号）、持卡人姓名、有效期、敏感认证数据（CVV/CVC、PIN、磁道／芯片数据）。敏感认证数据不得存储。
  - 日志：运营、应用、审计日志。对可能含 PII 或支付相关字段的日志单独分类为“受控日志数据”。
- 数据责任分配：
  - 数据所有者（业务负责人）：定义敏感度、用途与保留期。
  - 数据保管人（IT/安全）：实施加密与密钥管理、访问控制与监控。
  - 合规负责人：对齐监管及标准（GDPR/PIPL/PCI DSS），评估例外。

二、加密总体原则
- 在传输与静态两种状态均采用强加密；优先使用经广泛验证并符合 NIST/FIPS 的算法与模块。
- 采用分层加密：存储层（磁盘/卷/TDE）+ 应用/字段级加密；对支付数据使用令牌化降低暴露面。
- 最小化可解密面：按租户/业务域/数据集进行密钥分割，严格隔离解密路径。
- 采用认证加密（AEAD）以同时保障机密性与完整性。

三、客户数据加密指南
- 静态数据（At Rest）：
  - 存储层：启用磁盘或卷加密（如 AES-XTS-256），但不替代字段级加密。
  - 数据库：启用 TDE（AES-256），并对高敏字段进行列/字段级加密（建议 AES-256-GCM；每条记录唯一随机 96-bit IV；存储密文、IV、认证标签）。
  - 应用层：对身份证件号、联系方式、位置信息等进行字段级加密或伪匿名化（HMAC-SHA-256 加密盐/pepper在 HSM/KMS 管控），支持访问按需解密。
- 传输中（In Transit）：
  - 使用 TLS 1.2 及以上，优先 TLS 1.3；仅启用强套件（AES-GCM 或 CHACHA20-POLY1305），启用 PFS（ECDHE）。
  - 内部服务间可采用 mTLS；严禁明文或过时协议（TLS1.0/1.1、SSL）。
- 展示与使用：
  - 避免在界面或报表展示完整高敏 PII；实施掩码策略（如手机号仅显示后四位）。
  - 数据最小化：只在必要场景解密，记录访问与解密审计。

四、支付信息加密与合规（重点遵循 PCI DSS）
- 存储与禁止事项：
  - 不得存储敏感认证数据（CVV/CVC、PIN、磁道/芯片数据）于任何持久介质或日志；授权完成后即刻从内存清理。
  - 若存储 PAN，必须使用强加密或令牌化使其不可读。
  - PAN 展示时实施掩码：最多显示前六与后四位（通常仅显示后四位）。
- 令牌化（Tokenization）：
  - 优先使用令牌化替代保存真实 PAN；令牌应非可逆、随机或高熵生成。
  - 令牌映射表存放于独立安全域，访问受限并受审计；解令牌操作需双人审批或高权限工单。
- 加密实现：
  - 字段级：AES-256-GCM（AEAD）；可采用信封加密（Envelope Encryption：使用 KMS/HSM 保护 DEK，由 KEK 包裹）。
  - 端到端：对线下场景可采用 P2PE；线上支付链路全程 TLS 1.2+/1.3。
- 分段与访问控制：
  - 网络分段隔离持卡人数据环境（CDE）；严格访问控制与监控，最小权限原则。
- 日志与监控（PCI DSS 要求）：
  - 审计日志不可记录 PAN 全值或敏感认证数据；发生异常时以令牌或掩码替代。
  - 日志保留与可用性应满足 PCI DSS（通常至少保留 1 年，其中近 3 个月可即时检索）；具体期限以组织合规评估为准。

五、日志加密与敏感信息治理
- 日志设计：
  - 采用白名单字段策略：明确定义允许记录的字段；默认拒绝敏感字段写入。
  - 结构化日志（JSON/CEF），字段级标签（如 pii=true, pan=true）便于管控与稽核。
  - 内联脱敏与红化：在日志代理或应用侧对可能含 PII/PAN 的字段进行掩码或令牌化；严禁记录密钥、口令、访问令牌、会话 ID。
- 加密与完整性：
  - 传输：日志代理到收集端使用 TLS 1.2+/1.3。
  - 静态：集中式日志存储启用 AES-256 加密；对高敏日志采用字段级加密或索引分离。
  - 完整性保障：对日志批次进行签名或哈希链（如每批 HMAC-SHA-256/数字签名），实现篡改检测与可验证性；采用追加写/不可篡改存储（WORM/append-only）满足合规与取证。
- 保留与访问：
  - 定义分级保留策略（运营日志较短，审计/安全日志较长）；遵循数据最小化与法定保留期。
  - 访问审计与隔离：仅安全与合规团队可访问原始审计日志；为业务提供脱敏副本。

六、密钥管理（KMS/HSM）
- 生成与质量：
  - 使用 FIPS 140-3 验证模块或等效强随机源生成密钥；避免自研算法。
- 分层与分隔：
  - 根密钥/主密钥存于 HSM；数据密钥（DEK）由 KMS 管理；按系统/租户/数据域分割密钥。
  - 使用信封加密：KMS/HSM 保护 KEK，KEK 包裹 DEK；密钥材料不落盘明文。
- 生命周期与轮换：
  - 定期轮换（如 12 个月或依据风险与合规要求；遇到泄漏迹象立即轮换），支持撤销与销毁。
  - 密钥启用审批、双人控制与分离职责；所有操作留痕审计。
- 访问与使用：
  - 最小授权调用 KMS；避免将密钥下发到应用文件系统，优先远程加解密 API 或短期会话密钥。
  - 采用硬件加密加速与密钥封装以降低密钥暴露。

七、访问控制与解密治理
- 角色与流程：
  - 解密为受控操作：需业务理由、审批与时间限制；采用“即时访问”（JIT）与“限时凭证”。
  - 建立紧急“破玻璃”流程，包含事后复盘与审计。
- 技术控制：
  - 应用端实施细粒度授权与属性基访问控制（ABAC/RBAC）；对高敏字段进行服务端解密，避免在客户端侧暴露密钥。
  - 全量记录解密事件、访问主体、目的与结果。

八、安全验证与合规证据
- 配置基线与检测：
  - 加密配置基线（算法、密钥长度、套件、IV/nonce 使用规范）纳入代码与基础设施即代码的合规扫描。
  - 对 GCM 等 AEAD 强制唯一 nonce；提供库级封装防止重复。
- 测试与审计：
  - 定期渗透测试与加密实施检查；对日志完整性进行抽样验证（签名/哈希链校验）。
  - 保留合规证据：密钥轮换记录、访问审计、异常响应与销毁证明。

九、备份与灾备
- 备份全程加密（AES-256）；备份密钥与生产密钥隔离管理。
- 离线保管与跨域灾备，定期演练恢复并验证解密路径与权限控制。

十、例外管理
- 所有加密例外需由数据所有者、安全与合规共同审批，明确补偿控制、期限与复评计划。
- 在临时技术限制下采用强替代措施（如令牌化/脱敏），并记录风险接受。

十一、标准参考（用于内部政策映射）
- NIST SP 800-57（密钥管理）、SP 800-38D（AES-GCM）、SP 800-52r2（TLS 配置）。
- FIPS 140-3（密码模块验证）。
- PCI DSS v4.0（保护账户数据、日志与监控要求）。
- ISO/IEC 27001/27002（信息安全管理与控制）。

实施清单（摘要）
- 明确数据分类与加密范围；设定展示掩码规则。
- 启用 TLS 1.3；禁用弱套件与旧协议。
- 对客户高敏 PII与支付字段实施字段级 AEAD 加密；PAN 使用令牌化。
- 严禁存储 CVV/PIN/磁道数据；日志端到端加密与内联脱敏。
- 部署 KMS/HSM；实施信封加密、密钥分割与定期轮换。
- 建立不可篡改日志与完整性验证；满足保留与即时检索要求。
- 强化访问流程（审批、JIT、审计）；定期测试与合规证据留存。

如需，我可提供面向具体技术栈（如某数据库/消息系统/日志平台）的详细加密配置基线与自动化校验脚本规范。

加密员工记录指南（数据治理）

1. 目的与范围
- 目标：将员工记录在全生命周期内以可验证的方式加密，降低未授权访问与数据泄露风险，满足法律与合规要求。
- 范围：人力资源系统、薪酬与福利平台、绩效与培训系统、文件存储与协作工具、备份与日志、传输与接口、移动与终端设备。

2. 数据定义与分类
- 员工记录通常包含个人身份信息（PII）与敏感个人信息（SPI），需至少归类为“机密”或“受限”级别。
- 强制字段级加密（或代币化）的典型数据：
  - 身份与证件号、国民身份证/社保号、护照号
  - 银行账号、工资、税务信息
  - 联系方式（电话、邮箱、住址）
  - 医疗与残疾相关信息、紧急联系人
  - 背调结果、绩效评价、纪律记录
- 元数据与索引中不得明文包含敏感字段的可还原值（例如不在日志/索引中写入明文证件号）。

3. 角色与职责
- 数据所有者（HR负责人）：定义加密适用范围、审批解密使用场景与例外。
- 数据管理员/数据管家（HR数据管理）：维护数据字典与加密清单，协调数据质量与掩码策略。
- 信息安全与加密服务团队：制定加密标准、管理密钥与KMS/HSM、监控与审计。
- 应用与数据库团队：实施字段/表/磁盘加密、接口加密、性能与可用性保障。
- 法务与合规：对齐 GDPR/PIPL 等法规要求与合同条款。

4. 加密策略总则
- 默认加密：所有受限/机密级员工数据在存储与传输中均需加密（“加密优先”）。
- 最小权限与分层解密：仅在业务必要时解密；优先采用字段级或记录级精细解密，避免系统范围内长时间明文。
- 与数据最小化协同：仅收集、处理所需字段；减少加密/解密面。
- 不在客户端或日志持久化明文敏感数据；采用掩码显示（如仅显示证件号后4位）。

5. 数据生命周期控制
- 采集：在客户端到后端采用强 TLS；在后端入库前进行字段级加密或代币化。
- 存储：数据库、对象存储、文件系统使用加密；备份与快照同等加密。
- 使用：按需解密，记录理由与审批；输出报表采用掩码或代币。
- 共享：对外接口以传输层加密＋载荷签名/加密；跨境传输需法务审批与保障措施。
- 归档与销毁：归档数据保持加密；销毁通过密钥撤销（加密报废/crypto-shredding）与物理删除双重控制。

6. 技术标准（算法与协议）
- 存储加密（推荐）
  - 对称：AES-256-GCM 或 ChaCha20-Poly1305（带认证保证）。
  - 数据库透明加密（TDE）：AES-256；但对高敏字段应加字段级加密以减少广泛解密风险。
  - 文件/对象：采用AEAD模式；避免ECB与过时算法（DES、RC4、MD5、SHA-1）。
- 传输加密
  - TLS 1.3（优先）或 TLS 1.2（仅强制 ECDHE + AES-GCM/ChaCha20-Poly1305；禁用TLS 1.0/1.1与弱套件）。
  - API 载荷可选额外签名（Ed25519）与应用层加密（JWE）。
- 密钥与公钥标准
  - 非对称：RSA ≥2048（优先 3072）或椭圆曲线 P-256/X25519；签名可用 Ed25519。
  - 哈希：SHA-256/384；密码存储使用 KDF（Argon2id 优先；备选 bcrypt/scrypt）。
    - Argon2id示例参数：内存 64–256MB，迭代 2–4，并行度 1–4（结合风险与硬件评估）。

7. 密钥管理（KMS/HSM）
- 集中式KMS或HSM管理密钥；支持密钥分级：主密钥（KEK）与数据密钥（DEK）采用信封加密。
- 密钥生命周期：生成（高熵、硬件来源）、分发（安全通道）、使用（最小暴露）、轮换（至少年度或事件驱动）、撤销与销毁（可验证）。
- 访问控制：密钥使用需基于服务身份与RBAC/ABAC；禁止将密钥与密文共存同一不受控位置（如同一备份包）。
- 审计：所有密钥操作与解密事件可追踪、不可抵赖；异常告警与阈值控制。

8. 访问控制与解密授权
- 解密仅在特定业务流程中进行，采用细粒度授权与临时访问令牌；支持“按字段、按记录、按时段”的访问限制。
- 双人审批或强制理由登记用于高敏字段（例如医疗、财务账号）。
- 前端显示采用动态掩码；导出文件默认加密并设置到期与访问口令的分发机制。

9. 应用与数据库实现模式
- 字段级加密：应用层在写入前加密高敏字段；避免数据库层广泛解密。可选确定性加密以支持等值查询，但须评估泄露风险并仅用于低风险字段。
- 代币化/映射表：将高敏值替换为不可逆代币；必要时以受控服务检索原值。
- 索引与搜索：对敏感字段不建立基于明文的索引。等值查询可用哈希索引（带盐，避免可逆推断）。
- 会话与缓存：禁止在中间缓存中存储明文；使用内存加密与最短TTL。

10. 接口与集成
- 第三方对接：合同与DPA需明确加密要求、密钥责任与审计权；使用互信TLS证书管理与双向TLS。
- 批量文件交换：采用加密容器（如 age/PGP）或 S/MIME；通道与载荷双重加密优先。

11. 终端与移动
- 终端全盘加密（Windows BitLocker、macOS FileVault、移动设备原生加密）；MDM强制策略与远程擦除。
- 禁止在未经授权的终端存储员工数据明文；U盘与可移动介质须强制加密或禁用。

12. 备份与灾难恢复
- 备份与快照必须加密，且密钥独立管理；定期演练解密恢复流程。
- 异地与冷备：遵循同等加密与密钥隔离；确保恢复链路的TLS安全。

13. 监控、审计与度量
- 日志：记录解密调用、数据访问主体、用途、时段、结果；保护日志不可被篡改。
- 度量：加密覆盖率、密钥轮换达标率、异常解密告警率、备份恢复成功率。
- 定期评估：加密方案渗透测试与密码合规评审，更新弱算法清单。

14. 例外管理与事件响应
- 例外须由数据所有者与安全团队联合审批，明确补偿控制与到期时间。
- 密钥泄露或嫌疑：立即轮换与撤销、影响评估、通知流程与取证；必要时执行加密报废策略。

15. 培训与文件化
- 面向HR与IT的加密与数据最小化培训；开发团队掌握安全编程与密钥使用模式。
- 文档：维护加密字段清单、算法与参数标准、密钥RACI、操作流程与应急预案。

16. 合规参考（指导性）
- GDPR 第32条（处理安全）、数据保护原则（最小化、完整性与保密性）。
- 中国个人信息保护法（PIPL）：采取加密等安全措施，严格访问控制与审计。
- ISO/IEC 27001/27002、NIST SP 800-57（密钥管理）、NIST SP 800-52（TLS 配置）等实践框架。

17. 实施检查清单（摘要）
- 明确数据分类与加密清单；确定字段级与存储级加密范围。
- 选定算法与协议（AES-256-GCM/TLS 1.3 等），建立KMS/HSM与信封加密。
- 配置RBAC/ABAC与审批流程；前端掩码与导出加密。
- 备份加密与密钥隔离；日志与审计报表上线。
- 定期轮换密钥与渗透测试；例外与事件响应机制就绪。
- 与第三方/云供应商签署加密与审计条款，验证实施。

本指南旨在在治理层面规定“加什么、谁批、如何管、如何审”，在技术层面规定“用什么算法与工具、如何实施与运维”。实施前应结合组织风险评估、系统架构与法律要求进行细化与验证。

Guidelines for Encrypted Database Backups

1) Purpose and scope
- Ensure backups of databases are encrypted end to end (in transit and at rest) to protect confidentiality and integrity, meet regulatory obligations, and support recoverability.
- Apply to full, differential/incremental, and log/WAL backups; include backup catalogs, configuration exports, and snapshots.

2) Policy requirements
- All database backups must be encrypted using approved algorithms and keys managed in a controlled key management system.
- Encryption must be enabled by default and enforced by technical controls (policy-as-code where possible).
- Backups must be transmitted over encrypted channels.
- Access to backup data and keys must follow least privilege, separation of duties, and dual control for key escrow/recovery.
- Implement immutability/WORM for critical backups and maintain at least one offline/air-gapped copy.
- Verify backup integrity and restoration regularly; treat successful test restores as a control objective.
- Retention, location, and deletion must comply with data classification, legal hold, and data residency requirements.

3) Roles and responsibilities
- Data Owner: Defines classification, retention, and location constraints.
- DBA: Implements backup encryption at the database/tool level; executes restores; validates integrity.
- Backup Administrator: Manages backup infrastructure, repositories, immutability, and monitoring.
- Key Management Owner (KMS/HSM): Manages keys, rotation, access, escrow, and auditing.
- Security/GRC: Defines cryptographic standards; verifies compliance; oversees risk exceptions.
- Internal Audit: Tests controls (encryption, access, restores, logging).

4) Approved cryptography
- Symmetric encryption: AES-256 with AEAD (GCM or CCM) preferred; alternatives: AES-256-CBC plus HMAC-SHA-256/512 if AEAD unavailable.
- Key wrapping: AES-KW (RFC 3394) or AES-GCM; if public key, use RSA-OAEP (≥3072-bit) or ECIES with P-256/P-384.
- Hashing: SHA-256/512; avoid MD5 and SHA-1.
- TLS: v1.2+ (prefer 1.3) with modern cipher suites.
- Use FIPS 140-3 validated crypto modules where required.

5) Key management (NIST SP 800-57 aligned)
- Use centralized KMS/HSM for root and data-encryption keys (DEKs). Prefer customer-managed keys (CMKs).
- Generate keys with KMS/HSM; never hardcode in scripts or store in source control.
- Separate key roles: DBAs and backup admins cannot access key material; key custodians manage keys.
- Rotation: Rotate KEKs annually or on material change; re-wrap DEKs; plan re-encryption of long-lived backups on schedule or upon compromise.
- Escrow and recovery: Define dual-control procedures; consider Shamir Secret Sharing for master key escrow.
- Backup keys securely and test key recovery; loss of keys renders backups unrecoverable.
- Access controls: Enforce least privilege with per-environment key policies; log key usage with key ID, principal, and purpose.
- Crypto-shredding: Define process to destroy keys for data subject deletion or end-of-life, subject to legal holds.

6) Architecture patterns
- Application/database-native encryption of backup artifacts is preferred over storage-only encryption.
- Storage-level encryption (e.g., encrypted disks/buckets) is additive, not a substitute for backup-file encryption.
- For dedup/compression, perform these operations before encryption within the backup application to maintain efficiency.

7) End-to-end workflow
- Data classification and scope: Include only necessary datasets. Exclude test data or anonymize where appropriate.
- Backup creation:
  - Use native DB features or enterprise backup tools that support AEAD and KMS integration.
  - Compress, then encrypt, then write to repository.
  - Embed or store separately a cryptographic signature/HMAC for integrity.
- Transport:
  - Use mTLS or SSH (SFTP) for agent-to-repository traffic; pin server certs where feasible.
- Storage:
  - Store encrypted backups on immutable/WORM-capable repositories; replicate to secondary region/account/tenant.
- Catalogs/metadata:
  - Encrypt the backup catalog, manifests, and any stored credentials; protect with separate keys and access controls.
- Verification:
  - Automatically verify backup integrity (checksums, HMAC, or AEAD tag) post-write and on a scheduled basis.
- Restore testing:
  - Perform periodic test restores to a sterile environment using production keys; validate data and logs/WAL replay.

8) Immutability and ransomware resilience
- Enable WORM/immutability:
  - Object storage: S3 Object Lock (Compliance/Governance), Azure Immutable Blob, GCP Bucket Lock.
  - Backup appliances: Retention lock features.
  - Tape: LTO WORM for offline copies.
- Maintain an offline/air-gapped copy for critical systems.
- Require MFA delete or governance-mode protections for retention settings.
- Scan backups for malware pre- and post-restore; do not rely solely on scanning encrypted data.

9) Access control and logging
- RBAC with least privilege for backup operations; separate roles for backup admin, DBA, and key custodian.
- PAM for privileged sessions; just-in-time elevation where possible.
- Break-glass process with dual approval and time-bound access; log all actions.
- Comprehensive audit logs: who/what/when/where for backup creation, key usage, restore attempts, deletions, and retention changes; forward to SIEM with alerts on anomalies.

10) Retention, residency, and legal holds
- Define retention by data classification and regulation (e.g., 30–90 days operational, 1–7 years regulatory, longer for specific rules).
- Apply legal holds in the backup system; blocks deletion and rotation.
- Enforce data residency: Ensure backup data and keys remain in approved regions; encryption does not waive residency constraints.
- Document cross-border transfers and apply SCCs or equivalent where required.

11) Integrity and authenticity
- Use AEAD (GCM) to provide confidentiality and integrity; additionally sign archives or manifests (Ed25519/ECDSA) where tools support it.
- Maintain and verify cryptographic checksums (SHA-256/512) for each backup segment; store separately from data.
- Validate integrity at backup time and before every restore.

12) Performance considerations
- Use hardware acceleration (AES-NI, ARMv8 Cryptography Extensions).
- Compress before encrypt; deduplicate before encrypt where supported by the backup tool.
- Avoid convergent encryption due to privacy and collision risks.
- Tune concurrency and I/O to offset encryption overhead; size CPU accordingly on agents and repositories.

13) Cloud provider specifics
- AWS:
  - RDS/Aurora: Enable encryption at instance/cluster creation; automated backups and snapshots inherit KMS CMK. To encrypt an unencrypted snapshot, copy with encryption and a CMK. Use AWS Backup with CMK and Vault Lock for immutability.
  - EC2 self-managed DBs: Use agent-based encryption with KMS; store backups in S3 with SSE-KMS and Object Lock.
- Azure:
  - Azure SQL/MI: TDE on by default; backups are encrypted. For CMK, integrate with Azure Key Vault (TDE with CMK). Use Azure Backup vault with immutability.
  - Self-managed: Encrypt with tool; store in Immutable Blob Storage with CMK.
- GCP:
  - Cloud SQL: CMEK-supported instances encrypt backups with CMEK; ensure key rotation and availability. Use Bucket Lock and CMEK for GCS backups of self-managed DBs.

14) Database/tool-specific notes
- Oracle: Use RMAN backup encryption (AES 128/192/256). Modes: Transparent (TDE wallet), Password, or Dual. Protect wallet with HSM/KMS where possible.
- Microsoft SQL Server: Use native backup encryption (AES-256) with certificates or asymmetric keys in master; protect the certificate private key; back it up securely. TDE does not encrypt unencrypted backups unless backup encryption is also enabled.
- PostgreSQL: pg_dump/pg_basebackup lack built-in encryption; encrypt via:
  - pgBackRest (AES-256, key management, compression, delta).
  - WAL-G or barman with KMS/GPG integration.
  - Pipe through OpenSSL or GPG with AEAD and signed manifests.
- MySQL/MariaDB: MySQL Enterprise Backup and Percona XtraBackup support encryption (AES-256) with keyring plugins (file, HashiCorp Vault, KMS). Ensure redo/binlog and keyring backups are coordinated for recoverability.
- MongoDB: Use backup tooling (Ops Manager/Cloud Manager/Atlas) with backup encryption; for file-level snapshots, ensure filesystem/block-device encryption does not replace backup-file encryption; protect keys in KMIP/KMS.
- Backup catalogs: Many enterprise backup suites (e.g., NetBackup, Commvault, Veeam) support per-tenant keys, immutability, and KMS/HSM integration; enable repository encryption and lock credentials.

15) Testing and drills
- Quarterly restore tests per critical system; include point-in-time recovery.
- Validate decryption using production-like keys and roles.
- Document RTO/RPO attainment; capture lessons learned and adjust runbooks.
- Test key rotation impact and expired/disabled key scenarios.

16) Compliance mapping (examples, verify against your obligations)
- GDPR Art. 32: Encryption appropriate to risk; ensure data subject rights and deletion with crypto-shredding when permissible.
- HIPAA: Encryption is addressable but expected; ensure key management, access logging, and secure disposal.
- PCI DSS v4.0: Strong cryptography for PAN at rest (Req 3); key management (Req 3.5/3.6); logging and monitoring (Req 10); backup media protection.
- SEC/FINRA: WORM retention (SEC 17a-4(f)) for broker-dealers; implement immutable backups and supervision.

17) Metrics and monitoring
- Coverage: Percentage of backup jobs with encryption enabled (target 100%).
- Key usage: Backups tied to CMKs with valid rotation status.
- Immutability: Percentage of backups stored on immutable/WORM media.
- Restore success rate and time; integrity check pass rate.
- Unsuccessful/unauthorized restore attempts and deletions (alerts).
- Age and compliance of keys, certificates, and modules (FIPS status).

18) Implementation checklist
- Define policy: Approved algorithms, KMS, roles, retention, regions.
- Inventory databases and backup flows; classify data and set retention.
- Select tooling that supports AEAD, KMS/HSM, immutability, and verification.
- Implement mTLS between agents and repositories; enforce TLS 1.2+.
- Enable encryption for all backup types (full, differential, log/WAL).
- Integrate with KMS/HSM; define key hierarchy and rotation.
- Configure immutable/WORM storage and offline copies.
- Encrypt backup catalogs and protect credentials/secrets.
- Automate integrity verification and periodic test restores.
- Implement RBAC, dual control for key recovery, and break-glass.
- Centralize logs in SIEM; build alerts and dashboards.
- Document runbooks for backup, restore, key recovery, and incident response.
- Conduct tabletop exercises for key compromise and ransomware scenarios.

19) Common pitfalls to avoid
- Relying solely on disk or bucket encryption without encrypting backup files.
- Losing key material due to inadequate escrow/testing.
- Not encrypting backup catalogs or manifests that may expose sensitive metadata or credentials.
- Skipping integrity verification and restore tests.
- Storing keys and backups in the same administrative domain without separation of duties.
- Compressing after encryption (ineffective) or expecting deduplication to work on encrypted blobs.
- Allowing retention/immutability settings to be reduced without multi-party approval and audit.

These guidelines provide a governance-aligned baseline. Adapt to your regulatory scope, threat model, and technology stack, and codify requirements into build/backup pipelines and configuration policies to ensure continuous compliance.