Frequently asked questions SURF Vendor Compliance.

No, we carry out assessments on vendors/applications where there is a need within the sector for conversations about privacy and/or security. These do not necessarily have to be parties with whom we already have an agreement. We negotiate as many modifications and/or contractual arrangements as possible that will benefit the entire education and research sector. This also applies if the contracts are negotiated directly between the institution and the supplier. An additional benefit is that these processes can lead to an agreement through SURF, take Zoom for example.

Twice a year, we assess the needs of CISOs, security officers, privacy officers and data protection officers via the SCIPR network, software contact points, CSCs, the Cyber Security Steering Group, the Beyond Privacy Shield Task Force and MBO Digitaal (via the IBP network).

We consolidate these needs based on criteria such as potential national collaborations, usage and urgency within the sectors, identified issues such as those relating to data storage, incidents, potential conflicts with procurement processes within SURF, and weight (small, medium, large). This information is translated into a proposal for the calendar.

This calendar is submitted to the Cybersecurity Steering Group. They consult with their constituencies and issue a consensus recommendation on the calendar. This recommendation is forwarded to the CSC chairs. They advise the SURF Executive Board. The outcomes of this recommendation are submitted to the SURF Executive Board for approval. Thereafter, the aforementioned stakeholders are informed, and the provision of services commences.

SURF Vendor Compliance reports to the Cybersecurity Steering Group in accordance with the existing frequency and annual cycle within SURF. If the evaluation indicates that substantial changes are required, these are submitted to the SPA (SURF Portfolio Advisory Committee).

We have been asked by members if, on behalf of the industry, we would like to conduct DPIAs, DTIAs and security checks on vendors/applications relevant to the majority of members. SURF negotiates on behalf of the entire sector, making us many times stronger with vendors than individual institutions.

Once we have carried out a risk analysis on a supplier or application, we engage in discussions with the supplier regarding the measures needed to mitigate any identified risks as far as possible. Many of these agreements are laid down in, for example, a standard data processing agreement. Instructions are also drawn up detailing how institutions can use the application in the most privacy- and security friendly way possible. These instructions are made publicly available as much as possible.

Whether your organisation actually uses the application is entirely up to the organisation itself. The organisation is responsible for assessing whether the application or supplier can be integrated into its own processes. We do a lot of preliminary work, but the organisation must ensure it is suitable for use within its own structure. In doing so, you can benefit from the technical, organisational and legal arrangements we have put in place for you.

Black/closed box approach: external perspective, no access to internal systems.
Pros: Mirrors customer view, less intrusive for vendors.
Cons: Limited visibility into internal processes, may identify more high risks.

White/open box approach: full access to internal systems and source code.
Pros: thorough analysis of data processing and security controls.
Cons: time-intensive, requires vendor cooperation.

Grey/(semi) open box approach: combination of black and white box testing, with selective internal access.
Pros: balanced insight, efficient use of resources, reduced vendor input.
Cons: may lead to inconsistent depth of analysis, relies on vendor accuracy.

The costs of carrying out compliance assessments are funded from the Basic Fee for Procurement and Digital Platforms (BIDP). Members have given their approval for the SURF Vendor Compliance service to be included in this. Virtually all members pay this basic fee. Contributions to the service are therefore made at a central level.

On average, we pick up eight projects per year. To identify requirements for the agenda, we send out a request twice a year to the following people: CISOs, security officers, privacy officers and data protection officers via the SCIPR network, software contact persons, CSCs, the Cyber Security Steering Group, the Beyond Privacy Shield Task Force and MBO Digitaal (via the IBP network).

If you have any requests in the meantime, you can submit them via the inventory form. Any requests we receive in the interim will be included in the next update of the calendar.

If there are different requirements within the organisation – for example, amongst staff in different departments – then all these staff members can provide input. If a vendor or application is mentioned more than once, we only count it once. In fact, all vendors/applications submitted per institution are only counted once. 

Example:
- 5 people from institution X each submit 3 different applications: a total of 15 applications are submitted by institution X.

- 5 people from institution X all submit 3 identical applications: a total of 3 applications are submitted by institution X.

This way we guarantee that each discipline/role is represented in the delivery of the desired applications/vendors.  

If you wish to submit joint requirements, there are two ways to do so: 
- Each institution completes the jointly agreed list separately. 
- The list is submitted by a single institution, but it must be clearly stated on behalf of which institutions the requirements are being submitted. This is because we count how many institutions have expressed a requirement for a compliance track on a specific supplier or application.  

Previously submitted requests for compliance assessments remain valid. We add any new input to this. We place the suppliers/applications that are frequently mentioned on a shortlist. Twice a year, we ask institutions to provide feedback on all suppliers/applications on the shortlist. This makes it clear to us which applications require urgent attention and allows us to adjust our calendar accordingly. You can submit input and requests for compliance assessments at any time via this form.

Institutions make extensive use of various suppliers. In many cases, suppliers process personal data of SURF members and their users. Under the GDPR, institutions are obliged to check their suppliers’ handling of privacy and security. SURF undertakes such compliance assessments at the request of institutions. We engage with suppliers on behalf of institutions to discuss privacy and/or security and ensure that suppliers take measures to address any identified risks. It is beneficial to do this collectively on behalf of all institutions; by combining knowledge and expertise, we achieve cost savings, share knowledge and strengthen our negotiating position towards suppliers. 

A DPIA, Data Protection Impact Assessment (DPIA), is a tool to identify privacy risks to data subjects (e.g., users). Under the General Data Protection Regulation (GDPR), a DPIA is required where there is large-scale processing of personal data or sensitive personal data.

Through SURF, the members make joint agreements with ICT and content suppliers regarding the supply and procurement of products and services. This way, the members collectively ensure scale and provide an efficient point of contact for suppliers. Performing risk assessments such as DPIAs are part of this. In many cases, suppliers process personal data of (employees and students of) SURF members. It is therefore important that suppliers comply with legislation and regulations. SURF collaborates as much as possible with partners such as SIVON and the government. Together, several DPIAs have already been carried out.

Each institution must determine for itself to what extent the results apply to its own organisation. The DPIAs produced can therefore be used by anyone, including organisations outside the education and research sectors, but must always be translated into the organisation’s own situation, processes and environment.

An umbrella DPIA conducted by SURF maps out the general functioning and data protection risks of a system. However, it cannot make assumptions about the specific way in which an individual institution deploys and implements the system in day-to-day operations. The final risk assessment and the determination of appropriate control measures therefore always take place at the institutional level. The umbrella DPIA serves as a sector-wide starting point and supporting tool for this purpose.

In most cases, we work with partners such as the Government and SIVON, and we commission external organisations, such as Privacy Company, to carry out research.

Yes, there is close cooperation between SIVON and SURF. The same applies to MBO Digitaal and SURF (and other collaboration partners such as the State). Wherever possible, we work together on the various DPIAs or exchange information about ongoing projects.

The risk assessments are in English because the language of communication with international suppliers is English. The results must also be clear to employees at these organisations and must not be misinterpreted or mistranslated. Furthermore, this ensures the DPIAs are accessible to a wide audience.

We use a qualitative risk assessment method, with a combination of a threat-oriented and a goal-oriented model. This means we investigate possible risks following from technical and organisational issues it encounters during its investigation, using the data life cycle and privacy by design techniques as guidelines, but also actively checks for the occurrence of certain common risks. SURF uses the ICO privacy risk framework based on the ICO taxonomy paper, supplemented as needed with risk frameworks like the one from the NIST PRAM method (problems for individuals) and the Solove taxonomy framework. To assess risks, we use a risk matrix with three levels of severity of impact and three levels of likelihood. While determining the likelihood and impact of a risk, we take into consideration a set amount of factors for both likelihood and impact and motivates its decision extensively.

We continuously evaluate our DPIAs and are actively exploring ways to make the risk tables, level definitions, and accompanying explanations even clearer and more accessible for our members.

No, a DPIA focuses specifically on identifying and mitigating data protection risks for data subjects (such as students, staff, and administrators).

While data protection is a crucial component, a favourable DPIA outcome alone does not mean an application should be fully approved for use. Institutions must conduct broader risk assessments as part of their standard governance and procurement process, depending on the type of process or application they want to use. Examples of additional topics to investigate are IP rights, ethical concerns, trade secrets or other, non-personal confidential information. 

This is not only about measurable material or immaterial harm that may be caused by violations of the GDPR, but also about the fundamental right of individuals to control the personal data concerning them. That right is particularly important considering the significant information asymmetry between individuals and the (large) companies and organisations that process their personal data.

The right of access is the first step in being able to verify for oneself whether processing is lawful. That is why the right of access is enshrined in Article 10.3 of our Constitution, in Article 8 of the Charter, and in the GDPR. If the probability of a risk occurring is 100%, as in the case of incomplete access, the risk table indicates that the risk is high, unless the impact is minimal. Because this involves a violation of a fundamental right, it automatically constitutes a high impact from a legal standpoint and thus a high risk.

Recital 91 of the GDPR explicitly states that a high risk exists when data subjects face obstacles in exercising their rights. When a vendor lacks transparency regarding its chain of sub-processors, it becomes difficult or impossible for individuals to know who is processing their data and to exercise their rights effectively. This directly aligns with the GDPR criteria for a high risk.

No, a DPIA is broader than just a risk identification tool. In accordance with Recital 90 of the GDPR, a DPIA also serves as a mechanism to demonstrate compliance with the requirements of the Regulation.

Risk assessment is an iterative process. When we identify a potential high risk, we first share our preliminary findings with the vendor to check for factual accuracy and to get clarification. Vendors are given the opportunity to provide additional evidence or propose technical mitigations. If an impasse remains, we publish the finding alongside the vendor’s position, enabling institutions to make an informed, independent judgment.

A published DPIA represents a point-in-time evaluation. In general, we conduct an update DPIA approximately six months after the initial publication.