Data at Rest (AES-256) & Data in Transit (TLS 1.3)
The engineering team encrypts all data at rest using AES-256 or equivalent, and all data in transit using TLS 1.3. This applies to every data category in the AI system: training data, evaluation data, feature stores, model artefacts, inference logs, monitoring data, configuration data, and the AISDP documentation itself.
Encryption at rest protects against storage-level access: a compromised cloud account, a misconfigured storage bucket, or an exfiltrated backup yields only encrypted data without the corresponding encryption keys. Encryption in transit protects against network-level interception: even within the VPC, mTLS ensures that inter-service communication is encrypted.
For AI systems processing personal data, encryption is both a cybersecurity control and a GDPR safeguard. The encryption configuration should be documented in Module 9, including the encryption algorithm, the key length, the scope of encryption (which data stores, which communication channels), and any exceptions with their justification. Cloud-native encryption services (AWS KMS, Azure Key Vault, Google Cloud KMS) provide managed encryption with HSM-backed key storage.
Key outputs
- AES-256 encryption at rest for all data stores
- TLS 1.3 encryption in transit for all communication channels
- Encryption scope documentation with any exceptions justified
- Module 9 AISDP documentation
Key Management
Encryption is only as strong as the key management that underpins it. The security team manages encryption keys through a dedicated key management service (AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault) with rotation policies, access logging, and separation of duties.
Key rotation ensures that keys are periodically replaced, limiting the exposure if a key is compromised. The rotation schedule should be documented: annual rotation for master keys, more frequent rotation for data encryption keys if supported by the KMS. Separation of duties ensures that no single individual can both access the encrypted data and manage the encryption keys. Access to key management operations is restricted to named security personnel and logged.
For the ten-year retention period, key management must account for credential survivability. Keys used to encrypt archived data must remain available and functional for the full retention period. If a key is rotated, the previous key must be retained (in a disabled state, available only for decryption) until all data encrypted with it has been re-encrypted or has passed its retention expiry. The key management policy and configuration are documented in Module 9.
Key outputs
- Dedicated KMS with documented rotation policies
- Separation of duties for key management operations
- Credential survivability planning for the ten-year retention period
- Module 9 AISDP documentation