Qualified Electronic Registered Delivery Service Practice statement

QERDS PRACTICE STATEMENT – V1.0

1. Purpose

This document aims to inform users of the Service on how the Service is performed, what to expect in terms of Service and on a high level what measures have been taken to make sure the Service runs correctly.

2. Terms and definitions

Terms appearing in this or other documents starting with capitalized letters are defined terms and have a contractually binding meaning. For those terms not defined hereunder, please check the Terminology in the Terms & Conditions or in the Privacy Statement both of which form an integral part with this Practice Statement.

3. Introduction

Dioss Smart Solutions NV with headquarters in Honderdweg 21, 9230 Wetteren, registered under the KBO number BE 0478 640 659 offers the Qualified Electronic Registered Delivery Service as a product to clients as direct customers and partners as resellers.

An ERDS is a service that makes it possible to transmit data between third parties by electronic means and provides evidence relating to the handling of the transmitted data, including proof of sending and receiving the data, and that protects transmitted data against the risk of loss, theft, damage or any unauthorized alterations.

This makes it possible for companies to digitize their paper workflow and save money on physical registered delivery postage, paper handling and have everything integrated in central information systems.

A Qualified ERDS is then the qualified version of ERDS offering more security in the process. This comes in the form of only using substantial level identification methods such as the Belgian eID card or itsme®, using Qualified timestamps, recording and securing the message
and the evidence.

The Dioss QERDS is audited and consequently certified as a Qualified Trust Service for digitally registered mail (eIDAS). You can find us on the list of trust services within Europe, i.e., the EU Trust List.

Dioss has a focus on identity and is now adding the QERDS product to its repertoire for B2B activities.

This QERDS replaces the physical postal registered email service and digitizes business processes.

Registered mail can be sent through the online UI or through secured APIs in the form of PDF documents. These messages will be routed to recipients, who can - after correctly identifying themselves - receive said message.

3.1 Goal of this document

This document describes what policies, obligations and practices are put in place for the provisioning of the QERDS by Dioss in its role as QTSP.

It also describes how we ensure the security of transmission against any risk of loss, theft, damage or any unauthorized alterations.

This Service is offered in compliance with the eIDAS Regulation (EU) No 910/2014, and in particular the subset on QERDS.

4. Compliance & Certification

The audit is performed by Conformity Assessment Body LSTI based on the eIDAS regulation and is audited via the ETSI 401 and 521 standards, starting 2022 and is recertified regularly.
Additionally, each major change to the platform is audited separately as well.

Dioss will only offer this Qualified Trusted Service after the FOD Economy has published the qualification in the EU Trust List.

Any nonconformities will be rectified by Dioss as required by the FOD Economy.

Dioss is also ISO 27001 certified by auditing party BSI since 2015, which is also recertified yearly and completely audited every 3 years.

Use of the Service also encompasses the processing of Personal Data. Dioss abides by the EU General Data Protection Regulation 2016/679. Full transparency is provided in our Privacy Statement.

5. Contractual Framework

5.1 Practice statement

This Practice Statement is publicly available for any stakeholder via the EU Trust List or via our website (https://smartsolutions.dioss.com/en/products/tuvi/). Any changes to this document will be announced:

• Modifications that have no impact on the Senders or relying Parties will be announced, but the Parties will not necessarily be notified up front.
• Modifications that impact Senders or relying Parties and that do not impact the secure and compliant operation of the Service will be notified via our website (https://smartsolutions.dioss.com/en/products/tuvi/practice-statement/) at least 2 weeks in advance of the implementation of the change.
• In case of changes that impact Senders or relying Parties that are urgent because they are required to maintain the security or compliance of the solution, a best effort will be performed to notify via the website as soon as possible.

This Practice Statement will be periodically reviewed by Dioss management as per the ISMS review policy.

5.2 Privacy statement

The Privacy Statement is publicly available for any stakeholder via our website (https://smartsolutions.dioss.com/en/products/tuvi/).

Handling Personal Data in a thoughtful and secure manner is very important to Dioss. The way we handle personal information is documented in our Privacy Statement.

5.3 Terms & Conditions

Our Terms & Conditions are published on our website (https://smartsolutions.dioss.com/en/products/tuvi/general-terms-and-conditions/) and subscribers will be required to accept these Terms & Conditions before they can use the Service.

6. Technical & Organizational Measures

6.1 Business Continuity

We are prepared for even the biggest issues and that’s where our business continuity policy comes in (ISO27001). It focuses on calamities and critical incidents completely disrupting the Service, and what to do afterwards so that the consequences are managed and recovery happens as quickly and efficiently as possible. Examples include the running datacenters becoming completely inaccessible because of fire, loss of connectivity and more.

It describes a series of actions necessary for recovery and prepares plans for when the worst happens. It also involves preparations necessary to make those plans, such as setting up backup locations and running failover tests for different situations such as mentioned above.

6.2 Employee and employment policy

It is important to have a fully capable team to ensure correct implementation of our policies.

The intake of all employees is thoroughly worked out to check for the necessary experience, skills and background. It also includes the necessary training on internal policies and security mechanics.

Checkout of a leaving employee includes a focus on remaining security responsibilities and the termination of leftover privileges.

6.3 Physical environment and security

The physical environment contains 2 aspects:

• The office, from where the code is written, support is offered, maintenance is performed and more.
• The datacenters that actually contain the data.

The office environment is protected by a series of measures including but not limited to: a fence, video surveillance, separated access control, logging of access and an alarm.

The datacenters are more heavily protected, which is discussed further in the Partner topic.

6.4 Software Access

Access control management is paramount to protecting Dioss’ information technology resources and requires implementation of controls and continuous oversight to restrict and allow access.

This policy is organized into the following key sections which map directly to the ISO 27001/27002 Access Control Domain security objectives:

• User Access Management
  • Registration, (least) privilege management, password management, removal of access, separation of trusted roles, ..
• User Responsibilities
  • Clean desk(top), lock screen, ...
• Network Access Control
  • Network segmentation, firewall systems, use of network services, authentication of external systems, ...
• Operating System Access Control
  • Secure logon procedures, auditing systems, privilege, ...
• Application and Information Access Control
  • allowed software list (system utilities), source code control, monitoring, ...
• Mobile Computing and Teleworking
  • Extra secure access and policy on way of working, ...

For the QERDS Service specifically penetration testing is performed to make sure that the product is safe and secure.

6.5 Incident management

Incidents may occur and in that case, the consequences need to be under control. The best way to do this is by making sure that we are prepared for incidents and how to treat them. The incident policy describes how to communicate to who internally and externally at what time.

It is aimed at a fast recovery first and correct communication and clarity afterwards.

6.6 Inventory & asset management

All relevant assets are identified and appropriate protection measures are assigned to them in line with risk management.

This includes how to handle mobile media, laptops, development & production servers and more. This also includes secure distribution, setup and disposal.

6.7 Information security & review policy

The ISMS system is regularly reviewed and updated according to the current best practices, changing environment and changing business needs.

This is achieved by continuous awareness of the importance of data security. Practically, at least yearly, an internal audit reviews the existing security policies, updates the risk register and checks the changed environment.

6.8 Risk Assessment

Risk analysis is performed on a company level, based on the day to day activities, and is extended with impact analysis of new products or large products, changes in way of working and more. Actions are defined, owners assigned and review is scheduled.

The risk assessment is periodically updated in accordance with the ISO 27001 standard, approved by management, supported by the DPO and security officer of Dioss.

6.9 Cryptographic controls

It is important to keep track of and use the latest state of the art cryptographic techniques depending on the intended usage. Dioss ensures the security of cryptographic keys and cryptographic devices throughout their lifecycle.

Encryption is used where necessary and there are established procedures for the management of the cryptographic control measures used.

6.10 Compliance

Dioss complies with all applicable laws, rules, regulations, decisions and orders when providing Services based on this Practice Statement. Specifically we provide TSP qualified trust services in accordance with the provisions of Regulation (EU) No 910/2014.

6.11 Backup & recovery

We need to ensure that the electronic information resources are backed up at scheduled intervals to suitably secure storage media in order to facilitate the restoration of all or part of those information resources in the event of loss or corruption of the original data.

This includes recovery tests and the definition of an RTO and RPO.

6.12 Contract policy

Which agreements are necessary at what time and what needs to be included as a minimum is defined in the contract policy (ISO27001).

6.13 Antivirus / virus prevention

This extends the software access policy (ISO27001) and defines what minimum requirements the antivirus protection needs to perform.

6.14 Logging & monitoring

Logging is important, not only for auditing purposes but also for monitoring, maintenance and providing evidence for the proof of sending and proof of receiving the Service provides.

A baseline of server monitoring is present, including hardware (cpu, ram, disk) and software (health checks). On top of that, there are extra checks on supplier integrations, vulnerability exposures, server access, database health and more.

Logging is extensive since this Service is required to provide evidence as to the correctness of its process. So for each sending and receiving action, several identifying characteristics of the transaction are stored (for which specifically, see the Privacy Statement). Additionally, any server access or activity on the servers is logged as well.

6.15 Passwords

A specific ISO27001 policy is in place to define how password management and in general access to the services is granted, for both the users of the application and the internal support people.

7 TSP operation

7.1 Sending a registered email

7.1.1 Enrollment

Upon acceptance of the Quotation, an account is created for the Sender:

• A Sender declares an email address and accepts the Terms & Conditions.
• The email address is verified and confirmed.
• The Sender sets a strong password.
• The Sender declares a mobile phone number which is verified and confirmed.
• The Sender enrolls for a two factor authentication (2FA) using google authenticator (or a similar app) or SMS.
• Belgian company number / Belgian VAT number is filled in.

The Sender needs to complete these steps to continue.

• First and last name will be fetched from the Belgian eID card or via itsme® in the steps below.
• The Senders company name will be automatically filled in based on the VAT number.

7.1.2 Sender identification and authentication

The Sender can only be a legal entity. Senders will need to appoint one or more Authorized Users, who should identify themselves with LoA=High, using itsme® or a Belgian eID card. This will be complemented with a KBO check.

Identifying the legal entity

To register an Authorized User, the system will attempt to check the legal representative through a search in the KBO. The Authorized User will receive a list of potential legal representatives (natural persons only) of the Sender and will have to select who he/she/they is/are or select that she/he/they is/are not present in the list. In the last case, he/she/they will have to contact Dioss’ IVO with proof of being a legal representative.

After that, he/she/they will have to identify with eID/itsme® where a name matching will be carried out with the selected legal representative. The registration will check that the names are correct, discarding the middle names in the matching. If there is no match, the activation will be stopped. If there is a match, the process will produce an identification cookie that proves the identity of the user with a high level of assurance, for example an itsme® identification challenge or some data signed with the users eID card. This challenge will be stored in the profile and archived for auditing purposes.

itsme® flow

• The Authorized User is requested to authenticate using the itsme® service.
• The regular itsme® flow is used: summarized below as an illustration, specific flow falls under BMID responsibility.
  • The Authorized User is requested to input their mobile phone number.
  • The Authorized User needs to confirm the action on their mobile phone.
  • Confirmation is sent back to the Service and includes the Authorized User basic information (first and last name).

Belgian eID flow

• The Authorized User is requested to authenticate using his/her/their Belgian eID card.
• The Authorized User may need to install the Dioss eID middleware (if not already installed).
• The Authorized User is prompted for his Belgian eID card and PIN.
• The Belgian eID card is validated using the latest best practices (OCSP, CRL, eID data signatures).

If the selected KBO name of the Authorized User and the itsme®/ Belgian eID data matches (first and last name) then the identified Authorized User can proceed.

If not, the process will be manually checked by an Identify Verification Officer (IVO) to verify that the identified user is indeed the Authorized User. In that case, the system will capture a report from the Identity Verification Officer about the check and which conclusion was taken. Once a company legal representative is confirmed and identified as an Authorized User, they can start using the sending function.

7.2 API Enrollment (optional)

Once the Authorized User is registered and identified, an API key can be generated inside the created profile. This key is the responsibility of the Authorized User, and should be rotated regularly.

API access is strictly secured and will only be available through Dioss themselves or through a specific set of third parties. The Sender may delegate his/her/their API access to these third parties but remains responsible. The list of third parties is contained in its agreement made with Dioss.

7.3 UI Authentication

Senders and their Authorized Users may now login to the web UI using their password and 2FA. There, they may

• Send qualified registered mail.
• Review their information.
• Rotate/revoke their API key.
• Delegate other senders for their company.

7.4 Evidence

The message is always a PDF document. There is no extra metadata except the metadata that is contained in the PDF document itself (which for the purposes of the QERDS Service is part of the PDF document itself).

The message is not altered in any way except for the following:

• Adding a seal to make sure no content is changed.
• Fixing of corrupt references, where Dioss applies its best effort not to change any functional content.

Proof of sending, known as the notification report, with all the relevant data up to that point is generated once the recipient is notified, this contains at least:

• Recipient identification data
• Recipient email address
• Recipient company name/vat if applicable
• Sender identification data
• Authorized User identification data (if applicable)
• Sender email address
• Sender company name/vat if applicable
• Sent document hash
• Sealed document hash
• Timestamp of sending
• All actions related to the delivery

This notification report is sealed and is timestamped using a Qualified Timestamp for the time of receiving by the Service. This is the means to prove that the content has not been modified during transmission.

The notification report can be obtained through the UI or through the API.

7.5 Receiving a registered email

The Receiver will have to be strongly identified/authenticated (LoA=High) before having access to the sent Delivery. Receivers do not need an account to receive messages. They do need to do the identity verification each time they want to receive registered data.

A Receiver cannot reject a Delivery explicitly, though it is possible to just do nothing upon receiving the registered email and let the availability period expire.

Recipient identification and authentication
A Receiver can be a legal and/or a natural person. The Receivers receive a link to the message in their mailbox, and need to identify themselves through a trusted identity provider.

A Receiver will receive a notification that some registered Delivery is available. This notification will happen through the email provided by the Sender.

The email notification will have a link to the QERDS platform. The link is unique and will bring the Receiver to this platform where the Receiver will have to identify prior to getting access to the content of the delivery. Only after a successful identification, the Receiver will be able to access this content.

If the Receiver was defined as a natural person, the identification process (which will make use of Belgian eID/itsme®) will perform a name matching and optionally also birthdate matching between the data provided by the Sender and the data from the official identification data. If all match, the Receiver is considered identified.

The identity check will lead to the creation of a challenge similar to the one used for the identity of a Sender. This challenge will be archived. The declared identity in case of a company will be archived as well as the proof of declaration.

itsme® flow

• The Receiver is requested to authenticate using the itsme® service.
• The regular itsme® flow is used: summarized below as an illustration, specific flow falls under BMID responsibility.
  • The Receiver is requested to input their mobile phone number.
  • The Receiver needs to confirm the action on their mobile phone.
  • Confirmation / refusal is sent back to the Service and includes the Receivers basic information (first and last name).
• If confirmed, the first and last name are compared to the information input by the Sender. If a birthdate was specified by the Sender, then the Receiver will be prompted to enter his/her birthdate.
  If there is a match, the Receiver can continue to consignment.

Belgian eID flow

• The Receiver is requested to authenticate using their Belgian eID card.
• The Receiver may need to install the Dioss eID middleware (if not already installed).
• The Receiver is prompted for his Belgian eID card and PIN.
• The Belgian eID card is validated using the latest best practices (OCSP, CRL, eID data signatures) .
• If validation goes well, the first and last name and potentially also birthdate are compared to the information input by the Sender. If there is a match, the Receiver can continue to the consignment.

Legal Entity
In case of a legal entity, an automated KBO check is performed, where the first and last name of the Receiver’s legal representative is checked versus the ones listed as possible legal representatives. In case this automated check fails, the consignment is aborted, no manual backup verification is provided.

Birth Date
The Sender may specify to check the birthdate of the Receiver as well. In that case, the eID flow automatically checks this as well. In the case of the itsme® flow, the Receiver can be optionally prompted to input their birthdate (based on whether or not the Sender entered the birthdate as an extra validation). This is not meant as an extra security measure but just to make extra sure that the correct person is addressed. In case of a mismatch, the consignment is aborted.

7.6 Consignment

Once the identification process is completed and the match is made, the Receiver can download the PDF document.

Proof of receiving, known as the evidence report, with all the relevant data up to that point is delivered to the Sender and Receiver, this contains at least:

• Receiver identification data
• Receiver email address
• Receiver company name/vat if applicable
• Sender identification data
• Authorized User identification data (if applicable)
• Sender email address
• Sender company name/vat if applicable
• Sent document hash
• Sealed document hash
• Timestamp of sending
• Timestamp of acceptance/expiry
• Method of authentication of the receiver
• All actions related to the delivery

This evidence report is sealed and is timestamped using a Qualified Timestamp for the time of receival (upon successful authentication) by the Receiver. This is the means to prove that the user content has not been modified during transmission.

The evidence report can be obtained through the UI or through the API, and is also sent to the sender and receiver by email.

7.7 Timeline

Once the registered Delivery is notified to the receiver, it remains available for receival for 14 days before it expires. In the meanwhile the Sender can retract the registered Delivery as long as the receiver has not taken any action to receive it.

When the registered Delivery reaches a next state (expired, retrieved by recipient or retracted by sender), the evidence reports (and document itself in case of successful receival by the recipient) of registered Delivery remain available for download through the API/GUI for another 14 days.

The registered Delivery can be retrieved multiple times by the receiver during this period, but only if it has been successfully received (not when expired or retracted).

After this period, the registered delivery is marked as archived. Upon archiving, the document of the registered Delivery is deleted from the server. The evidence reports are also removed from the server, but those do remain available on the long term storage for 7 years.

Additionally, 2 years after archiving, the metadata of the registered Delivery is removed from the database.

See further information in the Terms & Conditions and the Privacy Statement.

8. Partners and suppliers

Some services used by the Service are outsourced to reliable external partners, and are either on the EU trust list or otherwise certified for reliable service (for example through the ISO 27001 standard or for the datacenters the ISO 9001 standard). The supplying actors are always checked for delivery reliability and meeting the high requirements necessary for stable and correct service.

External partners are used for: Qualified timestamps, hosting, physical hardware for key storage and more.

8.1 Exploitation

This Service is made available by Dioss, but can also be used and exploited by partners. They will offer the Service through their own commercial channels but use the UI and API of the Dioss QERDS.

8.2 Connected Trust Services

DigitalSign
Provides Qualified Timestamps and is listed on the EU trust list.

Universign
Provides Qualified Timestamps and is listed on the EU trust list.

Quovadis Trustlink BV
Issues certificates for qualified electronic seals and is listed on the EU trust list. They also provide FIPS 140-2 level 2 signature creation devices.

Belgian Mobile ID
Provides itsme® services and is listed on the EU trust list.

8.3 Other main partners

AWS
AWS is used for long term storage of the evidence and logs.

Belgian Government
We use the OCSP and CRL services of the Belgian government to validate the Belgian eID. The government is responsible for the issuance and continued service surrounding the Belgian eID cards.
The Belgian Government has the final authority on instating this Service as a QTSP.

Hetzner
The cloud hosting occurs at Hetzner. Hetzner is ISO 27001 certified.

LSTI
LSTI is the auditing party, Conformity Assessment Body and accredited by the EU to perform audits for QERDS.

Yubico
This party provides FIPS 140-2 level 2 HSMs.

9. Support

Businesses with a contract or Service Level Agreement are referred to the stipulations provided therein.

Businesses that use this Service through a partner (who has a contract with Dioss) should contact this partner.

Receivers should contact the respective Senders for first line support.

10. Qualified Status

The service offered by Dioss is audited and reviewed for qualification, in order to provide the QERDS Service with Dioss as the QTSP. The current EU Trust List can be verified on the following website: https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home

11. Termination

Dioss has created a Termination Plan that deals with termination notification, subcontractors management, information maintenance, termination phasing and updating of the termination plan procedure.

11.1 Notification

Dioss will inform the FOD Economy as soon as the decision to terminate the Service has been made.

All customers of the Service will be informed at least 30 days before the actual termination of the Service. The notification will include the date of termination, the termination plan and the practical arrangements to be made.

All recipients will be informed about the termination of the Service on the website (https://tuvi.dioss.com). The notification will include the date of termination. All the other parties which are involved in the electronic registered Service (taking into account contract specifics) will also be notified in order to hand over or terminate the contracts and to make further arrangements.

11.2 Continuation

Dioss will contact QTSPs of the qualified electronic registered delivery Services in order to find a successor for the Service. Preliminary contacts to do this will be made before the QERDS enters operations. FOD Economy will be kept up to date of these contacts and negotiations.

In case a successor is found, Dioss will make all the necessary arrangements to transfer all loggings to this successor and offer the existing customers the opportunity to move to the successor for the continuation of the Service.

In case no successor is found, Dioss will make the necessary arrangements to transfer the evidence data to the Senders for later storage.

11.3 Practical arrangements after termination notification

Once all relying parties have been informed of the termination of the Service, the following arrangements will be made:

• No new Senders will be accepted.
• No new deliveries will be accepted.
• Outstanding electronic registered deliveries not yet accepted by the receiver will be kept available for acceptance by the receiver up to the agreed upon period (normally 14 days).
• Already accepted electronic registered deliveries will be kept live for download by the receiver for the period agreed upon with the specific clients in their contracts (normally 14 days).