How SDRbuddy handles your data

Limited CRM input, with clear information sources

The design limits normal automatic CRM input used as prospect context to the company name and, where available and permitted, the target person’s name and professional role or title. Broader CRM prospect records are excluded. Separately permitted public or external research is a different source of information.

For normal automatic CRM-derived prospect context, the approved maximum is company name, plus optional target-person name and professional role or title. The optional fields must be available and permitted. Broader CRM record content—including company domain, email address, telephone details, notes, previous-contact history, communications, free text and custom prospect fields—is never automatically imported as substantive prospect context under this design. Limited technical record identifiers may be used for separately governed integration or correlation purposes; that does not make them prospect context.

Separately permitted public or external research can supply business or professional context. For example, a company domain found independently through permitted research has a different source from a domain imported from your CRM. Passing excluded CRM information through a search or AI service does not make it permitted research. Generated assistance and permitted immediate post-call information are also governed separately. The three-field CRM limit is therefore not a claim that SDRbuddy only ever processes three fields.

AI services with defined purposes and authorization

The governance requires relevant AI processing to stay within eligible purposes and data boundaries, the required customer authorization and applicable legal conditions. Customer approval can restrict processing; it cannot authorize processing outside those limits.

External AI, search or research services may process information as part of the authorized workflow. The governance limits each service to information that is eligible, permitted and needed for its role; it does not grant unrestricted access to your CRM. Customer-specific information must identify relevant services and explain their purposes, data categories, processing locations and material retention, training, secondary-use and human-access conditions. These conditions depend on the actual service and configuration. SDRbuddy-side non-persistence does not establish zero provider retention or a universal no-training promise.

Under SDRbuddy’s governance, first introducing external AI, search, research or inference processing that receives customer- or prospect-derived data normally requires explicit approval from an authorized customer representative, unless valid existing approval already covers the arrangement. Being informed, acknowledging information and approving a defined arrangement are different actions. This business approval does not by itself establish statutory consent, contractual authority, subprocessor authorization or international-transfer authorization.

You may refuse an arrangement or withdraw approval for an enforceable scope. The affected future processing must then respect that authorization state; an alternative service path is not guaranteed. Withdrawal does not automatically erase earlier outputs, customer-system records or evidence that must legitimately be retained. Material changes require review and the applicable notice, acknowledgement or renewed approval. A fallback provider must independently meet the relevant conditions.

Processing locations · Responsibilities and further information

Temporary prospect processing, governed retention

Measuring activity without building prospect profiles · Limited CRM input, with clear information sources

SDRbuddy is designed for temporary prospect-specific processing, without building an accumulating prospect-content database. This does not mean no information is retained: service, security and measurement records may persist, and external providers have their own governed retention conditions.

SDRbuddy’s normal architecture does not intentionally maintain a lasting prospect-content repository after information is no longer needed for the authorized processing lifecycle. Temporary processing can involve memory, transport, caches or queues. Any permitted prospect content in logs, backups or evidence must also have a defined purpose and bounded lifecycle. Account, authentication, billing, support, security and other justified service records are distinct from prospect content. Outputs placed in your designated systems may remain there under your governance. External-provider retention is assessed separately.

Retention and deletion must follow the applicable information category, purpose, configuration and contractual requirements. At the end of processor services, the framework preserves the customer’s applicable choice of deletion or return of data still held; already expired or deleted transient data need not be reconstructed. Where permitted residual backup copies remain, they must stay protected, unavailable for ordinary production use and subject to bounded expiry. Residual copies are not treated as completed deletion. Exact periods and arrangements belong in the information applicable to your service.

Measuring activity without building prospect profiles

The design uses a Contact Attempt as its measurement unit. Permitted activity, outcome and assurance records may persist for their governed purposes without becoming a repository of prospect research, contact histories or broader CRM records. Analytics and technical identifiers cannot be used to bypass the CRM boundary. Reuse for SDRbuddy’s own purposes, such as benchmarking or model training, requires separate assessment and authorization; it does not follow merely from providing the service. Removing or replacing a name alone does not establish that information is anonymous.

People remain in charge

The approved design supports people before, during and immediately after a call. It excludes autonomous prospect outreach and emotion, biometric or voice inference. People remain responsible for their sales actions.

SDRbuddy’s approved B2B-first scope is preparation immediately before a call, assistance during it and support immediately afterwards. The design excludes autonomous prospect outreach and emotion, biometric or voice inference. AI assistance supports the person conducting the work; it does not transfer responsibility for sales actions to the AI.

Safeguards supported by evidence

Temporary prospect processing, governed retention · AI services with defined purposes and authorization · Clear processing locations and transfer arrangements · Responsibilities and further assurance

The approved architecture makes data minimisation, limited retention, access governance and security responsibilities part of the service design. The safeguards implemented in a particular setup need supporting evidence; design approval is not a security certification.

The approved privacy and security framework calls for purpose-limited processing, data minimisation, governed access, confidentiality, appropriate security measures and incident cooperation. Implemented safeguards must match the actual processing and applicable security documentation. Evidence for a particular setup should distinguish deployed controls from requirements or future targets. This page does not assert independent certification or guarantee complete security.

Clear processing locations and transfer arrangements

Processing geography must be considered across application infrastructure, stored records, external services, support access and downstream processing. Hosting in one region would not, by itself, establish that all processing stays there. The applicable customer information must describe material locations and transfer arrangements. Authorizing a provider does not separately authorize every international transfer or expand the information eligible for processing. This page makes no EU-only processing claim.

Responsibilities and further assurance

For ordinary customer-directed prospect processing, SDRbuddy’s intended arrangement is that the customer acts as controller and SDRbuddy as processor. Actual roles depend on the activity. The framework assigns customer responsibilities for lawful purposes, source data, instructions, transparency, authorized users, outbound activity and retention in customer systems. SDRbuddy’s processor responsibilities include governed processing, confidentiality and security, provider oversight, applicable rights and incident assistance, and deletion or return. The applicable agreements and processing specification define the arrangement; this page explains it rather than replacing them.

For a pilot or service assessment, ask your SDRbuddy contact for the information applicable to your setup: processing scope, enabled providers and services, retention and training conditions, geography and transfer arrangements, security evidence, applicable DPA and supporting assurance material. Customer-specific restrictions and approval state must be reflected in that information. A public overview or a pilot approval does not by itself establish production authorization.