Security & Compliance

Welcome to the Security & Compliance Hub.

This page covers Enreach Outbound & Enreach Flows' security measures and GDPR compliance. Your data is in safe hands with us.

A note on naming conventions in this document:

Enreach Outbound and Enreach Flows are product names. Enreach Campaigns is the legal entity.

GDPR

Enreach Outbound & Enreach Flows is GDPR and ISO 27001 compliant. As part of our Information Security Management System (ISMS), all solutions and aspects of their delivery — including technical and organisational measures and the entire value chain — are reviewed annually by independent external IT auditors under the ISAE 3402 and ISAE 3000 audit standards. Full reports are available for download on our website.

LEGAL DOCUMENTS

Four legal documents define our vendor/customer and data processor/data controller relationship:

1. The Contract

2. Terms and Conditions

3. Data Processing Agreement (DPA)

4. Data Privacy & Platform Security Legal Documents

DATA HOSTING

Our services are co-located across Danish data centres and AWS in Dublin and Frankfurt.

- Physical servers are hosted in our racks in data centres in Denmark.

- Virtual servers are hosted in AWS data centres in Frankfurt, Germany and Dublin, Ireland.

- Production data is hosted in EU-based data centres only. No data ever leaves the European Union.

- Prior to using AWS, we obtained written confirmation that data will not be transferred outside of EU locations.

AWS (Amazon Web Services) is a US company, but the use of their EU-only locations has been assessed and accepted by the EDPB (confirmed with Enreach's Group DPO).

SUB-DATA PROCESSORS

Sub-data processors used to deliver our services securely are listed on our website (GDPR section). Hosting and housing providers do not have access to customer data. Data is encrypted both at rest and in transit.

ACCESS MANAGEMENT & CRYPTOGRAPHY

Access Control

Access rights are granted solely on the basis of work-related need, with heads of department responsible for approvals. Controls ensure ongoing alignment between access rights and job functions.

- Devices (PCs, mobiles, tablets) and passwords are subject to defined protection requirements.

- Only privileged personnel have access to system administrator tools, central servers, and source code.

- Production servers containing customer data are located only in Enreach Campaigns' data centres.

- Privileged access is reviewed and inspected on at least a quarterly basis.

Authentication

- Users authenticate via instance name, username, and password. MFA (via SMS or email code) and IP whitelisting are available and recommended.

- Multi-factor authentication is supported for users, business administrators, IT administrators, and remote access.

- Remote access uses strong authentication, secure gateways, encrypted sessions, and all activity is logged and subject to independent review.

Password Policy

- Passwords are hashed and salted using PBKDF2.

- Full compliance: lockout duration (30 minutes), unsuccessful logon attempts (6), complexity rules (mixed character types and/or length).

- Partial compliance: password history and age requirements are not natively enforced, but password resets can be triggered on request.

- Idle sessions are terminated after 30 minutes or more. Sessions are flushed nightly to avoid interrupting agent wrap-up or paused admin work.

Encryption

- All data in transit uses HTTPS only (industry best practice).

- Databases are encrypted at rest (industry best practice).

- Encryption keys are managed solely by Enreach Campaigns and stored in AWS KMS, with all access and usage logged in AWS CloudTrail.

- SSL certificates are managed exclusively by the IT department (application architect and network administrator). No certificates may be acquired bypassing this process.

- Enreach Campaigns has documented procedures for cryptographic key management across the full lifecycle: generating, storing, archiving, retrieving, distributing, revoking, and destroying keys.

Service Accounts

Service accounts are used with documented accountability and reviewed periodically, as assured through the ISO 27001-based ISMS and annual ISAE 3000/3402 audits.

ASSET MANAGEMENT

- All assets are defined with ownership, criticality, and technical dependencies.

- Servers, systems, and networks are documented and kept up to date at the introduction of new equipment, systems, or architectural changes.

- Acceptable use of systems is defined for all employees, covering access, use, and export of data. Data is categorised per GDPR standards.

- Customer data must not be stored locally, on USB sticks, or on other portable media, except where a customer has requested data transfer in writing or where transfer between servers via network is not possible. In such cases, data must be anonymised or pseudonymised where possible, and the device must be password protected.

- Portable devices must not be sent by regular mail; they must be hand-delivered by Enreach Campaigns staff or collected by the customer.

- When decommissioning physical servers, hard disks are either securely formatted (making data irrecoverable), physically destroyed, or both.

Inventory, Ownership, Classification

- All assets containing, handling, or processing customer data are catalogued and included in a maintained, periodically reviewed inventory.

- Each information asset has an appointed owner responsible for its full lifecycle, including implementation of appropriate security measures.

- Documented procedures exist for information classification, labelling, acceptable use, and secure disposal and re-use of equipment.

COMPLIANCE

Certifications and Audits

- ISO 27001: Not directly certified, but ISO 27001 is the ISMS framework used and is audited annually under ISAE 3000 and ISAE 3402.

- ISAE 3402: Yes (audited). Equivalent to SOC 2.

- ISAE 3000: Yes (audited).

- ISO 9001, ISO 27017, ISO 27018, SOC 3, HIPAA, PCI/DSS, MIFID II, TÜV, BSI IT Grundschutz, CSA OCF, EuroCloud: Not certified.

Penetration Testing

Annual penetration testing is conducted by an independent external third party. Reports are confidential and for internal use; key findings are included in audit reports where relevant.

Third-Party Controls

- Sub-processors are assessed annually via ISAE 3402, SOC 2 (or equivalent) reports, plus follow-up interviews.

- Full ISAE 3402 and ISAE 3000 audit reports are publicly available on the Enreach Outbound website.

- Pen test reports are confidential and cannot be shared with end customers in full.

Data Retention and Contract Termination

- Customers can delete all data within their setup using project-level deletion rules.

- Upon contract termination, customers may request data export (e.g. via SFTP) prior to deletion, as agreed between parties and defined in the DPA.

Personal Data Anonymisation

Personal data is not automatically anonymised when a user is deactivated. This must be done manually by the customer.

Key Compliance Questions

Q: Are all contractual and regulatory requirements affecting information security identified and kept up to date?

A: Yes.

Q: Are intellectual property rights and use of proprietary software managed via documented procedures?

A: Yes.

Q: Is information retention aligned with contractual and regulatory requirements?

A: Yes.

Q: Is the ISMS independently reviewed at planned intervals or after significant changes?

A: Yes.

Q: Is compliance with security controls regularly reviewed, including technical reviews?

A: Yes.

CONNECTIVITY & INTEGRATIONS

- The solution is a web application accessed over the internet via HTTPS.

- Users authenticate via instance name, username, password, and recommended MFA + IP whitelisting.

Integration Options

Enreach Outbound offers:

- A comprehensive REST API supporting create, update, read, and delete operations on all logical entities.

- HTTP triggers to push event-driven calls to any external webservice/API (e.g. on lead closure).

- An in-app scripting interface (TypeScript) for modifications to the agent contact page GUI.

- A Zapier app for Zapier-based integrations.

Flows by Enreach offers:

- A comprehensive external REST API.

- HTTP triggers.

- Scheduled imports of data files from SFTP servers.

Communication Features

- Customers can configure their own email gateway (SMTP server).

- Built-in SMS features are available via Enreach Campaigns' SMS providers.

- Standard APIs allow data exposure to third-party solutions, including reporting tools (subject to customer-side development if required).

DATA HOSTING (DETAILED)

Hosting Locations

- AWS: Primarily Frankfurt, secondarily Dublin (EU only).

- Physical hosting: InterXion and Global Connect, both in the Copenhagen area, Denmark.

AWS Services Used

- Windows webservers, EC2

- MySQL databases

- S3 storage (recorded conversations and email attachments)

- Linux/Freeswitch/Kamailio for telephony (SIP, WebRTC)

All production data is hosted in EU-based data centres only. AWS instances are dedicated instances with all data encrypted at rest and in transit. Written confirmation from AWS confirms data is not transferred or replicated outside EU locations.

Sub-processor controls are assessed annually via ISAE 3402, SOC 2 (or equivalent) reports and follow-up meetings. Changes to approved sub-processors are notified to data controllers in advance to allow for objection or data withdrawal.

DATA PROTECTION & EXTRACTION

Encryption and Access

- All data transfer uses HTTPS only.

- Internal architecture uses VPNs and dedicated connections.

- Data is encrypted at rest; encryption keys are managed by Enreach Campaigns.

- All features, permissions, and data access rights are controllable at a detailed level via roles and/or individual permissions.

Data Extraction

- All customer data can be exported via GUI or API, and deleted/overwritten with blank values.

- There are no row-level limitations on export (limitations can be removed on request).

- Full extraction can typically be completed in under one day, depending on data volume.

Data Flows and Storage

- Data stored in MySQL databases, encrypted at rest and in transit.

- Encryption: data in transit (HTTPS); data at rest (PBKDF2); encryption keys managed via AWS KMS, access logged in AWS CloudTrail.

- The customer controls what data is uploaded, how long it is stored, and whether it is shared externally.

- Data is not automatically sent anywhere else. External data flows are entirely customer-controlled via API or HTTP triggers.

Data Subject Rights

- API is available to support extraction, correction, and deletion of personal data (EU citizen rights).

- All requirements for data subject rights (access, rectification, deletion, objection) are supported and tested regularly, documented under ISAE 3000.

Data Protection Contact

For DPO contact information, visit the Enreach Data Protection Team page on our website.

EVENT LOGGING

- Event and audit logs are retained for a minimum of 6 months.

- Logs are reviewed on an ad hoc basis; some events are monitored in real time, others periodically.

- All changes to personal data and system entities are logged.

Log Scope

All CRUD operations are logged for: users, organisational units, campaigns and supporting entities, and leads (which contain customer/prospect personal data). Logs include:

- What was changed, from what value, to what value.

- The user who performed the action.

- Session details: IP address, session ID, session start and end.

- For API/external operations: the API account username, the action requested, and any permission denials with reason codes.

- Exact timestamps (CET unless otherwise stated).

Log Access

- Logs are visible in the UI for users with sufficient permissions.

- Bulk export operations can be requested from Enreach Campaigns Support.

GDPR & DATA DELETION

Right to Be Forgotten

- For customer (lead) data: individual leads can be "forgotten" via a dedicated GUI feature. The lead status is set to "Anonymised (status code 610)".

- For agent users: personal data can be deleted, but the user entity and system ID are retained. For security purposes, login logs may still show the original username against historical login attempts even after anonymisation.

Deletion Methods

Enreach Outbound supports both logical (irreversible) deletion and destructive anonymisation, governed by project settings.

Logical deletion (automatic): In Administration → Projects, define automatic deletion rules for leads (success/non-success, sensitive/non-sensitive). When the configured period expires, lead data is permanently deleted and cannot be recovered.

Destructive anonymisation ("Forget lead"): In Administration → Lead Privacy, an administrator can use Forget / Forget lead to anonymise all data linked to a lead ID — including success archive, lead entries, lead changes, SMS, phone numbers, etc. Data is made irrecoverable rather than merely hidden.

Fields and Objects Covered

All lead fields configured as sensitive data types (e.g. national ID/company ID, full name, address, phone/mobile, email, bank account, date of birth, sensitive text/number, sensitive phone/mobile, sensitive email) follow the special deletion rules.

Standard personal fields (name, phone, email, result, appointment fields, etc.) are anonymised/deleted together with the lead when "Forget" is used, or upon automatic deletion.

Source of Truth

Personal data is stored in both Enreach Outbound and Enreach Flows — there are therefore two sources of truth, depending on where the lead was created. There are no additional copies, views, or indexes of the same lead.

Archiving vs. GDPR Deletion

A simple archiving action is not equivalent to GDPR deletion or full anonymisation. Archiving is an operational status change used to stop active processing (e.g. campaign contact), but personal data — name, phone number, email, notes, etc. — may still remain accessible internally unless explicitly deleted or anonymised via the dedicated GDPR functions.

Audit logs and the Lead Admin Access Log are not cleared upon archiving; clean-up is handled via deletion rules and Lead Privacy / Forget.

If your current flow only sets an "archived" status, you do not have a documented guarantee that personal data has been deleted or anonymised. GDPR deletion should be built around the project's automatic deletion rules and/or manual Forget in Lead Privacy. Archiving should be used only as an operational status — not as the deletion action itself.

Automated Deletion

- Deletion rules are configured per project/tenant, per data type (emails, chats, recordings, CDRs, agent login data), with individual timeframes.

- Jobs run nightly, deleting all data covered by the configured rules based on delta time from the data entry date.

- Individual field-level deletion is supported, allowing some fields to be deleted after 1 day while others are retained longer.

- Manual/immediate deletion (outside the nightly job) is also available.

Deletion Process

When data is deleted, field values on a lead entity are updated to NULL (blank). The lead's system ID (a non-identifiable key, e.g. "527972S3012") is retained for system integrity. Logs record that fields X, Y, Z for subject ID were updated to NULL on a given date. Original values are purged from all log tables after 3 days.

Anonymisation vs Deletion

Where appropriate, data is replaced with blank/null values rather than deleted outright, preserving statistical integrity at the entity level while removing personally identifiable values. This can be configured per tenant and per data type.

Call Logs

Call logs contain: call time, agent/channel, campaign, disposition/outcome, references to the lead, recording IDs, technical keys (session ID, call ID), and reporting fields (duration, result, queue, etc.).

Once all master data fields on a lead have been deleted, the data remaining in the calls database is no longer personally identifiable.

Call Recording Retention can be configured per campaign (not just globally) for:

- Success / Non-success recordings

- Full / Partial recordings

When the retention period expires, recordings are automatically deleted. The highest-level setting wins (Project overrides Campaign; if neither is set, the corporate default applies).

There is one category of call data subject to a mandatory legal retention requirement of 5 years: start time, end time, call ID, phone number, corporate ID, and user ID. This data cannot be deleted within that period.

Recordings and Media

Recordings are stored in the database under an encrypted filename. When downloaded, the recording receives the filename you have configured. Deletion is handled through the deletion rules described above, not per individual lead or phone number. Transcripts and metadata are stored as part of the recording record and are handled through the same rules.

Backup and Deletion Integrity

- A full backup is taken every night. All fields deleted during the day are permanently deleted that same night.

- Live data replication runs across 3 steps; deleted data is removed from all 3 steps within a maximum of 5 minutes.

- Offsite backups are stored for a rolling 3-day period; backups older than 3 days are deleted.

- Deleted data is moved to a temporary hidden database table (_itemdata) with a timestamp, and purged after 3 days.

- This ensures deleted data is not restored from backup, is removed from all instances within 3 days, and supports integrity verification after any backup restore.

- These processes are audited by an independent IT auditor under ISAE 3402 and ISAE 3000.

API / Programmatic Deletion

An API is available to support GDPR anonymisation and deletion:

- Anonymisation: POST /leads/{UniqueId}

- Deletion: endpoint available for open leads only.

- API documentation: https://wshero02.herobase.com/api-docs/#!/leads/postleadsUniqueId_post_5

All API lookups and actions return machine-readable status codes (e.g. 200 = OK).

Identifying a Lead for GDPR Purposes

System key: Each lead has a unique LeadID used internally and in Lead Privacy (Forget lead is applied at Lead ID level).

Practical identification keys:

- Phone number: Search in Administration → Lead Privacy → Lead phone numbers. Results show all leads where the number appears; open each lead to apply Forget.

- Other fields: Search by Lead ID, phone number, or other lead data (email, external ID, Salesforce Campaign Member ID, CRM ID, etc.) — provided these have been created as fields in lead master data.

- External/Salesforce IDs: There is no built-in Salesforce Campaign Member ID system key, but custom fields (e.g. ExternalId, SF_CampaignMemberId) can be used as search criteria if configured. The typical flow is: find the person in your own system by external ID → use the matching phone/email/ID stored in Outbound to locate the lead(s) → act on the specific Lead IDs (delete/Forget/retention).

Scope of Deletion

Deletion targets a specific lead ID, not all occurrences of a phone number or email automatically.

- In Lead Privacy → Lead phone numbers, searching by number shows all leads where the number appears.

- Forget is applied per lead ID. When applied, all data linked to that lead ID is anonymised (success archive, lead entries, changes, SMS, phone numbers, etc.).

- There is no single "forget this phone number everywhere" call. You select lead by lead from the list and forget them individually.

To clean up all occurrences: use phone number/email as the search key → get the full list of matching leads → run Forget on each (manually or as an organised process). Combine with Block phone numbers / Do-Not-Call to prevent the number from being re-imported or called going forward.

Duplicate Leads

The system permits multiple leads with the same phone number and provides tools to prevent and manage duplicates.

During upload (prevent duplicates): In Upload Lead Pool, use the Duplicate Search feature to define how duplicates are detected and handled. "Duplicate search only Open Leads" checks only against open leads, so closed/completed leads with the same number do not block new imports. Options include excluding or flagging duplicates.

In Lead Privacy (GDPR management): Search by phone number to see all leads where it appears, including duplicates. Apply Forget to each lead individually.

Blocking (forward-looking): Under Block phone numbers / Do-Not-Call, block the number once to prevent all future imports and calls on that number, regardless of how many leads it appears on.

How Customers Handle Right to Be Forgotten in Practice

Most customers use the built-in "Forget me" function for immediate anonymisation. For periodic deletion, they use the built-in automatic deletion rules. Some customers who receive deletion lists use the API (POST /Leads) to update lead fields with randomised data, ensuring data is both deleted and overwritten and cannot be recovered.

Test Environments

Production data is never used in test or development environments. All test data is synthetically generated to reflect the structure of real data without containing actual personal data.

HUMAN RESOURCE SECURITY

- Pre-employment screening is conducted on all candidates within the framework of applicable legislation.

- All employees sign confidentiality agreements (NDAs) as part of their employment contracts.

- Employees are trained and kept up to date on information security throughout their employment.

- Upon termination, access rights to all business systems are immediately removed and verified.

- Sanctions are defined for breaches or disregard of information security policies.

Staff Outside the EU

Enreach Campaigns has staff in Ukraine (offshore development team) and one developer in Thailand. These individuals work exclusively for Enreach Campaigns and access data only via VPN to EU-hosted servers. No data is hosted locally by these staff members. This arrangement has been assessed by compliance consultants and auditors as equivalent to employees travelling and working abroad, and as compliant with EU data transfer restrictions.

HR Security Controls (ISMS-assured)

- Pre-employment background checks: Yes.

- Confidentiality agreements and security policy briefings upon hire: Yes.

- Security awareness programme (reviewed at least every 3 years): Yes.

- Security responsibilities communicated at role change or termination: Yes.

- Verified personnel access to systems and services on a quarterly basis.

INCIDENT MANAGEMENT & BUSINESS CONTINUITY

Incident Definition

Security incidents include: successful external intrusion; customer data found online without customer approval; employee data found online without Enreach involvement; and confidential business data (contracts, revenue, classified information) found online.

Security events include: situations that could have led to incidents if not detected, and cases where data was accidentally sent to unintended recipients with potential for harm.

Incident Response

- Customers are contacted immediately and no later than within 24 hours if an incident involves their data.

- Documented procedures cover evidence gathering, escalation, and contact with authorities where necessary.

- All employees are trained on incident response procedures.

- An annual summary of analysed incidents and lessons learned is available to data controllers upon request.

- No breaches of personal data security have occurred. Procedures are in place to ensure notification in the event of a breach.

Business Continuity

- IT Disaster Recovery (DR) and Business Continuity (BC) plans exist with defined RTO and RPO, audited under the ISO 27001-based ISMS.

- Failover sub-components are tested monthly; the full plan is tested at least annually.

- Backups are taken daily and transferred to encrypted storage in an off-site data centre (not the same site as the production server). Backup restoration is tested quarterly.

- Backups are not stored on tape; they use encrypted off-site digital storage.

OPERATIONS SECURITY

Infrastructure Hardening and Patching

- Only base system components are installed; unnecessary services are disabled.

- Security patches are applied daily where available.

- Firewalls run on each host, restricting communication to necessary services on dedicated VLANs.

- No systems are directly reachable over WAN; central firewalls control all backend access.

- A Web Application Firewall (WAF) is in place.

- Malware protection is implemented across all systems and assets, with continuously updated signatures.

Monitoring

- All instances are monitored using Prometheus and Zabbix.

- Monitored metrics include: server access, CPU/memory/disk usage, database master-slave lag, heavy SQL queries, telecom channel usage, and call volumes.

- Alerts are sent to key personnel via email (non-critical) or SMS (critical) when defined thresholds are reached.

- Historical logs and events are regularly reviewed for improvements and optimisation.

Network Security

- Multi-layered firewalls; all traffic monitored.

- Databases are accessible only via VPN.

- Traffic is monitored for abnormalities (spikes, delays) with automated alerts.

- Fraud detection cooperation with all telecom operators used as sub-suppliers.

- All data exchange uses HTTPS over the public internet; internal connections use LAN/fibre between data centres.

Change Management

- Changes to production are documented, tested, approved, and validated before deployment.

- Developers cannot deploy their own changes directly to production.

- Master releases target every 3–4 weeks; hot fix releases address critical issues within 3 working days.

- Development, test, and production environments are fully separated; customer PII is never used in test or staging.

NTP and Time Synchronisation

NTP is used across all servers throughout the network.

Key Operations Controls (ISMS-assured)

- Application source code and libraries: least privilege access, monitored.

- Technical vulnerability management: documented process in place.

- System hardening: documented procedure covering OS, databases, applications, network components, and virtual environments.

- Operating software installation: documented procedures in place.

- Log protection: logs protected against tampering, overwriting, and unauthorised access.

- Backup security: backup storage has equivalent protection to the main site.

PROVIDER SERVICE DESCRIPTION

Enreach Outbound & Enreach Flows is a telemarketing system for outbound sales. Enreach Campaigns does not manage any customer data on customers' behalf. All data is uploaded and managed by the customer. At minimum, only a telephone number is required to dispatch outbound calls. All additional data is uploaded by the customer as needed.

Enreach Campaigns acts solely as a data processor, operating on instructions from the customer as data controller.

No third parties have access to customer information. Sub-data processors are used for hosting/housing only and do not have access to data.

RISK MANAGEMENT

Risk management covers all areas connected with delivering the Enreach Campaigns product and service. Risk analysis, assessment, and management follow ISO 27005, based on impact and vulnerability analyses at service level.

The information security policy is signed by Enreach Campaigns' CEO and applies to all employees and close partners. The ISO 27001 framework is used for the ISMS, covering the following control areas:

1. Information security management and security policy

2. Organisation of information security

3. Human resource security

4. Asset management

5. Access control

6. Cryptography

7. Physical and environmental security

8. Operations security

9. Communications security

10. System acquisition, development and maintenance

11. Supplier relationships

12. Information security incident management

13. Information security aspects of business continuity management

14. Compliance

SECURITY POLICY & PROCEDURES

The ISO 27001 framework (listed above) underpins the full ISMS. The ISMS is subject to annual audit under ISAE 3402 and ISAE 3000.

Security Organisation

- Segregation of duties: clearly defined organisation reduces key-person dependency and mitigates risk of data misuse.

- Contact with authorities: responsibility for engagement with public authorities on information security matters is defined.

- Project management: information security is addressed in all project phases and all projects, regardless of size.

Change Logs and Access Logs

1. All changes to data are logged with user attribution (who changed what, and when).

2. All actions on the platform are logged. Not all data is surfaced in the GUI by default; customers may contact Support for full details, which can be provided on request.

Password Management

For Enreach Outbound: all password policy requirements are fully supported.

For Enreach Flows: requirements are partially supported.

Initial password security: users are required to change passwords at first login; no user can know another user's password.

Sub-processor Inspections

Sub-processors are assessed by obtaining ISAE 3402, SOC 2 (or equivalent) assurance reports and conducting interviews to review technical and organisational measures. Documentation is provided to auditors as part of the ISAE 3000 submission.

Secure Logon

Strict password policy, MFA, and VPN are implemented to minimise the risk of unauthorised access.

IT Security Policy Review

The IT security policy is reviewed continuously and at least once per year (audited by IT auditor).

SYSTEM ACQUISITION, DEVELOPMENT & MAINTENANCE

Development Practices

- Development follows an agile methodology derived from SCRUM and RUP, using sprint-based cycles.

- Master releases target every 3–4 weeks. Priority 1 and 2 security issues must be resolved within 3 working days.

- A zero-bug-tolerance policy applies before deploying new code to production.

- Code branches from the main branch for feature development, progressing through: feature branch → pre-production → CX branch → pre-release → release → production.

- Function testing occurs in feature branches. Integration, regression, and happy-flow testing occurs in CX/pre-release/release branches using Enreach's own test data only.

Test Data

- Test and production environments are completely segregated.

- Customer PII is never used in testing.

- Test data is synthetically generated to reflect the structure of production data without containing actual personal data.

- Transfer of customer configuration data to staging for development purposes requires written approval from the Head of Operations and Head of Development, and may never include prospect or employee personal data.

Key Development Controls (ISMS-assured)

- Security and privacy by design: integrated into all system design.

- Security requirements defined and approved before development begins.

- Secure architecture principles maintained across all layers.

- Development, test, acceptance, and production environments are appropriately separated and secured.

- Security review and testing within every development cycle before production deployment.

- Acceptance testing follows a documented procedure; results are documented.

- Test data is classified and handled under documented procedures including isolated environments and post-completion removal.

- Customer data is never used for testing without explicit customer approval.

ACCESS CONTROL

- Access control policy is documented and maintained, including assignment of business roles to system roles and lifecycle management of access rights.

- Least privilege principle applied: users and system components have only the minimal access required for their function.

- Network access restricted per access control policy; default passwords changed before users connect.

- Unique user IDs for all employees; shared/function accounts only permitted where operationally necessary and documented.

- Access provisioning and revocation follow a documented process.

- Privileged access rights are restricted, minimised, and require formal management approval before activation.

- Administrative accounts are separated from regular user accounts.

- High-privilege accounts are verified every 6 months; activities are fully logged and traceable.

- User accounts are reviewed annually.

- Access rights are disabled or adjusted upon termination or role change; users do not automatically regain old access rights upon account reactivation.

- Accounts are locked for a specified period after repeated failed login attempts.

- Passwords are never transmitted in clear text; password and account information are never sent together.

Provider Employee Access

Staff at Enreach Campaigns follow a least-privilege access principle. Only the core IT Architectural Team has OS-level access. The commercial Support team may access a customer's application account only with explicit permission granted by the customer.

What could be compromised to expose data across tenants?

Data is completely separated across tenants. Even in the multi-tenant database, all table keys restrict data to the individual tenant. The database layer (Linq2db) adds an additional security layer ensuring it is physically impossible to return data for another tenant, regardless of parameters passed. Annual third-party penetration tests specifically test cross-tenant data access; no successful attempts have ever been made.

PHYSICAL AND ENVIRONMENTAL SECURITY

- Physical perimeter protection requirements are defined and documented for all premises containing systems processing customer data.

- Physical entry controls are in place for offices, production sites, and data centres.

- Physical keys, cards, and access codes are stored securely; theft, loss, or misuse is treated as a security incident.

- Visitor access procedures are documented and implemented.

- Procedures exist for physical protection against natural disasters and accidents, based on risk assessment.

- Environmental conditions in data centres are monitored and regularly inspected.

- A clear desk policy is implemented for all information processing facilities.

Servers are only placed in data centres that can provide ISAE 3402 assurance reports annually. Office locations are subject to additional physical security procedures.

COMMUNICATIONS SECURITY

- Security mechanisms, service levels, and management requirements for all network services are identified and documented.

- A documented network zone model defines security requirements for data within and between network zones.

- All data exchange uses secure connections (HTTPS over public internet; internal LAN/fibre between data centres).

- Information exchange procedures (including NDAs) are agreed between parties before any exchange takes place.

- Electronic messaging is protected against unauthorised disclosure, alteration, duplication, or destruction.

SUPPLIER RELATIONSHIPS

- Security controls agreed with the data controller are propagated throughout the supply chain, including all sub-contractors.

- Sub-contractor agreements must be signed before any sub-contractor personnel can access customer systems or data.

- The data controller has the right to audit Enreach Campaigns against agreed requirements, or may request third-party audit reports covering the services in scope.

- The data controller will be informed without undue delay of any changes that may affect the information security controls agreed within the services.

HIGH AVAILABILITY, DISASTER RECOVERY & REDUNDANCY

- Data is replicated to slave instances in real time.

- Databases are separated across different AWS availability zones.

- Failover servers are in place for all production servers, with automated failover managed by KeepAlived.

- Data is replicated from AWS to physical servers in private racks at InterXion and Global Connect (both Copenhagen area, Denmark).

- HA and failover are managed entirely by the service; customers are not involved in failover or recovery scenarios.

- The service is fully GDPR compliant, as assured and audited (see ISAE 3000 report on our website).

- Full details are available in the latest ISAE 3402 audit report on our website.

SERVICE METRICS, LOGGING, MONITORING & INCIDENTS

- Logging and alerting at multiple levels are implemented using Prometheus and Zabbix.

- Lead history (calls, activities) can be exported via API.

- Monitoring capabilities are designed to detect unauthorised activity including port scanning and cross-tenant attacks.

- Full details are available in the latest ISAE 3402 audit report on our website.

PROVIDER AND SERVICE ACCREDITATIONS

General IT audit reports (ISAE 3402, ISAE 3000) are available on our website (Audits section). Cloud-specific certifications and further compliance information are also detailed in those reports.

AI (DIALOX)

The following information relates to DialoX, Enreach's AI partner. It is drawn from DialoX's Privacy Statement. Enreach acts as an independent Data Controller for processing under DialoX.

Data Processing

DialoX processes personal data for the following legitimate business purposes:

- Improving DialoX core functionality and customer experience.

- Responding to business queries.

- Quality control.

- Providing developer and customer support.

The legal basis is legitimate interest, proportionate to Enreach's business objectives and compliant with applicable Data Protection Legislation.

Personal Data Processed

When using DialoX messaging functionality, the following data is processed: IP address, login data, chat message content, chat partner details, country, language, message status, and any files transmitted (including voice mails and transcriptions).

Customers are responsible for informing their employees and end users (bot users) that submitting Sensitive Personal Data via DialoX constitutes explicit consent for its processing.

Data Storage and Retention

- All data is stored on servers within the EEA.

- Data is retained only as long as necessary to fulfil collection purposes and meet legal and reporting obligations.

- Data retention periods can be configured per environment.

LLM Training

No. DialoX uses GPT models hosted on Azure in the EU and has opted out of training on customer data.

OTHER RESOURCES

- Audit reports, legal documentation, and sub-data processors: available on our website

- GDPR compliance information: available on our website

- Data Protection Officer contact: available on our website