Vecos Information Security Policy

1. Introduction

  • Purpose

Vecos Europe B.V. (Vecos) delivers innovative locker management systems consisting of electronic locks with related accessories and software. Since mid-2016, the software Releezme is also available in a Software as a Service version (SaaS). This, as well as the implementation of the new General Data Protection Regulation (GDPR) in 2018, has led to a further description of the existing software and IT processes and which descriptions were then included in this information security policy.

For clients of Vecos, the GDPR has led to new and stricter regulations with respect to privacy and information security. They are required to maintain a register of processing operations, need to ensure proportional collecting of personal data and to do so only and exclusively in accordance with the purpose for which the personal data are processed. In addition, they need to assess whether suppliers have taken appropriate technical and organisational measures to secure their personal data.

Vecos realises that the processing of personal data and the delivery of services to multinationals, schools, hospitals and other organisations that process personal data are inextricably linked. It brings with it a responsibility. This document provides insight into the manner in which Vecos has organised her information security policy. For the sake of completeness: Vecos’ clients are themselves responsible for the appropriate purpose for the processing of user data and to meet the other requirements which apply to her as controller. Also, they are to provide the functional management and 1st line support themselves. The processing of personal data by Vecos in relation to providing her services will only take place under a GDPR compliant Data Processing Agreement.

When drawing up this information security policy, the following was taken into account:

  • The size of the SME organisation Vecos and the enforceability the policy should have;
  • The low-risk classification of the personal data that are processed;
  • The nature and (limited) extent of the services provided by Vecos and the limited impact this has on the

client’s overall services;

  • Legislation and regulations;
  • Input from

The privacy and security domain is subject to change. To maintain compliance with changing legislation and regulations, but also to process new insights, this information policy is reviewed, and updated where needed, at least once a year.

This document can also be shared with prospects and clients, allowing them to ascertain that, when they contract Vecos, they are appealing to a processor that offers adequate guarantees with respect to the application of appropriate technical and organisational measures, so that the processing of personal data meets the requirements of the General Data Protection Regulation and the protection of the rights of those involved can be guaranteed by the client. Vecos welcomes feedback in order to continuously improve and professionalise.

  • Structure

The structure of this document is as follows:

  • Chapter 2: Technical Measures Releezme Software
  • Chapter 3: Privacy
  • Chapter 4: Organisational measures for the R&D team
  • Chapter 5: Service Desk and Project Implementation
  • Chapter 6: Other issues, such as IT, Human Resources and Contract Management
  • Appendix containing an overview of the roles and the associated employees
  • Process approach

Vecos is a high tech SME enterprise with a focus on serving clients by delivering innovative locker concepts. Processes and structure are important in the execution of the work and in this Vecos has achieved a balance in order to keep the organisation scalable, lean and manageable in a competitive market.

The process approach is about the following:

Vecos employs highly qualified professionals, who are experienced in working in self-managing teams, who need autonomy and want to carry out their tasks in a professional manner. Based on that, the structure of the processes has been addressed:

  • There is a clear framework which contains the intention ‘what’ we want to achieve;
  • Where the ‘how’ is relevant to the quality of the execution, this is
  • Version management
  • – 13 July 2017  First version
  • – 14 August 2017 Textual amendment

(Duplicate paragraph removed)

  • – 29 December 2017 Policy completed
  • – 18 January 2018  Review by the board for release

3.3   –  15 January 2019 Extensive adjustments

The board of Vecos sees to it that this is a ‘living’ document, that employees and externals are informed of this policy and that the promised improvements are executed. This policy is not owned by one person. It is by Vecos and by the Vecos team.

2. Technical measures

  • Introduction

This chapter describes the technical measures taken and the provisions made by Vecos for the Software as a Service version of Releezme. It is also possible to install Releezme on-premises, in which case the infrastructural measures as described will need to be implemented by the client.

The illustration above shows the architecture of Releezme. For the client it consists of the following elements:

  • Locker Bank Controller (LBC): a user interface terminal to manage the physical lockers. The LBC usually has a card reader and the terminal’s touchscreen supports the requesting, opening and releasing of the locker of an end
  • The LBC connects the physical locks and hubs by means of a serial RS-485 The wiring needs to be built in properly by the installer of the lockers. A client usually has multiple LBCs and each LBC communicates with the Releezme software via a TCP/IP connection.
  • The purpose of the Releezme website is to allow software configurations, create interfaces and generate reports. In addition, there is an app available to end users and there are provisions to allow working via an Application Programming Interface (API). Availability of these features depends on the client’s
  • The technical components, which together form the Releezme SaaS service. These components are logically separated, aimed at scalability and set up under modern

In the software various technical measures were taken, such as:

  • Encryption of the communication between the ‘locker bank controllers’ and the platform, as well as the communication between the website/APIs (HTTPS EV SSL/TLS 1.2) and the platform. The data are encrypted using the AES 256
  • In the SaaS environment, the databases are physically stored on a storage medium on which Transparent Data Encryption is active. This ensures that all data are encrypted when
  • Controlled access to the configuration website and report based on an extensive rights/roles
  • Strong password policy (minimum of 8 characters, including 1 normal character / 1 special character and 1 uppercase letter) and the option of Single Sign-On. Company users have to reset their password at least every 90 days. This period is adjustable per client and can be reduced to a shorter period, with a minimum of 1 day. Releezme system managers have to change their password every 30 days. Releezme has no insight into the users’ passwords. The passwords are stored as hash on the basis of PBKDF2 with HMAC-SHA2, 128-bit salt, 256-bit subkey and 10,000 iterations. Single Sign-On only functions with valid SSL/TLS certificates on both the Releezme and the client end of the
  • The maximum duration of a login session is 4 hours. After 30 minutes of inactivity, the user is automatically logged off. Cookies are always encrypted when saved and always use the HttpOnly
  • Separated environments for development, testing, acceptance and production. Access to these environments and related management portals is limited via IP
  • The hosting takes place with Microsoft Azure. For European clients the data centre in region West Europe is
  • When using the mobile app there is the option to use a PIN
  • Clients can opt for the use of IP
  • SaaS: Backups of the data are automatically executed in Azure and allow a “point-in-time” recovery. Backups remain available for 35 days and are geographically
  • Microsoft Azure

Vecos has chosen to make use of Microsoft Azure as a ‘Platform as a Service’ (PaaS). Azure is an open and flexible platform which offers all the building blocks to develop, implement and manage cloud-based solutions. In choosing Microsoft Azure, the following considerations were important to Vecos:

  • By using a PaaS platform, the complete infrastructure, hosting of the physical and virtual servers,

security of the data centre and the platform’s basic safety are provided by Microsoft’s specialists.

  • Microsoft meets the European laws and regulations with respect to
  • Microsoft Azure has relevant certification with respect to information security: ISO27001, SOC 1 and SOC
  • The infrastructure’s high proven availability and possibilities to upscale fast when the situation requires this.
  • Personal data

Personal information (personal data) is used to identify the person using the locker(s), to establish access rights, and to verify compliance with the predefined company rules. Occasionally and on a “need to know” basis, Vecos employees have access to these data to enable them to provide support to the client. They have been screened and work on the basis of a clear privacy policy (this document and the Personal Data Procession policy. Also, they have at least fundamental knowledge of privacy, which allows them to understand the importance of privacy and security to both Vecos and the client.

Vecos processes the personal data in order to be able to offer the Releezme service:

  • Minimum: The user’s card number when card identification is
  • Optional: The locker user’s name to allow for user identification by
  • Optional: The locker user’s email address to be able to send email messages for the ‘anti-claiming’

functionality, among other.

  • Optional: Assigned Releezme identification code of the locker user’s phone when the Releezme mobile

app is used.

  • Required: Client-specific identification of a user when using the automatic import
  • These data are exchanged with Vecos by means of an interface, a one-time import or are input manually. When using an interface, the user information in the system can be kept up to date without manual processing.

When using Releezme, the following data are created:

  • Number of lockers and which lockers (including their location) are in
  • Opening/closing of the
  • Requesting/releasing of the
  • Administrative actions related to the locker by, for instance, the facility manager or service desk operator of Vecos
  • Per action: date/time.

Both these data and the personal data can be monitored by the client by means of the configuration website and/or generated reports.

In compliance with company and national policy, Releezme offers every company the option of customised data retention. Data, such as logged events, can be configured in such a way that they are deleted after for instance 90 days.

  • Development environments and data storage Releezme uses the PaaS platform Microsoft

The R&D team maintains several separate environments within Azure for development, testing, acceptance and production (DTAP street). The R&D team has their own development environment on their own laptops. An additional acceptance environment has been created for pen tests and third-party acceptance tests.

Test environment:

  • Contains development version with the latest state of affairs. Some features may be present only in part. Detailed logging is switched
  • This environment is only used by the R&D
  • There are no client data in this

Acceptance environment:

  • The same software as in the production environment, but with more detailed logging. The new version is installed here to conduct acceptance tests on that version prior to a production release. This environment is representative of the production environment, but does not meet Vecos’ SLA: various components run on a lower capacity
  • This environment is used when a pen test is executed under the direction of
  • There are no client data in this

Acceptance environment for third parties:

  • This environment is used for the development of external APIs or interfaces with partners/suppliers.
  • The software is similar to that of the Test or Acceptance Some infrastructure modules are shared between the Test and Acceptance environment (for instance email / caching or the service bus).

Production environment (Europe and Australia):

  • A production environment contains the executable code and additional supporting data (for instance

images) which are necessary for the product’s functioning.

  • Always contains a production release that is completely

The production environment’s databases are duplicated in physically different locations, as indicated below:

Azure Region Purpose
West Europe Production Europe
Australia East Production Australia and New Zealand
North Europe Database Fail-over/Backup Europe
Australia Southeast Database Fail-over/Backup Australia and New Zealand

 

If a client uses an import mechanism to keep the locker users in Releezme up to date using her own system, it is possible that an application with database will run on a client’s server. This application with a database falls under the client’s management and contains personal data as indicated in paragraph 2.4.

  • Web services

The Releezme web services (the configuration website and APIs) follow the following security rules:

  • All communication with and between web services is coded with a good, according to OWASP guidelines, configured TLS
  • TLS is used to verify the server on the service-client end. In other words, the service-client verifies whether the server certificate is provided by a trusted provider, has not expired, has not been revoked and matches the service’s domain
  • Releezme uses an official certificate of 2048 bits minimum with SHA256 and
  • All web services have “HTTP Strict Transport Security”.
  • Azure-hosted web services use the encryption algorithms as offered by the underlying Windows OS (Azure).
  • Users and service-client systems (with server-to-server communication) always need to identify themselves by means of a user verification process before obtaining access to the
  • Web services must use OAuth 2 for authentication, except:
    • Services which do not use system users for user access. This includes the Mobile interface (mobile devices) and the Reporting
    • The Mobile interface uses a set verification mechanism based on the unique device
    • Reporting API: this makes use of “basic authentication” to be able to support older versions of

Excel (PowerQuery), such as 2010 and 2013.

  • The Releezme website makes use of a typical username/password
  • Web services ensure that web service clients only have access to authorised data; where possible the

“role-based access control” mechanism is used, as is used in the website.

  • Exceptions: the import API and mobile API are limited by means of the functionality that they offer instead of the use of “role based access control”, since both only offer 1
  • All HTTP requests are automatically redirected to
  • LBC Communication Service

The connection between the LBC and the LBC Communication Service from the architecture overview (2.2) uses AES 256 encryption of the exchanged data combined with a Releezme-specific application protocol.

  • Access control

Releezme has two types of users which are kept strictly separated:

  • Locker users: these are users who obtain access to a locker, which is managed by Releezme, via a badge and/or smartphone app. These users do not have access to the Releezme system and the related websites/services.
  • System users: these are users who have access to the Releezme (configuration) system and the related website/services via a username/password. These users can – depending on their role/rights – change the configuration and generate

A system user has one of the following roles:

User Access Services Add new users Username/

Password

Operational manager All clients Website All types Yes
Client manager Vecos Website All types Yes
Company administrator 1 client Website Facility manager Service desk(+) Yes
Facility manager+ 1 client Website Facility manager

Service desk(+)

Yes
Facility manager 1 client Website Service desk(+) Yes
Service desk/ Service desk+ 1 client Website Yes

 

A further explanation of the roles can be found in the document ‘Releezme Explained’.

For system users, access to the Releezme system is organised with a username and password. With that the following is registered:

  • First name and last name
  • Email address, which also serves as the username and has to be confirmed prior to use
  • Phone number

The above-mentioned personal data are processed for the purpose of identification and communication.

Releezme makes use of “Role Based Access Control”, where roles with associated rights are given to authorised system users. The types of roles are divided into two levels, namely “System management users” and “Company users”.

 

System management users have access to all companies in Releezme. This role is only made available to users for the purpose of:

  • Operational management: essential for the management of the functioning of
  • Client management: for the purpose of the management of the various clients and companies in Releezme, as well as for setting up new clients and/or making adjustments to existing client configurations.

Company users only have access to 1 company, which is assigned when the user is created. For this type of user there are the following roles:

  • Service desk: user with limited access to the company in
  • Facility manager: user with access to the extent required for facility management within the company in Releezme. This type of user can create service desk
  • Company administrator: user with access to all functionality within a company in Releezme. This user can create the facility manager and service desk

Note: Access to the underlying Microsoft Azure system is limited to the development team. Changes in the configuration are scheduled and executed according to the ‘four eyes principle’, meaning that another member of the development team observes and checks whether the correct actions are being executed.

  • Access control of locker users

Locker users are entered into the Releezme software. This can be done manually or via an (automatic) import. The client can manage this herself. Depending on the configuration, there are multiple methods to grant users access to lockers in a company:

  • Using a badge that is connected to a locker user in Releezme. Depending on the rights assigned to the locker users, they can use lockers with that badge. When permitted by the client, a locker user can connect the Releezme smartphone app to his badge via a procedure. The locker user can subsequently also use the
  • Using email addresses which are connected to a locker user in The user can then initiate the pairing procedure between the Releezme smartphone app and his email address.
  • Using the option of self-registration by a locker user. The user then follows a procedure on the locker bank controller or via his phone. This method can for instance be used for

Every locker user is part of one or more user groups. The user group is connected to one or more groups of lockers. Each locker group can contain its own configuration, such as the use of anti-claiming.

  • The Releezme app

Locker users use their own access card to request, open and release lockers. When the option is included in the order of Releezme, there is the additional option to make use of the lockers using the Releezme app. The Releezme app can be downloaded in the Apple Store or Google Play Store.

The app does not store personal data and is connected by means of a procedure on the locker bank controller and/or via an email address. The user follows a step-by-step procedure on the controller’s screen and (eventually) connects his access card to the app by means of an authentication code which is generated by the system. On the phone itself a unique identification code (GUID) is used and apart from the user’s lockers no personal data are processed; the latter takes place on the Releezme servers.

  • Performance and service continuity

Vecos has organised its business continuity in various ways. The locker bank controllers include precautionary measures, which enable lockers users or managers to open the lockers in the event that the internet connection or the Releezme software is not available. In addition, as an extra precaution, the following measures are taken.

For production environments a Microsoft-managed service with a 99,95% minimum SLA is used, instead of a by Vecos herself managed Virtual Machine in Azure. Therefore, keeping the underlying machines up-to-date and the ‘hardening’ of these machines fall under the responsibility of Microsoft.

The system performance is monitored by the R&D team during working hours (Monday to Friday from 08:30 to 17:00 CET, not including generally recognised Dutch public holidays). Alerts are set to warn the operational managers when predefined limits are exceeded. Azure offers possibilities to scale services. If necessary, services are upscaled.

The source code of the Releezme product is stored in Microsoft’s “Azure DevOps” service and is locally stored on the laptop of a software developer. Every night, a backup is made of the entire software archive to a local Vecos server.

The product manager guards the staffing levels and the competencies of the development team in order to be able to guarantee business continuity.

3. Privacy

  • Relevant framework

Vecos processes personal data as a (sub-)processor for her clients. The client can be considered the controller and is responsible for the correct purpose for the processing of the personal data, and, when applicable, the informing of those involved and all other obligations that apply to the controller. If the Software as a Service services are delivered via an authorised partner, Vecos usually is sub-processor and the partners can be considered the processors. The Dutch Personal Data Protection Act and the European General Data Protection Regulation are leading.

Via the parent company, Cerebel Group, Vecos has a Chief Information security Officer (CISO) at her disposal, whose purpose and responsibility is:

  • To advise, both on request and on his own initiative, about the implemented (development) policy in the context of the processing of personal data and the associated (software)
  • To assess the technical and organisational
  • To execute Privacy Impact
  • To execute a Privacy Awareness
  • To take charge in the event of a data leak or security
  • Privacy Awareness Program

At every Vecos employee meeting, the CISO updates the employees and informs them regarding relevant issues with respect to privacy. Employee meetings are typically held twice a year. If the CISO deems it necessary, a separate meeting will be scheduled. If relevant to the subject, those absent are registered, in order to be able to bring them up to speed at a later time.

  • Access to personal data and sub-processors

Vecos has an organisational structure in which access to the different Releezme environments is organised. Only the service desk and the R&D team have access to the client’s production environment. As indicated before, no personal data are processed in the other software environments. Access to the Releezme software via Vecos is logged and is available to the client.

Vecos uses the following sub-processors:

  • Microsoft Azure for the hosting of the
  • Sioux Embedded Systems B.V. (Esp 405, Eindhoven, the Netherlands) for the software development. The software developers have access to the production environment for the purpose of implementing changes, such as updates, and for 3rd line
  • MailJet for SMPT relay mail traffic
  • Data leaks or security incident

In the event of a data leak or security incident, Vecos will inform the relevant clients without unreasonable delay, but within 48 hours after Vecos has become aware of the Security breach. Vecos will deliver such a notification via email. The mandatory notification regarding personal data breaches as defined in the GDPR is therefore applied more broadly. Vecos believes it is important that clients are also informed of possible security incidents.

Such a notification contains a brief summary of:

  1. the incident and how the notification was realised,
  2. the probable impact on Vecos and the client,
  3. The measures taken or suggested by Vecos to resolve these consequences,
  4. As soon as Vecos becomes aware of a Security breach that involves Personal data, Vecos shall take all necessary and appropriate measures to repair or resolve all shortcomings in her security measures and shall take action in accordance with the agreements in the Data Processing Agreement.

Communication on this subject usually takes place via email. Vecos keeps a list of contact persons. At their request, these contact persons receive a current overview from Vecos regarding the technical and organisational measures and any possible particularities with respect to privacy and security which have taken place in the past 6 months or which are to take place .

  • Data retention

In line with company and national policy, Releezme offers every company the option of customised data retention. Data, such as logged events, can be configured in such a way that they are deleted after for instance 90 days.

Releezme applies the following data retention periods:

Description Adjustable Period
App registration codes Per client 1-90 days (default 30 days)
Event log Per client 1-90 days (default 90 days)
Import actions Per client 1-90 days (default 30 days)
Users pending deletion Per client 1-90 days (default 90 days)
Recovery data Per client 1-90 days (default 5 days)
System logging warning and errors Not adjustable 90 days
System logging information Not adjustable 30 days
System logging debug Not adjustable 15 days

 

Clients can generate reports from Releezme using Microsoft Excel. The responsibility for the storage of these reports lies with the client.

At the written request of the client, Vecos can support the exchange of data with third parties appointed by the client via interfaces developed for that purpose (System interface, SCIM interface). The communication with and the processing of data by these third parties is the responsibility of the client and/or these third parties.

  • Additional agreements Additional agreements
  • All Vecos employees are informed of this policy document and are bound to act
  • When using a USB flash drive, the files must be encrypted and must be deleted from the USB flash drive immediately after the files are
  • Deleting storage media or email containing privacy-sensitive data, within 5 working days after the project has finished or before that, at the earliest possible point in time, if no longer
  • Sending personal data via email from and to Vecos is only permitted when an ‘encrypted file’ is used and

when the key is not transferred in that same email.

  • Personal data are not printed. However, if personal data are on paper or need to be available on paper, these are to be disposed of after use, using the locked metal container for confidential waste paper, which contents are then collected and destroyed by a specialised
  • If clients choose to send unencrypted personal data via email (for instance import files), they are to send these emails to the service email box (mailto:servicedesk@vecos.com). For this reason, the service email inboxes are not archived. After they have been handled, these emails must therefore be deleted as well (inbox, removed items and sent items). If such unencrypted personal data are sent to a personal email address instead of to the Service Desk, it is possible that these data are saved in an automatic back-up. This cannot be
  • A clean desk policy

4. Research & Development

  • Introduction

The development process by Vecos is based on SCRUM and agile working.

The development team uses an unambiguous checklist to determine whether a development item is ready for release and to be used in a next software release. This checklist is used to verify whether:

  • all code is written, checked in, reviewed and approved by the reviewer;
  • relevant design and user documentation is written, checked in, reviewed and approved by the reviewer;
  • unit tests have been updated and were all successful;
  • functional system tests were successfully executed in a representative environment;
  • QA has approved the
    • Sioux Embedded Systems

Vecos attaches great value to the continuity and quality of the R&D team. To properly secure the development activities, to accelerate the process where possible and to increase flexibility and capacity for client-specific development, Vecos has a strategic collaboration with technology partner Sioux Embedded Systems (www.sioux.eu). Sioux has its own quality system and is ISO 9001 and ISO 13485 certified, among others.

The Vecos R&D team consists mostly of Vecos employees and of Sioux employees, and is able to shape all software developments with respect to the Releezme website, API, locker bank controller and other embedded software herself.

  • Development cycle

The Vecos release policy is based on demand in the market. At least once a year a new version of the Releezme software is released; on average, there have been 4 scheduled releases per year in 2016 and 2017. The product manager determines the timing of a new release.

The development team works in two week sprints. Each sprint at least 1 meeting is held with the development team and the product manager to set or adjust the targets for that sprint. The development team consists of persons with the following roles:

  • software developer
  • architect
  • quality assurance engineer
  • product manager

The product manager ensures that all persons in the team are sufficiently equipped to fulfil their role in the sense of available knowledge and competencies.

All of the sprint’s tasks should be completed (see 4.2) at the end of each sprint. For that purpose assessments are made by developers (for design, coding, unit testing) and by quality assurance engineers (for functional testing). The test scenarios are prepared by the quality assurance engineers in collaboration with the software developer and, if necessary, with other relevant persons, which is to be determined by the product manager.

In addition, a part of the software developers’ available time is reserved for 3rd line service and support questions.

  • Change management

Requests for changes and issues can be submitted at any time by service desk employees, software developers, quality assurance engineers and the product manager in the online issue tracking system Azure DevOps.

Every sprint, the development team only works on items which have been categorised in Azure DevOps under that specific sprint in the sprint meeting. The assigning of development items to a sprint is the product manager’s task.

New items are added without a link to a specific sprint or release. At the beginning of every sprint the development team and the product manager go over all (newly received) items and determine:

  • whether the item is accepted;
  • whether the item belongs in the next (or indicated) release;
  • when in current release: whether the item belongs in the upcoming sprint;
  • whether the item requires further analysis;
  • whether the item is privacy or security

Depending on the result, the item is categorised (for analysis or for implementation) in the next or a future release or sprint. If the item is associated with the processing of personal data, the CISO is consulted to jointly perform a Privacy Impact Assessment (PIA). After the CISO has given his approval, the development item can be further dealt with. Reporting is done in Azure DevOps.

During the sprint a software developer processes the items assigned to him/her. All code changes are tested locally by the developer. Where possible, the unit tests are adapted or created for the relevant functionality. The developer checks the changes into Azure DevOps.

For entirely new functionalities or major changes to existing functionalities, the architect and software developers first create design documentation. Small changes to the application flow are processed by developers in said documentation. The same applies to small changes to the data model.

The developer sends a review request to another developer for every (set of) code changes or document changes. The history and content of this review request and possible remarks of the reviewer are saved in the Azure DevOps audit trail. The reviewer looks at functionality, code quality and adherence to the chosen architecture/patterns. The initial developer processes the remarks and the cycle is repeated until there are no more remarks.

All unit tests are executed online daily by Azure DevOps and failed tests are reported to the development team via email. In such an event, solving the failed tests gets the highest priority.

After reviewing, the development item is assigned to a quality assurance engineer, and the Azure DevOps item is provided with a software revision number in which the item is solved. The most recent version of the cloud software is, in joint consultation by the developers, installed in the test environment in Azure multiple times per sprint.

For the tests, randomly generated data are used as much as possible. Test data are only stored in local or test environments, never in production environments. If it is necessary to use client-specific data (for instance to research a client-related issue or to test a client-specific upgrade scenario), this is only done after obtaining the client’s prior express consent (and instruction), in which case it is also agreed when the data will be deleted. The client will be notified of this and the CISO will be informed of it.

The quality assurance engineers verify the Azure DevOps items on the test environment and/or with the newest LBC firmware. If the change is accepted by QA, the Azure DevOps item is marked as closed and its description is added to the release notes. If QA does not accept the change, the Azure DevOps item is returned to the developer, after which the cycle is repeated.

Azure DevOps contains an audit log for all Azure DevOps items, code and document changes, and reviews. This audit log cannot be adapted by Vecos, and always provides a truthful history.

With each new regular release, the OWASP Zap tool (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) is used to check the software for possible weaknesses. Findings are saved and any possible follow up actions are attached to it as an Azure DevOps issue.

The following principles are used for the revision check of the Releezme software:

  • New developments are made on “trunk”.
  • When a release is ready to be rolled out, a “branch” of that software is
  • Revision versions are developed on that
  • Each version that is rolled out to production receives a label in the software archive and the build is archived.
  • In principle, every change in a branch is to pushed to the trunk . Exceptions are branch-specific changes or code that was later
  • Version numbers are jointly determined by the software developer and the product
  • Deployment

The development team has an elaborate step-by-step plan for the upgrading of software production environments in Azure or in on-premises environments.

Brief summary of the cloud procedure:

  • The Vecos product manager has sole authority to approve changes to a production
  • The product manager determines in consultation with the development team and specifically with QA when a new release is deployed. For the cloud environment this happens at least 2 weeks prior to deployment, allowing enough time to inform clients by means of a notification on the
  • Upgrades are scheduled per Azure environment (Europe, Australia) at hours when the system has little activity or is not being used in that time zone. This is to be assessed by the product
  • Prior to the release, the to be released software is frozen for a specific agreed term and a branch is created in Azure That version is subjected to a series of acceptance tests, i.a. on the acceptance cloud environment.
  • The development team may extend the step-by-step plan of the release with specific points for this specific version and executes an upgrade test on the acceptance
  • The development team takes precautions (temporary backups ) to be able to return to the previous version, should issues arise during the upgrade.
  • The development team uses automated scripts that are aimed at executing all components and database upgrades with a minimum of offline-time for the Releezme system. In this, limiting the LBC’s offline-time has the highest
  • After the upgrade, QA executes a number of prepared tests to verify whether the upgrade was successful.

Virtually the same procedure applies to an on-premises upgrade, with the following exceptions:

  • If possible, these upgrades are executed from the Vecos location by means of remote
  • The coordination, alignment and approval of the upgrade are executed by the project manager of Also, the project manager makes arrangements with the client’s project manager in advance regarding consent to make the changes, when the upgrade is executed and possible consequences for the system’s availability.
  • If the client and/or Vecos so desire, a locally recreated virtual environment is used for acceptance, instead of the cloud acceptance

For on-premises upgrades, Vecos first provides a quotation.

The Releezme mobile application is available via the Apple Store and Google Play Store. The Vecos product manager has sole authority to approve a new app release. The technical management is in the hands of the development team. To allow for timely approval, a new version of the app is offered to the store well before the scheduled release date.

When a change or new functionality requires that both the server and the mobile application are upgraded, the actual publication of the app in the app stores is scheduled in the step-by-step plan of the cloud release.

After every rollout on a production environment (cloud or on-premises), the process is evaluated with the team and the step-by-step plan is updated where needed.

  • Self-evaluation regarding continuity, safety and availability

Every 3 sprints (= twice per quarter), the product manager organises a (scrum) retrospective with the development team and the CISO to evaluate its own process and to improve it where possible. The aim is to follow up on the retrospective’s top 3 points for improvement in the next sprint. In this retrospective, the release schedule is also looked at and the required capacity of the cloud environment associated with that, which is provided by the product manager.

Alternately per retrospective it is extended with a ‘Failure Mode and Effect Analysis’ (FMEA).

  • Pen tests

Vecos uses an external party to conduct safety tests on the software. So-called ‘white hat’ or ethical hackers are employed for penetration tests, in order to establish that the software has up to date and appropriate security measures and to trace any possible vulnerabilities in the software.

The product manager organises the tests. The outcomes are evaluated with the CISO. Based on these outcomes, the product manager and CISO jointly decide what needs to be done. The broad outlines of the outcomes of the pen tests are described in the report of the technical and organisational measures as described in paragraph 3.4 and 4.9.

  • Best Practices

The development team applies the following best practices:

  • With every new website or web API functionality there is a conscious evaluation with the product manager and CISO to decide to which roles in the software this functionality should be available and the possible effect on the processing of personal
  • The development team uses a template to fill out change requests or issues to ensure that no relevant information is
  • The development team follows ‘security by design’ by using OWASP principles with new
  • The development team follows ‘privacy by design’ and ‘privacy by default’ in consultation with the
  • The development team uses a secured password manager to store sensitive data, such as login details for cloud systems, configuration management, on-premises systems and encryption certificates. The secured password manager receives a new password monthly. When a member of the development team -who could have viewed the data- leaves the team, the passwords of the cloud system are immediately
  • Developers and operational managers do not use automatic saving for Releezme-related passwords in browsers, database management applications and development
  • Since the software is also installed in on-premises settings, no critical secrets are stored in the server software or server This includes Vecos-wide private encryption keys etc. This also applies to the mobile app.
  • With changes to external APIs and the mobile application, compatibility of older versions is taken into account for as long as feasible, which is to be assessed by the product
  • Releezme system management users use two-factor
  • Every sprint, the Azure security advisor tool is used to obtain security advice from Microsoft about the components used. Recommendations are followed up on according to urgency and impact. If a recommendation is not followed up on, this will be reported to the
  • Role CISO

The role of the CISO is described in paragraph 3.1. In the context of Research & Development, the CISO sees to it that the required processes are followed.

In addition to being present at the retrospective and the assessment of PIAs, the CISO also executes occasional checks on compliance with this policy document. Findings are recorded in the report of the technical and organisational measures as described in paragraph 3.4.

5. Service Desk and project implementation

  • Introduction

In project implementation and when delivering services, the Vecos employees come into contact with personal data. To be able to apply service level management, Microsoft Navision is used as a registration and workflow tool. Vecos also uses Microsoft Navision as a CRM system.

This chapter describes the method and is derived from the ITIL industry standards.

For the delivering of hardware and software, Vecos also works with authorised partners. If a client orders via an authorised partner, the Service Desk and project implementation are provided by the partner.

  • Incident management

An incident is an unscheduled interruption or reduced quality of the Releezme software or locker hardware including the firmware. Incident management is the process to resolve every unscheduled interruption as fast and as well as possible. The targets include, among others:

  • Restoring the normal service production as fast as possible and to minimize the negative impact on operational
  • Ensuring that the agreed levels of service quality and availability are

Clients can report issues via email (servicesdesk@vecos.com). The Servicedesk registers the incident and determines the incident’s priority depending on the underlying SLA and the nature of the issue. The Servicedesk operator coordinates the necessary actions to resolve the incident within set frameworks.

With incident management, the following also applies:

  • Only persons who are registered in Releezme with a management role or are registered in Navision as a contact person for the Service Desk can an report an
  • The service desk operator will not unlock
  • If necessary, Planning or the Service Desk operator bring in the development team for additional support.
  • Problem management

A problem is an unknown cause of one or more issues. The process Problem management handles the clustering of issues and proactive problem prevention in a structured manner. Problem management’s targets include, i.a.:

  • The prevention of issues and the elimination of recurrence of
  • Minimizing the impact of issues which cannot be

Periodically, Planning organises a session with the Service Desk operators to asses any possible issues. Based on those findings, Planning makes suggestions for the improvement of the software and services. These suggestions are discussed with both the product manager and the project managers.

  • Configuration management

In the Releezme software system, configurations are client-specific. The configuration is set up in the initial project. The client is responsible for the configuration and can independently make changes to it.

Vecos will not implement changes in the configuration without written consent (read: email) of the client representative. The client representative is registered in Navision.

  • Project implementation

For every installation project, a project plan or implementation overview is made by Vecos’ project manager. During the project, visit reports are made and an action-and-decision-list is maintained. These documents are stored in Navision together with project-specific correspondence.

Points of attention regarding project implementation:

  • User and management training courses follow a fixed pattern to ensure that all necessary elements are addressed.
  • After the project is delivered, all personal data that were provided (for instance an import file) are deleted from the network and emails containing personal data are

6. Other

  • ICT Cerebel Group

Vecos uses the ICT resources in cooperation with parent company Cerebel Group B.V. In addition, an external ICT company (Cliënt ICT) is used for network management. Cerebel Group also has an IT administrator who coordinates the work with the external ICT company.

Cerebel follows the following principles:

  • All computer systems have adequate and up to date virus scanners and anti-malware. The hard disks are encrypted and the systems have an individual BIOS
  • Multi-factor authentication is preferred. Where passwords are applied, a strong password is used (10 characters, 1 lowercase letter, 1 uppercase letter and 1 special character and the last 7 passwords cannot be reused) with an expiration term of 30
  • The company network and the network for guests are logically separated based on MAC
  • Access to the network and systems is organised based on ‘the principle of least privilege’.
  • Systems for the business operations of the entire Cerebel Group are backed up and stored
  • The Business Continuity is tested
  • Contract Management

Contract management is the process of managing the contracts with third parties in a systematic and efficient manner, up to the execution and the analysis of the execution for the purpose of maximizing the operational and financial supplier performance and risk reduction.

Contract administration is an important part of contract management. Contract administration has the objective to provide the internal organisation with sufficient insight into current contracts and the correct contract agreements and information, by means of keeping records for that purpose.

The contract administrator of Vecos is responsible for the contract management.

  • Human Resources

All Vecos employees must have a Certificate of Good Conduct. The HR manager sees to this upon commencement of employment of new employees. In addition, a non-disclosure agreement is part of the employment contract.

Vecos ensures that similar conditions apply with sub-processors.

Appendix 1: Overview teams and roles

Development team

Product Manager Software developers Operational managers Architect

Quality Assurance Engineer

Project implementation and Service Desk

Project leaders Planning

Service Desk Operators Other

HR

IT Administrator Contract management CISO

Board of directors Vecos

Updated on February 1st – 2018.