Data Protection

Data protection is about the measures and regulations to prevent unauthorised reading and using of data, protecting our clients’ interests.

Data protection at rest

Data at rest should always be encrypted with at least a SHA-256 or stronger encryption method. That includes backups.

Data protection at transit

Data in transit should always be encrypted with at least a SHA-256 or stronger encryption method. Meaning that secure connections are always used when transferring data outside the shielded platform networks using TLS 1.2 or higher.

Data classification

Data is classified as:

1. Public - data that is available for unidentified persons - the public. It can be freely used, reused, and redistributed without repercussions. Usually used to provide global or generic information or for marketing purposes.
2. Internal use - data that is available for and used by all authenticated employees or customers. This might include internal-only memos or other communications, business plans, etc.
3. Confidential - data that is available to a subset of specifically authenticated employees or customers. Examples are all customer data that can provide an insight into their modus operandi or their performance. Personal data like biometric data or BSN is considered confidential and is protected by the GDPR.
4. Restricted - data that, if compromised or accessed without authorization, could lead to criminal charges and massive legal fines or cause irreparable damage to the company or its customers. Examples of restricted data might include proprietary information or research and data protected by state regulations.

Data categories

Data is categorised according to their (operational) usage and confidentiality

1. Operational data, data that is used by clients or external service providers to support the act of shipping, this data is considered confidential.
2. Historic data, data that has been used by clients or external service providers to support the act of shipping, this data is considered confidential.
3. Technical data (logs), data that is used for internal purposes only, for example, to see how many calls an api receives or to log exceptions.
4. Personal data, data that is part of the Operational data, but can be traced back to an individual and as such might apply for GDPR compliance.
5. Audit data, data that is part of logging our systems operations access, for example, to see who access certain resources.
6. Marketing and analytical data, this data is considered for internal purposes and only contains data that is not directly retraceable to client data.
7. Test & example data, data that is used to test system functionality. This data contains example data that is representative of generic- and client usage of the system.

Data retention

For how long should data be retained and accessible? This highly depends on the data classification. Client access to data is always restricted to legal and contractual obligations, as such, all retention values can be altered to these obligations, compared to the retention period mentioned here.

1. Operational data will be directly available for at least 15 months.
2. Historic data will be available for 6 years, making the total amount of data available spanning a period of 7 years and 3 months
3. Technical data like logs will be available subject to technical needs. Traffic logs will be available for a minimum of 3 months, after which traffic data can be compacted for analytical purposes. Security logs should be available for a minimum of 6 months.
4. Personal data will be subject to the same retention scheme as operational data with the exception of actions to be taken due to GDPR compliance.
5. Audit data is considered as important as Operational data and as such should be retained for at least 15 months.
6. Marketing and analytical data will be available subject to internal needs.
7. Test data is considered as internal data and will be available subject to internal needs.

After contract termination, depending on termination agreements, data will not be retained.

Data authorisation

Individual data authorisation is always given on the least privileged principle. Client individuals are provided authorisation through the system, configured by the client (this responsibility can be forwarded to ShipitSmarter as part of an agreement).

ShipitSmarter users are only allowed to see, and in exceptional cases manipulate, client data on a specific request, in order to solve major production issues.

Client data used for testing and development purposes should always be generated or at least be manipulated operational data in such a way that there is no direct relationship between the test- and production data.

Data isolation

Client data is only accessible by that specific client, enforced by at least Identity Management, but preferably by encrypting the data specifically for that client. Runtime environments (and memory) can be shared, where isolation again is enforced by Identity Management, but non-shared environments have a preference.

The exception being clients having a specific contract where data sharing is agreed on.

Data protection in non-production environments

Production data that is classified as confidential or restricted will not be used in test environments unless the data is properly anonymised. This protects production data from abuse when being used in less security aware environments.

Whenever production data is used in non-production environment, for example to reproduce bugs, the environment hosting the data should be handled like being a production environment for as long as the production data is available on that system.

Physical access

As data is stored either in an external data centre or in Azure, physical access is restricted by the physical data centre policy (Digital Realty). Only people with the highest operational clearance (operational administrators) are allowed to request access. People not having the highest clearance can access the data centre, but only under the supervision of a person with the highest clearance. Each operational administrator can have the supervision of a maximum of one (1) person per data centre visit.