Data storage encryption – Part 3: key management, LGPD/GDPR and action plan

Part 3 of 3 – Governance and implementation

In the previous parts of this series, we covered the fundamentals of encryption and how to use symmetric and asymmetric cryptography in data storage. Now we focus on what really underpins all of this: key management, alignment with LGPD/GDPR, common mistakes, and a practical action plan.

1. Key management: the heart of encryption

Encryption without proper key management is, in practice, a false sense of security. If the key is exposed, all your efforts to encrypt data lose their value.

Some essential key management principles:

1.1 Never store the key alongside the data

A common mistake is storing the encryption key on the same server (or in the same folder) as the encrypted data. For example:

• keys in unprotected configuration files;
• secrets hardcoded in source code;
• environment variables exposed to any process on the server.

If an attacker compromises the server, they gain access to both encrypted data and keys, defeating the protection. Instead, use:

• secrets vaults (Secrets Manager, Parameter Store, Vault, etc.);
• KMS (Key Management Service) with access control and audit logs;
• HSMs (Hardware Security Modules) when the level of criticality requires it.

1.2 Regular key rotation

Rotating keys reduces the impact of a potential leak. Good practices include:

• defining a clear rotation policy (for example every 6 or 12 months);
• automating rotation as much as possible to avoid human error;
• having a plan to re-encrypt historical data when necessary.

1.3 Segregation of duties

Not everyone who administers the database needs access to the keys. And not every developer should be able to decrypt production data.

A good strategy is to separate roles such as:

• infrastructure (server and network operations);
• security and key management;
• development and support.

This segregation reduces the risk of insider abuse and supports more mature governance practices.

1.4 Monitoring and auditing

Logging and analysis are crucial. Key points to monitor:

• who requested use of a given key;
• when the request occurred and from which system/IP;
• in which context (production, staging, testing).

In an incident investigation, these records help to reconstruct what happened and make decisions quickly.

2. Encryption aligned with LGPD, GDPR and industry standards

Almost every organisation handles personal data to some extent. Laws such as LGPD in Brazil and GDPR in the European Union require companies to adopt technical and organisational measures to protect such information.

Encryption appears in these regulations as one of the key recommended measures. Some concrete benefits:

• Reduced regulatory risk: strongly encrypted personal data, with well-protected keys, tends to reduce the legal impact of incidents;
• Stronger position in audits: presenting encryption policies, key management processes and monitoring helps demonstrate due diligence;
• Alignment with standards such as ISO 27001, PCI-DSS and others, which often require or recommend encryption at rest.

Importantly, encryption alone does not guarantee compliance, but it is an essential component of a structured privacy and security programme.

3. Common mistakes when implementing storage encryption

Some pitfalls appear in many projects. Among the most common:

1. Using obsolete or weak algorithms
   Legacy algorithms such as DES or 3DES, or insufficient key sizes, may not provide adequate protection today. Prefer modern standards that are widely reviewed by the security community.
2. “Rolling your own” crypto
   Home-grown cryptography is a frequent source of vulnerabilities. Use well-established, actively maintained libraries instead.
3. Forgetting to encrypt backups and logs
   Many organisations protect only the main production environment, but leave database dumps, old backups and sensitive logs in cleartext.
4. Storing keys in cleartext in code or repositories
   Commits exposing keys, passwords and tokens are one of the most common causes of incidents. Use secrets vaults and proper credential management practices.
5. Ignoring performance impact
   Cryptography has a processing cost. You need to choose carefully what will be encrypted at disk, database, application or object level, and test the impact.
6. Failing to test recovery scenarios
   Encryption is of little use if, during an incident, you cannot restore access or recover data. Regularly test disaster and key recovery scenarios.

4. Practical checklist: where to start (or improve) your strategy

To turn concepts into action, use this checklist as a guide:

1. Map sensitive data
   • Which types of personal, financial or strategic data do you store?
   • Where are they located (databases, files, backups, cloud, endpoints)?
2. Classify assets
   • Group data by criticality (high, medium, low);
   • identify what needs to be protected first.
3. Enable disk/volume encryption where available
   • turn on native encryption for cloud volumes;
   • use LUKS, BitLocker or equivalent solutions on servers and workstations.
4. Evaluate TDE in your databases
   • check whether your DBMS offers transparent data encryption;
   • understand the impact on performance, backup and restore.
5. Define sensitive fields for application-level encryption
   • personal identifiers, credentials, trade secrets;
   • design how to encrypt/decrypt and how to handle queries and reporting.
6. Implement a key management service
   • choose a reliable KMS or secrets vault;
   • define who can access each key and in which environments.
7. Combine symmetric and asymmetric encryption
   • use symmetric algorithms to encrypt the data itself;
   • use asymmetric infrastructure to protect data keys (envelope encryption).
8. Document policies and procedures
   • how keys are created, rotated and revoked;
   • who is responsible for each step of the process.
9. Monitor and audit
   • log key usage and access to encrypted data;
   • regularly review suspicious events.
10. Train your teams
    • developers, DBAs and infrastructure teams should understand basic cryptography concepts;
    • reinforce good practices to avoid classic mistakes (such as hardcoded keys).

5. Conclusion: encryption as a business strategy

Encryption of data at rest is no longer a minor technical detail; it is part of your business strategy. Organisations that take it seriously:

• reduce the likelihood and impact of data breaches;
• protect their reputation and customer/partner trust;
• are better prepared to comply with LGPD, GDPR and industry standards;
• respond to incidents with more clarity, speed and transparency.

By combining symmetric encryption for large data volumes with asymmetric cryptography and solid key management, you build a robust defence layer aligned with market best practices.

If your organisation still does not have a clear data-at-rest encryption strategy, the best time to start is now. Take the first steps with the checklist above, evolve your architecture and integrate encryption into your data governance and privacy processes.

Bonus tip: if you want to go further and structure personal data governance with transparency for data subjects and compliance with LGPD/GDPR, explore solutions such as Unova to centralise consents, records and evidence of compliance.