These docs are for v2. Click to read the latest docs for v3.

CRM data security

Handling personal and sensitive data is a serious responsibility. As a centralized hub for individual-related records, the CRM plugin is designed with security at its core, ensuring user privacy, reducing the risk of misuse, and aligning with global data protection standards.

Why does this matter?

Every regulation (from GDPR to LGPD) shares the same principle: personal data should only be used for the purpose the user consented. The CRM plugin integrates with Midaz to support both transactional and non-transactional flows, and must ensure that sensitive data used in these processes is properly safeguarded.

Although Lerian doesn't offer cybersecurity services, we follow strict information security practices in all software we ship.


Security responsibilities


As an on-premise technology provider, Lerian does not oversee or enforce the cybersecurity policies of our clients. We respect the trust-based relationship each institution has with its end users and operate under the assumption that they follow the LGPD and any other relevant regional or industry-specific data protection regulations.

That said, Lerian is committed to delivering technology that adheres to strong, market-aligned security practices. This ensures that sensitive CRM data is protected as follows:

In transit

All data exchanged with the CRM is secured with TLS encryption over HTTPS. From the moment a request hits the system, whether it’s creating or updating a holder or account, sensitive fields are encrypted before being written to the database.

At rest

Because the CRM runs on-premise, encrypting disks or volumes is the client’s responsibility. Still, we strongly recommend implementing this measure to add a robust layer of protection.


How we protect data


The CRM plugin employs various protection methods based on the nature of the data and its intended use.

  • Encryption is used when the system might need to access the original value, such as names or contact information.
  • Hashing is used when values don’t need to be shown again but must remain verifiable, like identifiers used for filtering or lookup.
🚧

Attention

Sensitive data is protected as soon as it reaches the CRM. It’s never stored or processed in raw form.


Encryption and hashing strategies

To safeguard sensitive information while supporting application functionality, the CRM uses a combination of cryptographic techniques aligned with industry best practices.

Encryption

For fields that need to be retrieved or shown, such as personal names or emails, the CRM encrypts each value using strong, symmetric encryption. This ensures that even if database contents are accessed directly, original values remain unreadable without proper authorization.

The encryption process also includes a random component to guarantee that identical values never produce the same encrypted output.

Hashing

Certain fields are hashed to allow secure filtering without exposing the original value. These hashed values are stored in a separate internal structure that supports fast, secure lookups.

📘

Note

In some cases, fields may be hashed solely to meet internal database constraints, even if they aren’t searchable.


Key management

The CRM uses encryption and hashing keys that must be securely generated, stored, and managed by the deployment team. Keys should follow strong cryptographic standards and never be hardcoded or exposed in source code or version control.

❗️

Important

Protect your keys using a dedicated secret manager or secure storage solution. If a key is compromised, you must rotate it and re-encrypt or re-hash affected data.


Protected fields

Below is a list of fields that undergo protection processes within the CRM. You don’t need to concern yourself with the specifics of how this works; just ensure that you avoid entering sensitive data in areas not included here.

❗️

Important

Never store sensitive information in the metadata object.


Holder

  • name
  • document
  • contact.primaryEmail
  • contact.secondaryEmail
  • contact.mobilePhone
  • contact.otherPhone
  • naturalPerson.motherName
  • naturalPerson.fatherName
  • legalPerson.representative.name
  • legalPerson.representative.document
  • legalPerson.representative.email

Account

  • document
  • bankingDetails.account
  • bankingDetails.iban

Best practices & recommendations


Data encryption in the CRM plugin is designed to add a strong security layer, ensuring that even if the database is compromised, sensitive data remains inaccessible in its original form.

Decryption is only possible via a valid key or through authenticated and authorized service calls. That’s why key security is critical: if a key is leaked, the application cannot protect your data on its own.

To keep your environment safe, we strongly recommend:

  • Avoid exposing CRM services directly on edge layers like gateways or frontend apps.
  • Never store sensitive data in metadata fields, they are not encrypted.
  • Enforce governance for managing access to the production environment and related tooling.
  • Use secure key managers with strict access controls to safeguard your secrets.
  • Encrypt disks or volumes to protect data at rest.

If a key is compromised or needs to be rotated, it's your responsibility to generate a new one and re-encrypt affected data using the CRM’s available services.

🚧

Attention

Data security is a shared responsibility. The CRM plugin gives you the building blocks—make sure your deployment uses them wisely.