As a service provider or infrastructure, you have an idea what services you and your infrastructure partners offer, and to whom. And, as you are processing information, your service will contain valuable data. But what kind of data you are able to store in your infrastructure depends on the risk both you and your users are willing to absorb. And there may be regulatory requirements in place that prohibit you from storing certain classes or data, or that require you to secure of certify your services in a specific way.

Due to the diverse nature of data and services, the Policy Development Kit, while providing context, does not have specific recommendations, policy templates, or procedures. Public resources related to service management, risk assessment, and “AIC” (or “CIA”) information classification are provided below.

Service Levels

Service Management Systems, like the ISO 20 000 standards or FitSM, expect services to be “aligned to the needs and expectations of (potential) customers. Both the service provider and customer are aware of agreed service targets” (quoted from the FitSM standards). When working with a research collaboration, you may be faced with ‘unknown’ data and many implicit expectations, and making the users aware of what your service can and cannot do is essential for both security and functionality.

When engaging with users communities, be it directly or as part of an infrastructure, you should check whether the purpose for which the collaboration comes together matches the capabilities of your service(s). At times, you may want to explicitly clarify what your services may be used for, what their availability and reliability is, and any regulatory limitations users should be aware of. You do this by adding Terms and Conditions to the WISE Baseline AUP, after the 10 immutable clauses.

If you want to provide service guarantees to some of your collaborations, you can also add references to service level agreements at the end of the AUP presentation (“Applicable service levels agreements are located at: <URL>”).

Data classification: availability, integrity, confidentiality

A property of the information, rather than the infrastructure, the triad of availability, integrity, and confidentiality (seen in various permutations as well, like the “CIA Triad”), these different aspects of data security are foundational for both security as well as regulatory compliance.

As a service provider, you should make clear what classes of data may be processed by or stored in your services, and – depending on the sensitivity of the data – you should implement policy and technical controls to prevent the ’wrong’ type of data being sent to your services.

How important each aspect of the AIC/CIA triad is, depends on the (research) use case. Can the user accommodate delays in access, or being locked out for a longer time, as long as there is a near-absolute guarantee that the data will never be altered? It is essentially open, public data, but does it need to be available with 99.9999% availability?

Regulatory compliance also factors in here; for example personal electronic health data is especially protected, but also always available for primary use in healthcare. It scored “high” on all three aspects. Yet secondary use of this data, while still highly confidential, might be more lenient towards availability.

Work with your user communities to extract their data classification, preferably based on a risk assessment. In this assessment, users should take into account their ‘primary assets’ (data and processes that serve the purpose of their collaboration), and service providers should validate whether they have the technical and organisations measures in place to limit the risks to an acceptable level.

Beware of implicit expectations of users, and document the agreements as part of your Service Level Agreement (SLA) or Operational Level Agreements (OLA). Remember that in some cases you may need to (self) certify for compliance to legislation and implementing acts. This is especially common for personal and health data, but can also apply to dual-use and export-restricted knowledge.

Resources

  • No labels