{"id":7250,"date":"2026-05-26T17:11:19","date_gmt":"2026-05-26T16:11:19","guid":{"rendered":"https:\/\/liminal.pt\/martech-magazine\/?p=7250"},"modified":"2026-05-26T17:11:28","modified_gmt":"2026-05-26T16:11:28","slug":"10-gdpr-and-security-requirements-for-crm-and-automation-in-2026","status":"publish","type":"post","link":"https:\/\/liminal.pt\/martech-magazine\/en\/10-gdpr-and-security-requirements-for-crm-and-automation-in-2026\/","title":{"rendered":"10 GDPR and security requirements for CRM and automation in 2026"},"content":{"rendered":"\n

Compare features, integrations and price. In 2026, the decision must include one central question: does the platform allow personal data to be processed securely, traceably and in compliance with GDPR?<\/p>\n\n\n\n

This question is critical because CRM and marketing automation concentrate some of the most sensitive data in the commercial operation: contacts, job titles, emails, phone numbers, interaction history, communication preferences, acquisition sources, commercial interests, lead scoring scores, meeting notes, proposals and, in some cases, contractual or financial data. Even in a B2B context, much of this data remains personal data when it identifies or makes a natural person identifiable.<\/p>\n\n\n\n

GDPR does not prohibit marketing, sales or automation. It also does not prevent companies from using CRM, scoring, segmentation or commercial workflows. What it requires is that the processing of personal data has a legal basis, clear purposes, adequate security, transparency, respect for data subjects\u2019 rights and documented accountability. The regulation itself establishes principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality and accountability.<\/p>\n\n\n\n

In practice, this means that a B2B SME should not choose a CRM only because it is easy to use or because it has good automations. It must assess whether the platform allows consent management, access control, data export, record deletion, processing documentation, response to data breaches and evidence of compliance.<\/p>\n\n\n\n

At Liminal, we help companies design CRM and automation implementations that combine commercial efficiency, data quality and governance. The goal is not to turn GDPR into an operational blocker. It is to create processes that allow companies to sell, communicate and automate with confidence.<\/p>\n\n\n\n

This guide presents the 10 essential GDPR and security requirements that should be assessed before implementing or reviewing a CRM and marketing automation platform.<\/p>\n\n\n\n

RGPD for Marketeers – A Checklist Elementar<\/a><\/p>\n\n\n\n

Quick guide: 10 GDPR and security requirements for B2B CRM<\/h1>\n\n\n\n
    \n
  1. Legal basis and consent management
    Allows the company to record why it can process data and communicate with each contact.<\/li>\n\n\n\n
  2. Data encryption
    Protects personal data in transit and at rest, reducing risk in the event of unauthorised access.<\/li>\n\n\n\n
  3. Access control and permissions
    Ensures that each user only accesses the data needed for their role.<\/li>\n\n\n\n
  4. Data portability
    Allows the company to respond to data subject requests with structured and readable exports.<\/li>\n\n\n\n
  5. Right to erasure and data retention
    Allows data to be deleted when applicable and retention periods to be defined.<\/li>\n\n\n\n
  6. Data Protection Impact Assessment
    Helps assess risks when there are more intrusive processing activities, such as profiling or scoring.<\/li>\n\n\n\n
  7. Records of processing activities
    Documents what data is processed, for what purpose, by whom and for how long.<\/li>\n\n\n\n
  8. Notification and management of data breaches
    Allows incidents to be detected, response to be documented and legal deadlines to be met.<\/li>\n\n\n\n
  9. Data location and international transfers
    Assesses where data is hosted and what mechanisms exist when data leaves the European Economic Area.<\/li>\n\n\n\n
  10. Governance of integrations and processors
    Ensures that the website, ERP, email tools, analytics, advertising and automation follow the same data protection model.<\/li>\n<\/ol>\n\n\n\n

    How we assessed these requirements<\/h1>\n\n\n\n

    These criteria were selected based on three dimensions: GDPR legal obligations, common operational risks in CRM and automation, and real impact on marketing and sales management.<\/p>\n\n\n\n

    The first dimension is regulatory compliance. GDPR defines data subject rights, obligations for controllers, rules for security of processing, notification of breaches, processing records and impact assessments. These requirements are not secondary. They must be reflected in the way the CRM collects, stores, segments, exports and deletes data.<\/p>\n\n\n\n

    The second dimension is practical applicability. A requirement is only useful if it can be verified during a demo, a trial period or a configuration audit. It is not enough for the vendor to say that it \u201ccomplies with GDPR\u201d. It is necessary to understand how consent is recorded, how a contact is exported, how a record is deleted, how access is limited by profile and how a change is audited.<\/p>\n\n\n\n

    The third dimension is business impact. A poor GDPR configuration does not only create legal risk. It creates commercial risk. Databases without clear consent cannot be activated with confidence. Poorly recorded contact sources prevent attribution. Duplicates and outdated data reduce campaign effectiveness. Excessively open permissions increase the risk of data leaks. Poorly governed integrations circulate data without control.<\/p>\n\n\n\n

    For this reason, the following 10 requirements should be seen as a decision checklist for CEOs, CMOs, sales directors and marketing operations leaders.<\/p>\n\n\n\n

    1. Legal basis and consent management<\/h1>\n\n\n\n

    Consent management is one of the most visible aspects of GDPR, but it should not be confused with the entirety of compliance. Not all personal data processing depends on consent. In a B2B context, there may be other legal bases, such as contract performance or legitimate interest, depending on the purpose and context. Even so, when consent is used, it must be specific, informed, freely given and demonstrable.<\/p>\n\n\n\n

    In a CRM and automation platform, the company must be able to answer simple questions: why is this contact in the database? What communications did they authorise? When did they give authorisation? Through which form? Can they easily withdraw consent? Does the system prevent communications that do not respect the recorded preferences?<\/p>\n\n\n\n

    Consent management must be granular. Authorising a newsletter is not the same as accepting direct commercial contact. Taking part in a webinar should not mean automatic consent for all future campaigns. The CRM must allow purposes to be separated, such as institutional communications, educational content, event invitations, commercial campaigns, telephone contact or customer related communications.<\/p>\n\n\n\n

    Features to verify:<\/p>\n\n\n\n

      \n
    1. Specific fields for legal basis and processing purpose.<\/li>\n\n\n\n
    2. Record of the date, time, source and consent version.<\/li>\n\n\n\n
    3. Forms with separate options by purpose.<\/li>\n\n\n\n
    4. Preference centre for updating choices.<\/li>\n\n\n\n
    5. Workflows that prevent communications without an appropriate legal basis.<\/li>\n\n\n\n
    6. History of changes to the contact\u2019s preferences.<\/li>\n<\/ol>\n\n\n\n

      This requirement is important because it protects the company in the event of a complaint and improves database quality. Contacts with clear permissions tend to generate more reliable campaigns. Imported contacts without source, without consent or without documented legal basis create risk and reduce operational trust.<\/p>\n\n\n\n

      The common mistake is to create a generic field called \u201cGDPR accepted\u201d and consider the issue solved. That field is rarely enough. What must be documented is the purpose, legal basis, source, moment and associated proof.<\/p>\n\n\n\n

      2. Data encryption<\/h1>\n\n\n
      \n
      \"\"<\/figure>\n<\/div>\n\n\n

      Encryption is an essential technical measure to reduce the risk of exposure of personal data. Article 32 of GDPR refers to the need for technical and organisational measures appropriate to the risk, including, where appropriate, pseudonymisation and encryption of personal data.<\/p>\n\n\n\n

      In a CRM context, there are two dimensions to assess: encryption in transit and encryption at rest. The first protects data when it circulates between users, browsers, applications, APIs and servers. The second protects data stored in databases, files, backups and cloud infrastructure.<\/p>\n\n\n\n

      The company must confirm whether the platform uses HTTPS, updated TLS, encryption of stored data and robust key management practices. It must also understand whether attachments, exports, backups and logs are protected. Many failures happen outside the main CRM database, for example in files exported to spreadsheets, unsecured integrations or poorly configured backups.<\/p>\n\n\n\n

      Features to verify:<\/p>\n\n\n\n

        \n
      1. Mandatory HTTPS across the entire application.<\/li>\n\n\n\n
      2. Encryption of data at rest.<\/li>\n\n\n\n
      3. Encryption of backups.<\/li>\n\n\n\n
      4. Secure key management.<\/li>\n\n\n\n
      5. Protection of attachments and documents.<\/li>\n\n\n\n
      6. APIs with secure authentication.<\/li>\n\n\n\n
      7. Credential expiration and rotation policies.<\/li>\n<\/ol>\n\n\n\n

        Encryption does not eliminate all risks, but it significantly reduces the impact of unauthorised access. If an incident occurs, encrypted data is harder to exploit. It also demonstrates diligence in applying measures appropriate to the risk.<\/p>\n\n\n\n

        The common mistake is to assume that \u201cbeing in the cloud\u201d means being secure. Cloud is not an automatic guarantee of protection. Security depends on the vendor\u2019s architecture, the platform configuration, internal access, integrations and the company\u2019s own practices.<\/p>\n\n\n\n

        3. Access control and permissions<\/h1>\n\n\n\n

        Not everyone in the company needs to access all data. The principle of minimisation also applies to internal access. Each user should only have access to the data needed to perform their role.<\/p>\n\n\n\n

        In a CRM, this is particularly relevant because the platform brings together information from marketing, sales, support and management. A sales representative may need to see their opportunities and contacts, but not necessarily every contact in the organisation. A marketing team may need to segment campaigns, but not access sensitive commercial information. An external user or consultant may need temporary, limited and auditable access.<\/p>\n\n\n\n

        Access control must be granular. It must allow permissions to be configured by team, role, property, object, pipeline, region, owner or record type. It must also allow restrictions on exports, bulk editing, data deletion and access to sensitive reports.<\/p>\n\n\n\n

        Features to verify:<\/p>\n\n\n\n

          \n
        1. User profiles by role.<\/li>\n\n\n\n
        2. Teams and access hierarchies.<\/li>\n\n\n\n
        3. Permissions by object, field and pipeline.<\/li>\n\n\n\n
        4. Restrictions on data export.<\/li>\n\n\n\n
        5. Multifactor authentication.<\/li>\n\n\n\n
        6. Access and change logs.<\/li>\n\n\n\n
        7. Periodic review of active users.<\/li>\n<\/ol>\n\n\n\n

          This requirement reduces the risk of internal leaks, human error and unauthorised access. It also facilitates audits, because it allows the company to demonstrate that it applies control proportional to the risk.<\/p>\n\n\n\n

          The common mistake is to give administrator permissions to too many people. This speeds up implementation in the short term, but creates high risk. Another frequent mistake is forgetting old accounts belonging to employees who changed role or left the company.<\/p>\n\n\n\n

          4. Data portability<\/h1>\n\n\n\n

          The right to portability allows the data subject to receive their personal data in a structured, commonly used and machine readable format, and to transmit it to another controller when applicable. The CNPD describes this right as the possibility of receiving personal data in this type of format and, when technically possible, transmitting it directly between controllers.<\/p>\n\n\n\n

          In a CRM, this means that the company must be able to export the data of a specific person in a complete and understandable way. Exporting only name and email is not enough. Depending on the case, it may be necessary to include contact details, preferences, consents, interaction history, acquisition sources, data provided by the data subject and other relevant fields.<\/p>\n\n\n\n

          Features to verify:<\/p>\n\n\n\n

            \n
          1. Export by individual contact.<\/li>\n\n\n\n
          2. Export in formats such as CSV, JSON or XML.<\/li>\n\n\n\n
          3. Inclusion of relevant metadata, such as creation date and source.<\/li>\n\n\n\n
          4. Inclusion of consents and preferences.<\/li>\n\n\n\n
          5. Ability to export interaction history.<\/li>\n\n\n\n
          6. Documented process for validating the requester\u2019s identity.<\/li>\n<\/ol>\n\n\n\n

            Portability is important because it forces the company to know where the data is and how to deliver it. It is also a test of CRM architecture maturity. If data is spread across several platforms without a clear connection, responding to a portability request becomes slow and risky.<\/p>\n\n\n\n

            The common mistake is to think that exporting a complete contact list solves the request. Portability concerns the data of the data subject who made the request. The export must be precise, limited and secure.<\/p>\n\n\n\n

            5. Right to erasure and data retention<\/h1>\n\n\n
            \n
            \"\"<\/figure>\n<\/div>\n\n\n

            The right to erasure, also known as the right to be forgotten, allows the data subject to request the deletion of their data in certain circumstances. The CNPD explains that this right applies, for example, when the data is no longer necessary for the purpose that justified its collection, when consent has been withdrawn and there is no other legal basis, or when there is an objection to processing without overriding legitimate interests.<\/p>\n\n\n\n

            In the CRM, this requirement demands more than a delete button. The company must distinguish between deletion, anonymisation, marketing suppression, deactivation and mandatory retention. There are cases where certain data may have to be retained due to legal, tax or contractual obligations. In other cases, it must be deleted or anonymised.<\/p>\n\n\n\n

            Features to verify:<\/p>\n\n\n\n

              \n
            1. Permanent deletion of contacts when applicable.<\/li>\n\n\n\n
            2. Anonymisation of data when total deletion is not appropriate.<\/li>\n\n\n\n
            3. Suppression lists to prevent new communications.<\/li>\n\n\n\n
            4. Retention policies by data type.<\/li>\n\n\n\n
            5. Workflows for reviewing inactive contacts.<\/li>\n\n\n\n
            6. Propagation of requests to integrated systems.<\/li>\n\n\n\n
            7. Minimum record of request fulfilment.<\/li>\n<\/ol>\n\n\n\n

              This requirement is essential because old databases, without a current purpose, increase risk and reduce quality. Obsolete data harms segmentation, reporting and automations. In addition, keeping data indefinitely without necessity goes against the principle of storage limitation.<\/p>\n\n\n\n

              The common mistake is to delete only in the main CRM and forget connected tools, such as email marketing, event platforms, spreadsheets, ERP integrations, advertising tools or operational backups.<\/p>\n\n\n\n

              6. Data Protection Impact Assessment<\/h1>\n\n\n\n

              A Data Protection Impact Assessment, known as DPIA, is required when a type of processing is likely to result in a high risk to the rights and freedoms of individuals. The European Data Protection Board maintains guidelines on DPIA and high risk processing, which are relevant for assessing when an organisation should carry out this analysis.<\/p>\n\n\n\n

              In CRM and automation, a DPIA may be necessary in scenarios such as intensive profiling, automated scoring, advanced behavioural segmentation, data enrichment from multiple sources, large scale processing or automated decisions with significant impact.<\/p>\n\n\n\n

              A DPIA should not be seen as a bureaucratic document. It should function as a structured analysis of what will be done, why, with what data, with what risks and with what mitigation measures.<\/p>\n\n\n\n

              Features to verify:<\/p>\n\n\n\n

                \n
              1. Inventory of data used in automations and scoring.<\/li>\n\n\n\n
              2. Mapping of flows between CRM, website, ERP and external tools.<\/li>\n\n\n\n
              3. Identification of processing activities involving profiling.<\/li>\n\n\n\n
              4. Documentation of the purposes of each automation.<\/li>\n\n\n\n
              5. Record of mitigation measures.<\/li>\n\n\n\n
              6. Review before launching new high risk workflows.<\/li>\n<\/ol>\n\n\n\n

                A DPIA helps avoid projects that are only corrected after implementation. In marketing automation, this is particularly relevant because it is easy to create flows that seem efficient, but use excessive data, unclear purposes or opaque decision logic.<\/p>\n\n\n\n

                The common mistake is to treat lead scoring as a simple commercial feature. In many cases it is only internal prioritisation. But when it involves significant profiling, multiple data sources or relevant effects for data subjects, it must be assessed more carefully.<\/p>\n\n\n\n

                7. Records of processing activities<\/h1>\n\n\n\n

                Article 30 of GDPR requires controllers and processors to maintain records of processing activities under certain conditions. Even when an SME is not automatically required in every scenario, any company that uses CRM and automation on a regular basis should keep organised documentation about the processing activities it carries out.<\/p>\n\n\n\n

                In practice, records of processing activities answer fundamental questions: what data is processed? For what purpose? With what legal basis? Who has access? For how long is it retained? Which vendors are involved? Are there international transfers? What security measures exist?<\/p>\n\n\n\n

                Features to verify:<\/p>\n\n\n\n

                  \n
                1. Data inventory by module and purpose.<\/li>\n\n\n\n
                2. Documentation of legal bases.<\/li>\n\n\n\n
                3. Identification of categories of data subjects and data.<\/li>\n\n\n\n
                4. Identification of processors.<\/li>\n\n\n\n
                5. Retention periods.<\/li>\n\n\n\n
                6. Record of integrations and data flows.<\/li>\n\n\n\n
                7. Export for audits.<\/li>\n<\/ol>\n\n\n\n

                  This requirement is important because it turns compliance into management. When the company understands its processing activities, it can respond better to requests, audits, incidents and internal changes.<\/p>\n\n\n\n

                  The common mistake is to keep this record in a static document, created once and never updated. Whenever there is a new integration, new campaign, new form, new automation or new vendor, the record may need to be reviewed.<\/p>\n\n\n\n

                  8. Notification and management of data breaches<\/h1>\n\n\n\n

                  A personal data breach is not only a cyberattack. It may include sending data to the wrong recipient, losing a device, unauthorised access, unauthorised export, an integration error or accidental exposure of information.<\/p>\n\n\n\n

                  The CNPD indicates that when a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, it must be notified within 72 hours after the controller becomes aware of it. The EDPB also reinforces that notification must be made without undue delay and, when required, within that deadline.<\/p>\n\n\n\n

                  Features to verify:<\/p>\n\n\n\n

                    \n
                  1. Alerts on suspicious access.<\/li>\n\n\n\n
                  2. Alerts on mass exports.<\/li>\n\n\n\n
                  3. Change and access logs.<\/li>\n\n\n\n
                  4. Chronological incident record.<\/li>\n\n\n\n
                  5. Internal escalation procedure.<\/li>\n\n\n\n
                  6. Rapid identification of affected data.<\/li>\n\n\n\n
                  7. Communication and notification templates.<\/li>\n<\/ol>\n\n\n\n

                    This requirement is critical because the 72 hour deadline is short. Without logs, alerts and defined processes, the company loses time trying to understand what happened, who was affected and what measures it took.<\/p>\n\n\n\n

                    The common mistake is having technology, but no procedure. A CRM may have logs, but if no one monitors them, if there is no person responsible for incidents and if there is no response process, the functionality does not resolve the risk.<\/p>\n\n\n\n

                    9. Data location and international transfers<\/h1>\n\n\n\n

                    Data location remains a relevant topic for CRM and automation, especially because many global platforms use infrastructure, processors and support teams outside the European Union or the European Economic Area.<\/p>\n\n\n\n

                    European rules apply to the European Economic Area, and when personal data is transferred outside this area, appropriate safeguards must exist to ensure that protection follows the data. The European Commission explains that international transfers require specific mechanisms, such as adequacy decisions or other safeguards provided for in GDPR.<\/p>\n\n\n\n

                    Choosing servers in the European Union may simplify part of the analysis, but it does not solve everything. It is necessary to verify where primary data, backups, logs, support tools, processors, AI services, email platforms and integrations are located.<\/p>\n\n\n\n

                    Features to verify:<\/p>\n\n\n\n

                      \n
                    1. Hosting option in the European Union or European Economic Area.<\/li>\n\n\n\n
                    2. List of processors and their locations.<\/li>\n\n\n\n
                    3. Information about international transfers.<\/li>\n\n\n\n
                    4. Standard contractual clauses when applicable.<\/li>\n\n\n\n
                    5. Backup and disaster recovery policy.<\/li>\n\n\n\n
                    6. Information about access by support teams outside the EU.<\/li>\n<\/ol>\n\n\n\n

                      This requirement is important because many CRM implementations depend on ecosystems. The CRM may be in the EU, but a lead enrichment, analytics or support tool may transfer data to other countries.<\/p>\n\n\n\n

                      The common mistake is to ask only \u201cwhere are the servers?\u201d and ignore processors, integrations, logs and technical support.<\/p>\n\n\n\n

                      10. Governance of integrations and processors<\/h1>\n\n\n\n

                      CRM and automation rarely operate in isolation. They usually connect the website, forms, email marketing, ERP, advertising platforms, analytics tools, call centre, chat, webinars, proposals, invoicing, BI and API integrations.<\/p>\n\n\n\n

                      Each integration creates data circulation. Each vendor may act as a processor. Each API may expose data if not configured correctly. For this reason, governance of integrations is a central security and GDPR requirement.<\/p>\n\n\n\n

                      Features to verify:<\/p>\n\n\n\n

                        \n
                      1. Inventory of all integrations connected to the CRM.<\/li>\n\n\n\n
                      2. Processing agreements with relevant vendors.<\/li>\n\n\n\n
                      3. Control of API permissions.<\/li>\n\n\n\n
                      4. Management of tokens and access keys.<\/li>\n\n\n\n
                      5. Synchronisation logs.<\/li>\n\n\n\n
                      6. Data minimisation rules by integration.<\/li>\n\n\n\n
                      7. Approval process for new tools.<\/li>\n<\/ol>\n\n\n\n

                        This requirement is often the most neglected. The company may have a well configured CRM, but lose control when data moves to spreadsheets, external tools or integrations created without governance.<\/p>\n\n\n\n

                        The common mistake is to let teams create integrations without prior assessment. This happens with automation tools, no code connectors, manual exports and occasional scripts. The risk is not only in the CRM. It is in the ecosystem around it.<\/p>\n\n\n\n

                        How to configure these requirements in HubSpot, Salesforce and Zoho<\/h1>\n\n\n\n

                        HubSpot, Salesforce and Zoho can support security and GDPR requirements, but they require adequate configuration. No platform guarantees compliance simply by being contracted.<\/p>\n\n\n\n

                        HubSpot<\/h3>\n\n\n\n

                        HubSpot is strong for teams that need to integrate marketing, sales and service in an accessible platform. It allows companies to work with consent properties, email subscriptions, forms, permissions, teams, workflows and reports. For B2B companies, it is particularly useful when the goal is to connect lead capture, contact management, automation and pipeline.<\/p>\n\n\n\n

                        The critical point is to configure legal bases, subscription types, preferences, retention and permissions correctly. Without this configuration, the platform\u2019s ease of use may lead to excessive data use or communications without adequate segmentation.<\/p>\n\n\n\n

                        Salesforce<\/h3>\n\n\n\n

                        Salesforce is suitable for organisations with greater operational complexity, multiple access profiles, several teams, custom objects, advanced rules and enterprise integrations. It has strong personalisation capabilities, but that flexibility requires stronger governance.<\/p>\n\n\n\n

                        The risk lies in creating an architecture that is too complex, with permissions, fields, objects and integrations that are difficult to audit. For companies with mature processes, Salesforce can be very robust. For teams without governance, it can become difficult to control.<\/p>\n\n\n\n

                        Zoho CRM<\/h3>\n\n\n\n

                        Zoho CRM offers a good balance between cost, flexibility and ecosystem. It can be a strong option for SMEs that want CRM, automation, campaigns, support, projects and other applications in an integrated environment.<\/p>\n\n\n\n

                        The critical point is to design the data model, permissions, integrations and flows between Zoho applications and external tools properly. As with HubSpot and Salesforce, compliance depends on configuration, not only on the subscription.<\/p>\n\n\n\n

                        Comparative table: GDPR and security requirements for CRM<\/h1>\n\n\n\n
                        Requirement<\/strong><\/td>GDPR obligation or relevance<\/strong><\/td>Operational impact<\/strong><\/td>Risk if it fails<\/strong><\/td>Liminal support<\/strong><\/td><\/tr>
                        Legal basis and consent management<\/strong><\/td>High<\/td>High<\/td>Improper communications, complaints and loss of trust<\/td>Configuration of fields, forms, preferences and workflows<\/td><\/tr>
                        Data encryption<\/strong><\/td>High as a security measure appropriate to the risk<\/td>Medium<\/td>Data exposure in the event of an incident<\/td>Assessment of vendors and technical requirements<\/td><\/tr>
                        Access control<\/strong><\/td>High<\/td>High<\/td>Unauthorised access and data leakage<\/td>Definition of profiles, teams and permissions<\/td><\/tr>
                        Data portability<\/strong><\/td>High when applicable<\/td>Medium<\/td>Inability to respond to data subject requests<\/td>Export processes and documentation<\/td><\/tr>
                        Right to erasure and retention<\/strong><\/td>High when applicable<\/td>High<\/td>Improper data retention<\/td>Deletion, anonymisation and retention workflows<\/td><\/tr>
                        DPIA<\/strong><\/td>Situational, but critical in high risk processing<\/td>Medium<\/td>Launching automations with high risk without assessment<\/td>Data mapping and assessment support<\/td><\/tr>
                        Records of processing activities<\/strong><\/td>High in many contexts<\/td>Medium<\/td>Lack of evidence in an audit<\/td>Inventory of data, purposes and integrations<\/td><\/tr>
                        Notification of breaches<\/strong><\/td>High<\/td>High<\/td>Failure to meet the 72 hour deadline<\/td>Procedures, logs and response model<\/td><\/tr>
                        Location and international transfers<\/strong><\/td>High when there are transfers outside the EEA<\/td>Medium<\/td>Transfers without appropriate safeguards<\/td>Assessment of vendors and processors<\/td><\/tr>
                        Governance of integrations<\/strong><\/td>High as part of processing accountability<\/td>High<\/td>Loss of control over data in the ecosystem<\/td>Integrated architecture and operational governance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                        How to prepare a DPIA for B2B marketing automation<\/h1>\n\n\n\n

                        A DPIA, Data Protection Impact Assessment, starts by mapping the processing. Before assessing risks, the company needs to know what data is collected, through which channels it enters, where it is stored, which systems receive it, which automations use it and which decisions are made based on that data.<\/p>\n\n\n\n

                        In B2B marketing automation, this analysis should include forms, cookies, campaigns, scoring, segmentation, automated emails, CRM integration, connection to sales, data enrichment and performance reports.<\/p>\n\n\n\n

                        The second step is to assess necessity and proportionality. The question is not only \u201ccan we collect this data?\u201d. The correct question is \u201cdo we really need this data for this purpose?\u201d. If the campaign can work with less data, less data should be collected.<\/p>\n\n\n\n

                        The third step is to identify risks. Common examples include excessive segmentation, lack of transparency, outdated data, opaque scoring, unexpected communications, access by people without operational need or transfer to external tools without safeguards.<\/p>\n\n\n\n

                        The fourth step is to define mitigation measures. These may include clear consents, retention policies, pseudonymisation, access limitation, human review of decisions, simple opt out, activity logs, vendor documentation and testing before activating workflows.<\/p>\n\n\n\n

                        The DPIA should be reviewed whenever the processing changes in a relevant way. A simple nurture automation does not carry the same risk as a scoring model fed by multiple sources and used to prioritise commercial opportunities.<\/p>\n\n\n\n

                        What are the fines for GDPR non compliance in Portugal?<\/h1>\n\n\n\n

                        GDPR provides for two main levels of administrative fines. The most serious infringements may reach 20 million euros or 4% of annual worldwide turnover, whichever amount is higher. Other infringements may reach 10 million euros or 2% of annual worldwide turnover. These limits are set out in Article 83 of GDPR.<\/p>\n\n\n\n

                        In practice, risk should not be assessed only by the size of the fine. There is also reputational risk, loss of trust, operational disruption, incident response costs, audits, the need to clean databases and loss of commercial activation capacity.<\/p>\n\n\n\n

                        For SMEs, the best strategy is operational prevention. This means choosing appropriate tools, configuring permissions, documenting processing activities, managing consents, defining retention, controlling integrations and training teams.<\/p>\n\n\n\n

                        Why a Marketing Ops consultancy improves security and GDPR in CRM<\/h1>\n\n\n\n

                        A Marketing Ops consultancy adds value because it connects three dimensions that are usually separate: commercial strategy, technology and data governance.<\/p>\n\n\n\n

                        The legal team can interpret obligations. The IT team can assess technical security. The marketing team wants to execute campaigns and generate pipeline. The problem is that the CRM lives at the intersection of these areas. Without an operational bridge, the risk is creating policies that no one applies, or efficient automations that no one can audit.<\/p>\n\n\n\n

                        This is where Liminal adds value. Liminal helps companies turn GDPR requirements into concrete processes inside CRM and automation platforms. This includes data structure, consent fields, segmentation rules, permissions, workflows, integrations, reporting and team training.<\/p>\n\n\n\n

                        The question is not only whether to choose HubSpot, Salesforce or Zoho. The question is how to design a system in which data, processes and automations support commercial growth without creating unnecessary risk.<\/p>\n\n\n\n

                        Conclusion<\/h1>\n\n\n\n

                        GDPR and security should not be treated as a final step in CRM implementation. They should be part of the initial architecture design.<\/p>\n\n\n\n

                        A CRM platform can be powerful, but if it does not have a documented legal basis, clear consents, adequate permissions, data export, retention, erasure, logs, incident management and integration control, the company remains exposed.<\/p>\n\n\n\n

                        The 10 requirements presented in this article help assess vendors, review existing configurations and prepare a more secure implementation. They do not replace legal advice or the work of a Data Protection Officer when applicable, but they create a solid operational foundation for CRM and automation decisions.<\/p>\n\n\n\n

                        In 2026, B2B companies that treat data rigorously will have a competitive advantage. They will communicate with more confidence, activate databases with lower risk, respond better to audits and build more transparent relationships with clients and prospects.<\/p>\n\n\n\n

                        The right technology matters. But architecture, governance and adoption matter more.<\/p>\n\n\n

                        \n
                        \"Livro:<\/a><\/figure>\n<\/div>\n\n\n

                        Count on Liminal\u2019s CRM specialists<\/h2>\n\n\n\n

                        The world of Marketing and Technology is constantly evolving. It is increasingly important to rely on specialists who ensure that innovations are integrated into companies. In addition, for technology to contribute to business success, it is essential to have a strategy that guides the implementation, adoption and evolution of systems.<\/p>\n\n\n\n

                        As MarTech specialists, Liminal<\/a> offers an integrated vision that combines Technology, Marketing and Strategy. We ensure the successful adoption and implementation of marketing technologies, whether through the impartial choice of the right systems to address the challenges of the company, the adaptation of processes and flows in existing systems, or the development of a CRM<\/a> & Automation<\/a> strategy that contributes to business growth.<\/p>\n\n\n\n

                        FAQs about GDPR and security requirements in CRM<\/h1>\n\n\n\n
                        What is GDPR and how does it affect CRM?<\/strong><\/summary>\n

                        GDPR is the General Data Protection Regulation and applies to the processing of personal data of natural persons. In the context of CRM, it affects how the company collects, stores, uses, shares, exports and deletes data from contacts, leads, clients and users.<\/p>\n<\/details>\n\n\n\n

                        Is B2B data also covered by GDPR?<\/strong><\/summary>\n

                        Yes, when it identifies or makes a natural person identifiable. A general email such as info@company.pt<\/a> may not directly identify a person, but a professional email with name, job title and company is normally personal data.<\/p>\n<\/details>\n\n\n\n

                        Is marketing automation compatible with GDPR?<\/strong><\/summary>\n

                        Yes. GDPR does not prohibit marketing automation. It requires transparency, an appropriate legal basis, security, respect for data subject rights and limitation of the data used for each purpose.<\/p>\n<\/details>\n\n\n\n

                        Is consent always necessary for B2B campaigns?<\/strong><\/summary>\n

                        Not necessarily. Consent is one possible legal basis, but it is not the only one. Depending on the case, legitimate interest or another legal basis may exist. The choice must be documented and validated according to the purpose, context and expectation of the data subject.<\/p>\n<\/details>\n\n\n\n

                        How long can data remain in the CRM?<\/strong><\/summary>\n

                        There is no single time limit. GDPR requires storage only for as long as necessary for the purpose. The company must define retention policies by data type, purpose and legal obligation.<\/p>\n<\/details>\n\n\n\n

                        What happens if someone asks to have their data erased?<\/strong><\/summary>\n

                        The company must assess whether the request applies and whether there are legal obligations that justify partial retention. When applicable, it must delete or anonymise the data and ensure that the request is reflected in integrated systems.<\/p>\n<\/details>\n\n\n\n

                        Should the CRM be hosted in the European Union?<\/strong><\/summary>\n

                        It is not always mandatory, but it can simplify compliance. When there are transfers outside the European Economic Area, appropriate mechanisms must exist, such as adequacy decisions or standard contractual clauses.<\/p>\n<\/details>\n\n\n\n

                        What should exist in a data breach process?<\/strong><\/summary>\n

                        There should be detection, recording, risk assessment, identification of the affected data, a decision on notification to the CNPD, communication to data subjects when applicable and documentation of the measures taken.<\/p>\n<\/details>\n\n\n\n

                        Does an SME need records of processing activities?<\/strong><\/summary>\n

                        Many SMEs that use CRM and automation regularly should maintain documentation of processing activities, even when the formal obligation depends on the context. In practice, it is an essential good practice for audits, response to data subjects and risk management.<\/p>\n<\/details>\n\n\n\n

                        <\/p>\n

                        Feedback<\/span>
                        \n\t\t\t\t\t<\/span>\n\t\t\t\t<\/div>
                        \n\t\t\t\t\t<\/span>\n\t\t\t\t<\/div>
                        \n\t\t\t\t\t<\/span>\n\t\t\t\t<\/div>
                        \n\t\t\t\t\t<\/span>\n\t\t\t\t<\/div>
                        \n\t\t\t\t\t<\/span>\n\t\t\t\t<\/div><\/div>No rating yet<\/span><\/div>
                        O meu feedback:<\/span>