In conversations with potential partners, we occasionally hear that the solutions of different CRM integration developers are “more or less the same.” After all, most solutions display a customer card, allow you to search and log data, and help users work faster.
However, there are significant differences in what users actually see and in how integrations are technically designed. But it is precisely the less visible choices, such as how data is processed and how security is implemented, that are at least as important in today’s world and play a major role in determining the risks you face.
Our vision is that CRM integrations should operate on the basis of real time data, without storage or synchronization outside the CRM. From this vision, we at Red Cactus build a secure, generic standard and write about topics such as data processing and security, in the hope that other CRM integration developers will also follow this standard.
In previous articles, we already discussed how to recognize GDPR compliant CRM integrations. In this article, we introduce a top 6 security checklist for CRM integrations, focused on technical and infrastructural security. This checklist aligns with the standard we apply at Red Cactus when designing and developing CRM integrations.
The way users log in to a CRM integration forms the foundation of its security. A secure integration preferably supports single sign on via the organization’s existing identity provider, so that central security policies automatically apply. It should also be possible to define, at organization level, which identity providers are allowed. Unused identity providers, such as Microsoft, Google, or others, must be able to be disabled. In addition, an integration should automatically block users after a predefined number of failed login attempts.
When single sign on is not available and an integration uses a username and password, multifactor authentication must at least be enforceable. Security should never be an individual user choice. It must be enforceable at organization level.
If a CRM integration cannot meet these principles, it is reasonable to question whether this is a solution you want to continue with. In that case, at the very least verify that unauthorized access to an account does not immediately lead to access to customer data, for example because data is cached or synchronized within the integration. From a privacy and GDPR perspective, it is essential that a login incident does not automatically result in a data breach.
A CRM integration should always respect the roles and permissions of the CRM. Users should never be able to view or modify more data through the integration than is allowed within the CRM itself. The CRM authorization structure must be leading. To enforce this correctly, a CRM integration must operate in the context of the individual user. This means that data and actions are retrieved on behalf of the logged in user and can be traced back to a specific account. This is essential for control, auditing, and the correct application of access rights.
It is also important that authentication towards the CRM is based on individual users rather than a single central technical account. When an integration connects to the CRM using a central account, the link between user and data is lost. In practice, this means that everyone can access the same information through the integration, regardless of role or function.
The use of central accounts introduces additional risks, such as shared passwords, manual access management, and limited traceability. There is also the risk that access remains active when employees leave the organization. Combined with access to customer data, this increases the likelihood of unauthorized access and makes incidents harder to investigate.
If a CRM integration cannot support these roles and user context, it is important to critically assess the consequences. When CRM data is made available exclusively in real time and is not stored centrally, the impact of such limitations remains significantly more limited than with integrations that cache or synchronize data.
CRM integrations are often offered as cloud solutions, but the underlying architecture differs greatly between developers. Our vision is that data should be strictly segregated, even if this comes at a higher cost. In practice, however, we regularly see solutions with shared infrastructures in which data from multiple customers is processed within the same environment. Especially when CRM integrations are built on technologies that use data caching or synchronization, this leads to significantly higher risk.
When data from multiple customers is processed within a shared infrastructure, it is important to consider the impact of an incident. With integrations that cache or synchronize CRM data, a security breach or misconfiguration can result in data from multiple organizations becoming accessible at once. The impact of such an incident is therefore much greater than with integrations that do not store data.
For this reason, it is important to look beyond preventive security measures alone. Check how a CRM integration is set up in terms of continuity and recovery. Is the infrastructure redundant? How are backups arranged? Are there offsite backups, and is it clear what the expected recovery time is in the event of an outage or security incident?
A crucial question is whether a provider can fully recover after a major incident at all, and within what timeframe. This says a lot about how the infrastructure is designed and whether aspects such as redundancy, failover, and recovery procedures are actually in place.
Security is not a one time effort. CRM integrations continuously change due to new functionality, updates, and dependencies. That is why it is important for the security of an integration to be periodically tested by independent specialists.
Check whether a CRM integration is regularly subjected to independent penetration tests and whether the results are acted upon. A one off test in the past is insufficient. Recurring testing is essential to identify new vulnerabilities in a timely manner.
Transparency also matters. Can a provider demonstrate that these tests take place and at what level they are performed? This says a lot about how seriously security is taken within the organization.
If a CRM integration does not undergo periodic, independent security testing or cannot provide insight into this, it is important to critically assess the risk you take when processing customer data through that integration.
A CRM integration that has access to customer data must have adequate logging and monitoring. It should be clear who accessed the integration and when, which actions were performed, and which data was consulted. Logging is not only important for security, but also for manageability and compliance. In the event of an incident, it must quickly become clear what happened and what the impact was. Without proper logging, this is virtually impossible.
Monitoring is also essential to detect abnormal behavior in a timely manner, such as unusual login attempts, increased error rates, or unexpected spikes in data traffic. Early detection can significantly limit the impact of an incident.
If a CRM integrator cannot clearly explain which logs are recorded, how long they are retained, and how monitoring is set up, it is wise to critically assess the level of control you have over the processing of customer data.
A CRM integration depends on underlying software, frameworks, and infrastructure that are constantly evolving. Vulnerabilities often arise because security patches are not applied or are applied too late.
Therefore, check whether security patches are applied structurally and whether this is demonstrable. A provider’s release policy says a lot about how security is handled. Is there a fixed release cycle? Are updates controlled and rolled out consistently?
A mature CRM integration can deploy security updates without breaking existing connections or customer environments. When updates lead to functional regressions or require manual changes by customers, patching is often postponed in practice, increasing risk.
At first glance, CRM integrations may seem similar, but the choices around security, data processing, and infrastructure make a major difference. Precisely because CRM integrations deeply affect the processing of customer data, they deserve the same critical evaluation as the CRM itself.
What we still see too often is indifference. The idea that the risks of an incident lie with the CRM integrator, while in practice the impact is almost always broader. Responsibility cannot simply be shifted, and even if that seems contractually possible, the question remains whether an integrator can financially bear the consequences of a major incident or is adequately insured for it.
A security incident rarely affects just one party. It affects your organization, your customers, and often the customers of your customers. That is exactly why it is essential to be critical in advance and to consciously choose a CRM integration that demonstrably takes security seriously. If you use a CRM integration other than that of Red Cactus, this checklist is a good starting point to determine which risks you accept and where your boundaries lie.