Security & Compliance

Approved encryption solutions 

Does Enreach Campaigns only use encryption solutions that have been evaluated, documented and approved? Any exceptions shall be risk based, approved and documented. 

Key management 

Does Enreach Campaigns have a documented procedure for cryptographic key management throughout their life-cycle, including generating, storing, archiving, retrieving, distributing, revoking and destroying keys?

All assets are defined with ownership, criticality, and technical dependencies such as services that are dependent on certain assets.

Servers, systems, network etc. are documented and available for relevant technical personnel. At the introduction of new equipment and new systems, or at changes to architecture and infrastructure, relevant documentation is updated to ensure that this is always up-to-date.

The acceptable use of systems for employees has been defined, which i.a. includes guidelines for accessing, using, and exporting data. Data is considered categorised according to GDPR’s categories for this purpose, and special procedures are applicable for certain types of data.

We have procedures concerning the management of portable devices, disposal of devices, as well as transport of portable, data-carrying devices, as well as for the classification and labelling of data. This means, for one thing, but is not limited to, that data solely must be stored in systems and on physical and virtual servers labelled and specified for the purpose.

Customer data must not in principle be present anywhere else, including locally, on USB sticks, on other disks (flash drives), and similar. An exception to this is if a customer has requested in writing to be handed over data, or if it is necessary to transport data between two servers, and the transmission cannot occur via network.  If data is stored temporarily on such USB sticks, drives and similar, data must, to the widest extent possible, be anonymised or pseudonymised, and the physical device (including folders on it) must be password protected.

As a rule, these devices must never be sent by regular mail to customers but must be transported by Enreach Campaign’s employees or picked up by the customer. When physical servers are decommissioned, and data on hard disks no longer needs to be present on the drives in question, these disks must either a) be formatted in such a way that restore of data no longer is possible, b) be physically destroyed and the disks disposed of by employees in Enreach Campaigns’ IT department, or c) both. 

Inventory of assets 

Have assets that contain, handle or process the data controller's information of any kind been identified, catalogued and included in an inventory which is maintained, updated and periodically reviewed?

Ownership of assets 

Does each information asset have an appointed owner within the provider’s organisation who is responsible for the asset during the whole life cycle, including the implementation of appropriate technical and organisational security measures derived from the information classification?

Rules for the acceptable use 

Does Enreach Campaigns have documented rules for the acceptable use of information assets within the organisation? In case Enreach Campaigns or its agents make use of the data controller's assets/equipment they shall not be used for non-data controller purposes. 

Procedure for information classification 

Has Enreach Campaigns implemented a procedure for information classification and labelling, that ensures that the data controller's information receives an appropriate classification in accordance with its importance?

Disposal of media 

Is there shall be a documented procedure that ensures secure disposal and re-use of equipment based on the information classification scheme?

Identification of applicable legislation and contractual requirements 

Are all contractual requirements and regulatory requirements, affecting and regulating information security for the service, identified, documented and kept up to date? 

Intellectual property rights 

Does Enreach Campaigns have procedures to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products? 

Procedure for information retention 

Does Enreach Campaigns have procedures for retention of information types established and aligned with contractual and regulatory requirements?

Continuous review of security compliance 

Is the security management system and its implementation independently reviewed at planned intervals, or when significant changes occur?

Compliance with security policies and standards 

Does Enreach Campaigns regularly review compliance with security controls and measures defined in the applicable security management system? For the information and cyber security elements, this will also include technical reviews for ensuring compliance.

As our solution is a web application, it is accessed over the internet.

HTTPS is used for data transfer only. Users authenticate via instance, username and password, and MFA + IP whitelist can be applied (and is recommended). 

Outbound by Enreach offers various features to integrate with other systems and applications.

Besides API, HTTP triggers and third-party integration frameworks, Outbound by Enreach offers an in-app scripting interface, where modifications to the "contact page" (the primary GUI for agent users) can be conducted by customers themselves. For scripting and GUI modification within this interface, TypeScript is being used as the language. 

A wide set of integration features are available. Both Outbound by Enreach and Flows by Enreach offer a comprehensive external API which can be used for various types of integrations.

The API is REST based and allows the user of it to create, update, read and delete all logical entities. For reference, see the publicly available documentation page for the API of Outbound by Enreach here.

Both Outbound by Enreach and Flows by Enreach offer HTTP triggers which can push calls to any external webservice/API based on even driven rules, e.g.: “When a lead is closed as a success (typically a sale), make a POST request to an external API inserting details about the collected lead- and order data”.

Outbound by Enreach offers a Zapier app for integrations via Zapier. Flows by Enreach offers scheduled imports of data files from SFTP servers. 

Customer can set up their own e-mail gateway (SMTP server).

Customer can utilise the built-in SMS features (via Enreach Campaign’s own SMS providers).

Customers can set up jobs using our standard APIs to expose data in all kinds of third-party solutions, incl. reporting solutions (subject to development work being carried out by the customer themselves if needed). 

Outbound by Enreach and Flows by Enreach are hosted in professional data centers only: Two physical hosting (housing) providers in Denmark, and AWS.

Full details available at our website: GDPR and sub-data processors.

Providers are controlled annually by evaluating audit reports based on ISAE 3402 or SOC 2, in addition to follow-up meetings to discuss details and actions, if any.

At AWS, instances are dedicated instances and all data encrypted both in rest and in transit as recommended by EDPB, even though data is not transferred outside EU. Prior to entering business with AWS, we have collected written confirmation that with the choice of their EU locations only, data will not be transferred nor replicated out of the EU. 

AWS (Amazon Web Services) is a US company with data center locations in multiple places across the world. The choice of their EU locations is, at this time of writing, accepted by EDPB (confirmed with Enreach’s Group DPO).

Prior to entering business with AWS, we have collected written confirmation that AWS will not transfer data to any other locations given that we as an AWS customer do not actively order/configure services in other locations.   

From an application point of view, all features, permissions and data access rights can be controlled at a detailed level via roles and/or individual permissions. 

All data transfer takes place via HTTPS only. Internally (internal Enreach Campaigns architecture and infrastructure) VPNs and dedicated connections are used to access and transfer data.

Data is encrypted at rest, encryption keys are managed by Enreach Campaigns. Further details and descriptions are available at our website: GDPR.

Customer data can easily be exported (either from GUI or via API) and then deleted/overwritten with blank values (either from GUI or via API) in case of contract termination.

The exact time it would take to extract all data depends on the volume which customers will upload and store, but from an immediate point of view, as all is available and can be exported with no row-level limitation (as limitations can be removed upon request), it could be done in less than one day. 

What Encryption?

Technical Details: not just ciphers

• DIT (data in transit) - HTTPS
• DAR (data at rest) - PBKDF2
• DIU (data in use, e.g. memory)

What Encryption?

Key management details

All changes to personal data and system entities inside Outbound (and Flows) by Enreach are logged.

The logs are, from a backend point of view, kept in database tables which contain per-record logs of changes to entities.

These are made visible in the UIs as well, hence visible to users who have the decent levels of permissions to access and reviews these logs.

The scope of the logs are the following system entities which can contain personal data and/or other types of data: Users; organisational units (teams, departments); campaigns and its supporting entities; leads (which would be the entities that contain data on customers and potential customers).

All CRUD operations are logged, incl. the detailed change (what was changed, from what, to what).

The user who conducted the particular action is logged.

The session of the user (incl. the ip address of the user, the session id and when this session started and ended) is logged.

If the operation is conducted by an external system (incl. via API), this is logged, and the username of the API account is shown explicitly as evidence of which system requested the action and when. In the event that an external system or API user tries to conduct an action which permission levels do not allow, the request and reason code is logged.

The exact timestamp of the request and operation is shown. Timestamps are always shown in CET unless otherwise stated.

Logs can, when required, be exported from the UIs by users with sufficient levels of permissions themselves, and if bulk export operations are required, these can be ordered from Enreach Campaigns Support.

Partially. With regards to customer data, all individual leads can be “forgotten” hence deleted by a feature tailor made to this from the GUI. This is also reflected in the status of the lead, which will be set to “Anonymized (status code 610)”.

For agent users, personal data can be deleted, but the user entity will still exist with a system id. In some logs, e.g. the login log, a previous login attempt (successful or unsuccessful) will still be displayed with the original user name even if this has been anonymised/overwritten, for security purposes. 

Our solutions are designed to support the customers in being fully self-serviced here, hence data can easily be searched, retrieved, edited, exported, deleted etc.

If our customers reach out to our support for assistance on this, or if Enreach Campaigns receive inquiries from data subjects directly, we have standard procedures for this.

There is an API available that allows clients and partners to fulfil the individual EU citizen rights in terms of extraction, correction and deletion of their PID. 

Can the solution restrict the use of data only to the timeframe when it’s still needed, and provide the option for automatic deletion? 

Yes: the solution supports the GDPR law in regards of deletion of PID data after x days. This time frame (deletion after x days) can be defined individually by every client/tenant.

This time frame can be different for different data types, such as mails / chats / recordings, CDRs, agent login data and any other PID data types. These jobs are executed nightly on Outbound by Enreach database servers and are based on delta time from loading/entering to (the set interval), and delete all data marked as covered by the jobs for deletion.

The same function is available at the single field level to support that individual fields (their values) are deleted after just 1 or a few days while the rest are stored longer (for example). Flow by Enreach: The same principles apply, where the functionality is called macros – here it is also based on delta time from loading / entering, to (the set up interval). In addition to this (applicable to both systems), data with manual jobs can be deleted immediately, i.e. without waiting until the next night.

The previously described functionality by which data is deleted works in practice so that the fields on a lead (system entity for data subject) are retained, but that the values are replaced with "nothing" (in the database context, the value of the fields is updated to NULL). The subjects retain their system ID, which is a system key with no context with personally identifiable data (e.g., 527972S3012).

In the log at the single topic level, it appears that as of (given date) an update has taken place, where the fields X, Y, Z (field names) for subject id (e.g. 527972S3012) has been updated to nothing. The original values are deleted from all log tables after 3 days, cf. the description below. 

The described functionality from both Outbound by Enreach and Flows by Enreach means that tables with data that are visible to users are cleared for content at the latest at night. When executing jobs, the deleted data is transferred to a hidden, temporary database table called _itemdata. Records in this table are encumbered with a timestamp for insertion, and are deleted after 3 days.

All changes in production (master databases) are immediately (in near real time) reflected to all slaves (read and failover databases). Offsite backup is taken by Enreach Campaigns A/S for both Outbound by Enreach and Flows by Enreach nightly, and stored for 3 days rolling. After this, backups are deleted older than 3 days. In practice, this means that deleted data is stored in some database instance for 3 days after the data has been removed visibly to the user. The above methods mean that deleted information is not restored in connection with restore from backup; that data is deleted from all instances (including backups) after 3 days (but is invisible to the user from after each nightly run) and that a data basis is established for double-securing deletion of data in connection with restore from backup (integrity). The above descriptions, including that these are accurate and work in practice, have been audited by an independent IT auditor, through which the supplier has obtained ISAE3402 and ISAE3000 statements. 

Does the application protect Data Subject Rights, enabling a data subject with the right to obtain, according to the Applicable Laws, and from the data controller: Access to their data (A data subject can make a request to be informed about the type of personal data and how it’s processed). - Rectification and Deletion (A data subject has the right to ask for rectification of inaccurate data processed and request for deletion of their data), and - Objection (a data subject has the right to object to the processing of their personal Data for serious and legitimate reasons). 

Security screening 

Does Enreach Campaigns conduct a pre-employment screening performed on all candidates before employment?

Terms and conditions 

Do employees of Enreach Campaigns and its subcontractors agree to and sign the terms and conditions of their contract, including a Non-Disclosure Agreement (NDA), which shall state their and the organisation’s responsibilities for information security during and after employment?

Information during employment 

Are all personnel of Enreach Campaigns informed about the roles and responsibilities regarding security? Any changes in roles or responsibilities shall be made known to all personnel where relevant. 

Awareness and education 

Does Enreach Campaigns have an awareness program for security established? All personnel shall undergo the awareness program every 3rdyear (at least), as relevant for their job functions. 

Process for termination or change 

Does Enreach Campaigns have a procedure for change and termination of employment that details the security related responsibilities, and is the process communicated?

The information security committee has defined procedures for information security incidents and events, which are embedded in Enreach Campaigns and which the management is responsible for being observed.

We define information security incidents as:

• The detection of successful external and unwanted intrusion in systems
• Finding customer data (hosted in the master database for Outbound by Enreach and Flows by Enreach) online, where there is an obvious or strong suspicion that the publication of data has not occurred with the customer’s approval and intent
• Finding data on current or former employees in Enreach Campaigns online, where publication of data has occurred without Enreach Campaigns’ involvement or intent
• Finding other confidential business data online (according to the same directions) defined as customer contracts, revenue, or information which is classified as secret according to further definition by the information security committee.

We define information security events as:

• Events that, if they had not been discovered, could have led to security incidents
• Situations where unintended data or information by accident (due to human error) has been sent to other recipients than the intended, and that it is assessed that this may entail damage or serious consequences for Enreach Campaigns. 

Procedures have been defined for both, which describe for employees and managers how they should act in case of incidents and events, including (but not limited to) gathering evidence and contact with authorities, if necessary. All employees are aware of the instructions and have trained them. 

Yes – IT DR and BCP Plans exist and outline RTO and RPO. This is assured through Enreach Campaigns' ISMS (Information Security Management System) based on ISO27001.

The ISMS consists of policies, procedures and controls. We are subject to annual audit on this and obtain audit reports based on the ISAE 3000 and ISAE 3402 standards. 

Documented operating procedures for security incident management 

Does Enreach Campaigns have a documented process for security incident management, including defined roles and responsibilities as well as procedures for detection and recording, classification, escalation, resolution and reporting?

Notification of breach 

Will Enreach Campaigns without undue delay report all security incidents to the data controller according to defined reporting routines?  

Reporting of weaknesses 

Will all relevant identified security weaknesses be registered and reported to the data controller according to defined reporting routines?

Documenting lessons learned 

Will knowledge gained from solving security incidents be analysed and documented to reduce the likelihood or impact of future incidents?

Annual summary of analysed incidents 

Can an annual summary of analysed incidents and the lessons learned be made available to the data controller upon request? 

Servers are only placed in data centres provided by suppliers who have been issued, and annually can show, assurance reports at the level of ISAE 3402.

Enreach Campaigns office premises are subject to a number of procedures that secure the office as well as material and units stored at the office, regardless of servers only being placed in data centres. 

This entails, e.g., procedures aimed at employees describing security measures for offices, common areas, and similar areas. Physical locations are listed at our website: GDPR. In addition to these are Enreach Campaigns office locations in Denmark and Sweden. 

Services are hardened, patched and protected.

Only the base of each system is installed, and any services included in base that is not needed are disabled (eg. SMTP services). All systems are patched with security updates daily, if any.

Firewalls are running on each host only allowing the necessary services to communicate on affected ports and only on a dedicated VLAN. No systems are directly reachable over WAN, central firewalls controls access to any backend service. 

We have operating procedures for the IT department’s most significant duties, and these procedures are subject to versioning and change management. We have defined the responsibility for ensuring that an assessment of the capacity requirements for critical IT systems is performed regularly.

Due to our size we cannot have a complete overlap on all functions, but as to the previous description we aim, by virtue of segregation of duties and thorough as well as continuous documentation and knowledge sharing, to avoid dependence on individuals.

The IT department consists primarily of developers in a “devops” constellation, where two persons are dedicated to operations, optimising servers and infrastructure, monitoring and handling operational issues, but where all have operations as the first priority in case of technical issues on the platform or information security issues.

All instances of Outbound by Enreach and Flows by Enreach are monitored by means of monitoring tools. Thereby we monitor, among other things, access to servers, CPU/memory/disk usage, similar for database servers, lag (in milliseconds) between master and slave databases, heavy SQL queries made by applications or directly by a client, and much more.

Critical levels and values are defined for all these monitoring areas. Alarms must trigger when these values are reached and must be sent to key employees either via email (for less critical alerts) or SMS (critical alerts). Historical logs and events are regularly reviewed in a structured manner to perform improvements and optimisation.

We have procedures for backup besides continuous data replication, and the usability of backups for restore is regularly checked. The development of Outbound by Enreach and Flows by Enreach, including release of changes, occurs according to Enreach Campaigns’ formalised and embedded development model. The development process is Enreach Campaigns own method derived from an agile approach to development, SCRUM, and RUP. The development takes place in sprints, but not of an eternal, specified duration, as sprints are defined according to prioritised tasks in backlog. On the basis of the classic project triangle consisting of time, scope, and resources, time is the factor that defines the objective for master releases with a release at least every 4 weeks, but we aim to make a master release every 3 weeks. Quality and marking tests as complete, however, are always to be considered more important than the desire of making more frequent releases, as a zero-bug tolerance when new code is deployed for production overrides the desire of having new functions/features released quickly to customers.

Next to master releases, hot fix releases are performed with corrections of distinct errors and significant inexpediencies. Significant errors and disclosed security weaknesses with the priority of 1 or 2 (as per the Enreach Campaigns operations procedure) must always be handled as quickly as possible, and no later than within 3 working days. Development occurs in development environments where code is branched from the main branch/”default”. These development branches are connected with the staging database, where test data is found. Test data and production data are thus completely segregated, and customers’ data must not be copied from master to staging without approval from Enreach Campaigns' head of Operations and head of Development. If this permission is granted, it can and will only comprise configuration data in order to test and develop up against true, complex data in order to ensure the quality of the development, but it must and can never comprise data on the customer’s prospects, employees or similar which are personally identifiable and can be categorised in accordance with GDPR’s articles 6, 9, and 10.

Function testing takes place in development branches (also called feature branches), after which code is merged to pre-production, on to CX branch, on to pre-release branch, on to release branch, from which code is finally deployed for production.

Integration testing with associated regression tests and happy flow testing takes place from CX branch, pre-release branch and/or release branch, where testing occurs in the master database, but on our own test data. Customers’ personally identifiable data are thus not part of tests and are not accessed or viewed by Enreach Campaigns employees in any of these test phases. Data in the master database on own accounts are created in such a way that it structurally looks like production data that customers work with, whereby data security, confidential processing, and simultaneous quality assurance are ensured and balanced.

We have procedures concerning the scope, processing, protection, and check of logging on various system types. All logins and significant user actions in Outbound by Enreach and Flows by Enreach are monitored and logged. The logging of significant user actions concerns i.e. data export, such that customer administrators have an overview over which users that access and export data.

All changes to data are registered. All significant changes to configurations are registered. These registrations are also available for customer administrators through visible logs in the user interface.The logging level also comprises employees at Enreach Campaigns, whereby it is checked that these do not access customer data without a work-related need for this. This is checked and tested in a detailed manner on the basis of spot checks.

All instances of Outbound by Enreach and Flows by Enreach are monitored by means of monitoring tools. Thereby we monitor, among other things, access to servers, CPU/memory/disk usage, similar for database servers, lag (in milliseconds) between master and slave databases, heavy SQL queries made by applications or directly by a client, and much more.

Critical levels and values are defined for all these monitoring areas. Alarms must trigger when these values are reached and must be sent to key employees either via email (for less critical alerts) or SMS (critical alerts). Historical logs and events are regularly reviewed in a structured manner to perform improvements and optimisation. We have procedures for backup besides continuous data replication, and the usability of backups for restore is regularly checked. 

We have procedures for network management and monitoring, including maintenance of network and network equipment. Traffic on all connections and interfaces are monitored in relation to data volume over periods of time. Alarms have been set up that are triggered and sent to technical personnel in case of abnormalities (traffic spikes, significant delays between master databases and slave databases, and much else).

Regarding tele connections, the amount of provider channels, the amount of server channels (Freeswitch channels), and amount of ongoing calls, amongst other things, are monitored, and max values for periods of time are logged. This ensures ongoing, correct capacity management as well as a precaution against misuse. In addition, as an extra layer of security against misuse we cooperate with fraud detection departments at all telecom operators that we use as sub-suppliers.

Exchange of information solely occurs by means of secure connections. If this occurs via the public Internet, data is encrypted (in principle by means of HTTPS). Systems that can communicate on internal connections (on internal IP address behind firewall – and between data centres via fibre connection, through which servers on various locations also can reach each other on internal IP address) use this method for data exchange via LAN. 

How does the supplier ensure that operating procedures are documented and maintained, and do these include the following?:

• Malware protection 
• Change management 
• Capacity management 
• Environmental separation.

How has the supplier implemented security measures in relation to the following:

• Malware protection
• Backup 
• Logging and monitoring
• control of operating software Management of technical vulnerability managers.

Documentation of changes 

Are all changes to the production environment, including the underlying infrastructure, documented according to formal change management procedures? The documentation shall cover all the steps performed as part of the change management procedure, including test results, approvals and decisions. 

Changes in production environment 

Does Enreach Campaigns have a policy in which changes in the production environment shall only permitted by authorised personnel in accordance with the change management procedure?

Division of environments 

Are development, testing and production environment separated from each other?

Installation of changes in production environment 

Does Enreach Campaigns have a policy in which developers shall not be able to apply their own changes in the production environment? Before promoting a change to the production environment it shall be tested, approved and validated. 

Malware protection 

Do all systems and assets shall have malware protection (e.g. web content filtering, mail protection, antivirus, firewall)? The malware protection shall update signatures on a continuous basis. 

Backup 

Does Enreach Campaigns ensure adequate backups of system images, software, and information, and performs annual tests of these? The test results shall be documented.

Backup Security 

Does the backup of information have a level of physical, logical and environmental protection equivalent to that of the main site? The controls applied to storage media at the main site shall be extended to cover the backup site. 

Logging of events 

Does Enreach Campaigns maintain security and event logs, with establish procedures and capacity for event monitoring. 

Access to logs 

Is it possible to, upon request, obtain access to log files and to transfer logs to the data controller? 

Protection of log information 

Are logs protected against tampering, overwriting, and unauthorised access?

Procedures for installation of new software 

Does Enreach Campaigns have documented procedures for installation of new software and new versions of existing software in any production environment? 

Procedures for managing technical vulnerabilities 

Does Enreach Campaigns have a documented process for managing technical vulnerabilities?

Patching 

Are patches tested and evaluated before they are installed to ensure they are effective and do not result in side effects? If no patch is available or if patching is not possible, compensating controls shall be considered. 

System hardening 

Does Enreach Campaigns have a documented procedure for equipment and system hardening? The procedure shall define roles and responsibilities as well as specific instructions for hardening of operating systems, databases, applications, network components and virtual environments. 

The service provided is a telemarketing system, for sales to contact existing and potential customers. Enreach Campaigns does not manage any data or information for customers.

All data and information in the system is uploaded and managed by the customer.

Enreach Campaigns is a data processor acting on instructions provided by the customer as a data controller only. Our services are co-located across Danish data centers and AWS in Dublin and Frankfurt. 

Following Enreach Campaigns’ choice of Frankfurt and Dublin, the hosted data is not being transferred to outside EU. Enreach Campaigns has obtained written confirmation from AWS that this is the case.

Physical servers are hosted in our racks in data centers in Denmark, and virtual servers are hosted in the AWS data centers in Frankfurt, Germany, and Dublin, Ireland.

Production data is hosted in EU-based data centers only, and the hosted data is not being transferred to outside EU.

The overall architecture and security setup is illustrated on our website: GDPR. No 3rd parties have access to any information. The sub data processors used are for hosting and housing only, and these 3rd parties do not have access to data. Data is encrypted during rest and transit, and further and full information is available in the audit reports (based on ISAE3402 and ISAE3000) which can be found at our website: GDPR.

Risk management in Enreach Campaign’s A/S is done for all areas connected with delivering the product and serviceEnreach Campaigns. Risk analysis, assessment, and management are based on ISO 27005, and are based on impact analyses and vulnerability analyses at service level. Service is understood as business systems supporting the delivery of Enreach Campaigns as well as Enreach Campaigns in itself as a customer system.

Above all is our top-level information security policy, which is signed by Enreach Campaigns’ CEO and which sets the framework for the information security work. This is valid for all employees and close cooperative partners (such as consultants).

The framework for the information security code of practice is ISO 27001, and the code of practice is classified according to the following control areas:

• Information security management and security policy
• Organisation of information security
• Human resource security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
• Compliance.

The framework for the information security code of practice is ISO 27001, and the code of practice is classified according to the following control areas:

• Information security management and security policy
• Organisation of information security
• Human resource security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
• Compliance.

This includes, but is not limited to the following:

Segregation of duties - We have a clear and well-defined organisation with segregation of duties, which entails that dependency on key persons is reduced as much as possible. In addition, segregation of duties has been introduced to areas where there is a risk of the occurrence of misuse of the company’s data and information.

Contact with authorities - We have defined responsibility for contact with public authorities regarding topics pertaining to the area of information security.

Project management - We have defined the responsibility for Enreach Campaigns’ project management model managing information security in all phases in an adequate manner, such that projects do not impact Enreach Campaigns’ overall risk exposure to a negative degree. Information security is considered in all projects, regardless of their size. 

1. Yes

2. Partially. All actions on our platform are logged, but for overview and simplicity purposes, not all data is made available to users in the GUI. Hence, depending on the level of request, the customer may need to reach out to Enreach Campaigns support team for further/full details, but in that case, it can be provided upon request. 

Yes, this is secured at data processor (audited by IT auditor).

System accesses are revalued and checked every 3 months cf. ISMS. Data processor has ongoing controls that check and ensure conformity between employees' access to data and instructions from the customer.

Documented framework for security & resilience 

Does Enreach Campaigns have a documented security framework (ISMS), including a security policy that is approved by management, published and communicated to all employees and relevant external parties?

Documentation of security roles and responsibilities 

Have all security roles and responsibilities been defined, documented and allocated within Enreach Campaigns? Has Enreach Campaigns appointed a person responsible for security with the services delivered to the data controller in scope?

Segregation of duties 

Have conflicting roles and responsibilities been segregated to reduce risk for unauthorised or unintentional modification or misuse of the data controller's assets?

Security in project management 

Is security addressed in all stages of project management, regardless of the type of project? Are all projects staffed with sufficient security resources to implement appropriate information security controls and meet the security objectives?

Mobile device policy 

Are security measures for the use of mobile devices in Enreach Campaigns defined, documented and implemented?

We have procedures that ensure secure change management in business supporting systems.

The procedures prescribe that change logs are obtained and evaluated, and that changes are tested before they are released. As all significant internal work processes are documented, the process documentation is updated where necessary, in connection with changes. 

The development of Outbound by Enreach and Flows by Enreach, including release of changes, occurs according to Enreach Campaigns’ formalised and embedded development model.

The development process is Enreach Campaigns’ own method derived from an agile approach to development, SCRUM, and RUP. The development takes place in sprints, but not of an eternal, specified duration, as sprints are defined according to prioritised tasks in backlog. 

On the basis of the classic project triangle consisting of time, scope, and resources, time is the factor that defines the objective for master releases with a release at least every 4 weeks, but we aim to make a master release every 3 weeks. Quality and marking tests as complete, however, are always to be considered more important than the desire of making more frequent releases, as a zero-bug tolerance when new code is deployed for production overrides the desire of having new functions/features released quickly to customers.

Next to master releases, hot fix releases are performed with corrections of distinct errors and significant inexpediencies. Significant errors and disclosed security weaknesses with the priority of 1 or 2 (cf. Enreach Campaigns operations procedure) must always be handled as quickly as possible, and no later than within 3 working days.

Development occurs in development environments where code is branched from the main branch/”default”. These development branches are connected with the staging database, where test data is found.

Test data and production data are thus completely segregated, and customers’ data must not be copied from master to staging without approval from Enreach Campaigns’ Head of Development and Head of Operations. If this permission is granted, it can and will only comprise configuration data in order to test and develop up against true, complex data in order to ensure the quality of the development, but it must and can never comprise data on the customer’s prospects, employees or similar which are personally identifiable and can be categorised in accordance with GDPR’s articles 6, 9, and 10.

Function testing takes place in development branches (also called feature branches), after which code is merged to pre-production, on to CX branch, on to pre-release branch, on to release branch, from which code is finally deployed for production.Integration testing with associated regression tests and happy flow testing takes place from CX branch, pre-release branch and/or release branch, where testing occurs in the master database, but on our own test data. Customers’ personally identifiable data are thus not part of tests and are not accessed or viewed by Enreach Campaigns employees in any of these test phases. Data in the master database on own accounts are created in such a way that it structurally looks like production data that customers work with, whereby data security, confidential processing, and simultaneous quality assurance are ensured and balanced. 

Security requirements for systems 

Are security requirements for new systems or enhancements established and approved before development is initiated?  

Security & privacy by design 

Are security and privacy requirements integrated in the design of information systems?

Secure development policy 

Is development performed according to a documented procedure for secure development?

Secure architecture 

Are secure architecture principles established, documented, maintained and applied in all architecture layers?

Secure development environment 

Are development, test, acceptance and training environments appropriately protected and secured, similar to the corresponding production environment? 

System security testing 

Within every development cycle, do the developed systems or programs undergo security reviewing or testing before they are put into production? 

Acceptance testing 

Does Enreach Campaigns have a policy in that in order to verify that systems comply with information security requirements, the technical solution, the documentation and the associated procedures shall be reviewed according to a documented procedure? The review shall include formal acceptance testing and the result shall be documented. 

Protection of test data 

Is test data classified (based to sensitivity) and handled according to documented procedures that include requirements on isolated test environments and procedures for removal of test data after completion?

Use of test data

Does Enreach Campaigns have a policy in which the data controllers' data shall not be used for testing, unless explicitly approved by the data controller? In which case all requirements and conditions expressed by the data controller on such testing as well as relevant requirements provided must be fulfilled.

Access control policy 

Does Enreach Campaigns have an updated and documented access control policy applicable for the asset(s) in scope of the service delivered to the data controller, including assignment of business roles to system roles as well as a description of how access rights are managed?

Formal policy on the use of network services 

Is access to networks and network services restricted in accordance with the access control policy?

Least privilege principle 

Does the provision of access to information follow the principle of least privileges, i.e. users and system components only possess the minimal privileges and access rights they need in order to fulfil their defined function?

Change of default passwords 

Are default passwords to networks and network services changed before any users are allowed to connect to them?

Process for unauthorised devices 

Is a documented description regarding how to identify and handle devices that have been connected without approval established, and are such unauthorised devices automatically identified?

Unique user ID's 

Do employees of Enreach Campaigns have a unique user account (ID), and shared IDs (function or service user accounts) only allowed when unique user accounts cannot be used for business or operational reasons? Exceptions shall be managed, documented and approved. 

User access provisioning 

Does Enreach Campaigns have a documented access provisioning process, including a description of how access rights are granted and revoked?

Authorisation of privileged access rights 

Are privileged user access rights restricted and kept to a minimum? Is there a formal process for management approval of privileged access rights before activation?

Separation of privileged access rights 

Are administrative accounts separated from regular accounts?

Verification of privileged access rights 

Are high privileged user accounts verified every 6th month according to a formal process?

Logging of privileged user account activity 

Are activities performed with high privileges logged and traceable?

Management of secret authentication information of users 

Is secret authentication information (e.g. password) protected with controls (i.e. using salted hashes for storing passwords, strong encryption or similar measures) to ensure confidentiality?

Distribution of passwords 

When distributing new passwords to a user, is the identity of the user established, according to a documented procedure, before the password is distributed? Is the password unique and a password change mandatory at the first login?

Annual review of user access rights 

Are user accounts reviewed annually according to a formal process, and is the review documented? 

Removal or adjustment of access rights 

Are access rights of all employees and external users to information and information processing facilities disabled upon termination of their employment, contractor agreement, or adjusted upon change? Users shall not automatically regain old access rights upon account reactivation.  

Failed Logon 

Are accounts disabled/locked for a specified period of time after repeated unsuccessful login attempts? 

Logon security 

Does Enreach Campaigns have a policy wherein passwords shall not be transmitted in clear text over the network? Furthermore passwords shall not be distributed together with the account information in the same delivery. 

Password minimum requirements 

Are minimum requirements for authentication defined, approved and implemented?

For general app and data access, the following applies.

The customer itself controls what data to upload and how long time to store data for. The service needs, as a minimum, just telephone number to be able to dispatch outbound calls. Other data can be uploaded as the customer needs and wants (all done by the customer itself). Data is deleted from Outbound by Enreach according to deletion rules set up/configured by the customer itself.

For the service provider’s (Enreach’s) ability to access, the following applies, also in line with Detail Provider employee access controls (Read more under Provider Design and Isolation).

Staff at the provider of Outbound/Flows by Enreach are generally restricted access to systems and services, following the least and minimum access principle. See the audit reports (latest ISAE3402 audit report published on our website: Audits. Nobody outside the core IT Architectural Team have OS access. The commercial Support department can, upon permission granted by the customer itself, access the customer’s app account for service purposes.

Requirements on physical protection 

Does Enreach Campaigns have defined and documented requirements for physical perimeter protection to areas that contain systems and/or process information of data controllers? The level of physical protection shall be based on the classification of the system and/or information processed at the premises. The requirements shall include specifications for mechanical protection, technical protection and surveillance. The specification shall at least include requirements on doors, locks, alarms, windows, walls, ceiling and floor. 

Physical access provisioning 

Has Enreach Campaigns implemented physical entry controls for offices, production sites, data centres and any other locations?

Secure storage of physical access 

Are physical keys and cards as well as codes that grant access to physical areas stored in a manner that prevents unauthorised persons from gaining access? Theft, loss or misuse of keys, cards or codes shall be managed as a security incident. 

Identification of visitors 

Does Enreach Campaigns have a procedure for managing visitors access to the physical premises? 

Protection against natural disasters and accidents 

Does Enreach Campaigns have a defined and documented procedure for physical protection related to management of natural disasters and accidents? The level of physical protection shall be based on the classification of the information processed at the premises and a risk assessment covering the likelihood and impact of natural disasters and accidents 

Environmental conditions in the server room  

Are environmental conditions in the data centre adequately protected, monitored and regularly inspected?  

Clear desk policy 

Does Enreach Campaigns have a clean desk policy implemented for all information processing facilities? The policy shall at least cover handling of papers and removable storage media. 

Requirements for network security 

Are security mechanisms, service levels and management requirements of all network services identified and included in network service agreements, whether these services are provided in-house or outsourced?

Network segmentation 

Does Enreach Campaigns have a documented zone model (model for physical and logical segmentation of networks) containing security requirements for handling of information within network zones as well as regarding transfer between zones?

Agreements on information transfer 

Does Enreach Campaigns have a policy in which secure information exchange procedures are agreed upon between the data controller and the supplier before any information exchange takes place? The procedures shall include the signing of a non-disclosure agreement (NDA) and formal approval from both parties before information exchange is initiated. 

Secured electronic messaging 

Is all information involved in electronic messaging appropriately protected (e.g. from unauthorised disclosure, unauthorised alteration, unauthorised message duplication, unauthorised destruction etc.)? The usage of electronic messaging platforms shall be properly protected.  

Use of sub-contractors 

When contracting sub-providers, does Enreach Campaigns ensure that the security controls agreed with the data controller are propagated throughout the supply chain? If the supplier sub-contracts parts of the service delivery under the agreement, all Security Controls agreed with the data controller shall be included and agreed with the subcontractor. The agreement with the sub-contractor shall be signed before the subcontractor or any of its personnel can access the data controller's systems and/or information. 

Right to audit 

Does the data controller have the right to audit Enreach Campaigns in respect to the agreed requirements and delivered service? The data controller shall have the right to assign an independent third party auditor for this, or Enreach Campaigns shall provide third party audit report covering the services delivered to the data controller in scope.

Changes to supplier services 

Will Enreach Campaigns inform the data controller's contract owner without undue delay of all changes that may influence the fulfilment of the information security controls agreed upon within the services delivered?

Yes, full compliance assured and audited within.

See latest ISAE3000 (scope: GDPR) report on our website: Audits.

Data replicated to slave instances in real time. Databases separates across different availability zones on the AWS sites. Failover servers in place for all production servers, with automated failover for most assets managed by KeepAlived. See further info about the platform, security, compliance and related topics on our as well as in the latest ISAE3402 audit report: Audit.

HA and failover is managed and assured by the service (Outbound by Enreach). Thecustomer is not involved in failover scenarios and/or recovery scenarios.

How is resource isolation identified?

• Single-tenant dedicated PHYSICAL
• Single-tenant dedicated LOGICAL (e.g. Multi-tenant on shared physical)
• Multi-tenant shared LOGICAL resources (e.g. app instance handles many customers, only the app has to be exploited to see across data)

How does the detail Provider employee access controls work?

• Physical and logical (e.g. can they login to our OS or app instance?)