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

---

We apply different protection methods depending on the nature of the data and how it’s used.

• Encryption is used when the system might need to access the original value, like names, emails, or phone numbers.
• Hashing is used when values don’t need to be shown again, but must be securely verified, like document IDs or account numbers.

🚧

Attention

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

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.

🚧

Remember

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