Dossier Afspraken en Procedures
Dossier Afspraken en Procedures
Het Dossier Afspraken en Procedures (=DAP) is een beschrijving van de operationele kaders die de functioneel beheerders centraal hebben bepaald die gelden voor alle voorzieningen van de Coöperatie. Dit zijn dus de afspraken tussen de leden en de Coöperatie Mbo voorzieningen U.A.
Het proces om te komen tot een DAP is erop gericht om eenduidigheid te krijgen tussen de leden, om de processen van de Coöperatie en haar leden zo kosteneffectief te laten werken. De DAP is een document dat alle afspraken bevat of verwijzingen hiernaar. Het doel van de DAP is om één set van alle afspraken te hebben voor alle voorzieningen zodat er zo min mogelijk verwarring op kan treden.
Positionering
De DAP vormt een eenheid met de PDC. Waarin de PDC de strategische en tactische kaders aangeeft en de DAP de operationele.
Het management van de Coöperatie is verantwoordelijk voor het beheer van dit document. Een wijziging wordt pas definitief doorgevoerd als alle deelnemende leden akkoord zijn. Indien er geen tekst kan komen waar een ieder mee akkoord is beslist het bestuur. Na akkoord zal aanpassing van dit document van kracht worden volgens versiebeheer.
Versie | Datum | Gewijzigd | Naam |
0.9 | 3 dec 2020 | Versie ter goedkeuring AV | IM |
1.0 | 16 december 2020 | Goedkeuring AV | IM |
1.9 | 19 mei 2021 | Versie ter goedkeuring AV na review leden | IM |
2.0 | 10 juni 2021 | Officiele versie. Goedkeuring AV 9 juni | IM |
De begrippenlijst is uniform voor het Coöperatiereglement, de Product Diensten Catalogus en dit Dossier Afspraken en Procedures. Het kan dus zijn dat niet alle begrippen hieronder genoemd in dit document voorkomen.
Algemeen manager
De persoon die leidinggeeft aan de (ingehuurde) medewerkers van de Coöperatie en verantwoordelijk is voor de uitvoering van de werkzaamheden binnen de coöperatie.
Algemene Vergadering (AV)
Het orgaan van de Coöperatie dat bestaat uit de leden conform artikel 4 van de akte van oprichting.
Beheerskosten
Alle kosten die voortvloeien uit het inkopen of bestellen van roerende zaken en diensten met een economische levensduur van korter dan een jaar.
Bestuur
Het bestuur van de Coöperatie Mbo Voorzieningen U.A..
Budget
De aan de algemeen manager beschikbaar gestelde geldmiddelen na goedkeuring van de AV.
CAMBO
Voorziening Centraal Aanmelden voor het mbo
Code goed bestuur in het mbo 2020
Deze code geldt voor door de overheid bekostigde instellingen voor middelbaar beroepsonderwijs. Wanneer mbo-instellingen een scholengemeenschap vormen met het voortgezet onderwijs, met het hoger beroepsonderwijs of daarmee andere bestuurlijke of institutionele verbindingen hebben, wordt aanbevolen de onderhavige code van toepassing te laten zijn op de gehele instelling.
Coöperatie
Coöperatie Mbo Voorzieningen U.A., opgericht op 4 april 2019 te Utrecht.
Dossier Afspraken en Procedures (DAP)
Dossier afspraken en procedures. Dit document bevat alle tactische en operationele afspraken rondom de levering van de voorzieningen.
Expertgroep
Afvaardiging van de leden om te beslissen over wijzigingen. Voor wensen voor doorontwikkeling en wensen die fundamentele veranderingen teweegbrengen in de architectuur, de governance, de security of privacy hebben zij een adviserende rol aan de gebruikersgroep voorzieningen.
F&C
Afdeling Finance en Control ondergebracht bij de MBO Raad.
Functionaris Gegevensbescherming (FG)
De functionaris gegevensbescherming van de Coöperatie.
Functioneel Beheerder
Verantwoordelijke voor het optimaal functioneren en de continuïteit van de voorzieningen binnen elk afnemend lid.
Gebruikersgroep voorzieningen
De Gebruikersgroep voorzieningen is belast met de vraagarticulatie van de mbo-sector in relatie tot de Coöperatie. saMBO-ICT is verantwoordelijk voor een goede samenstelling en het goed functioneren van deze werkgroep. De werkgroep is slechts adviserend naar de AV van de coöperatie. Alle leden van de coöperatie zijn ook lid van saMBO-ICT.
Investeringen
Alle zaken met een aanschafwaarde van €1.000 of meer én een economische levensduur van
xxxxxx dan een jaar.
Leden
Alle mbo-instellingen die lid zijn van de Coöperatie.
Mailbox eigenaar
Producteigenaar die verantwoordelijk is voor de mailbox xxxxxxx@xxxxxxxxxxxxxxxx.xx en de algemeen manager die verantwoordelijk is voor de mailbox xxxx@xxxxxxxxxxxxxxxx.xx. Beide zijn de tweede verantwoordelijke van de andere mailbox in geval van afwezigheid of calamiteit.
Melder
De persoon die een melding doet bij de Coöperatie.
Medewerker
De (ingehuurde) medewerker van een afdeling hiërarchisch vallende onder de algemeen manager.
MBO Raad
De MBO Raad is de brancheorganisatie van de instellingen in het middelbaar beroepsonderwijs en de volwasseneneducatie. Bij de MBO Raad zijn alle instellingen in de mbo-sector aangesloten die bekostigd onderwijs aanbieden. De vereniging behartigt de gemeenschappelijke belangen van de leden, biedt diensten aan en onderneemt gezamenlijke activiteiten die samenhangen met deze belangenbehartiging.
OI
Onderwijsinstelling.
Product Diensten Catalogus (PDC)
Dit document bevat alle strategische afspraken rondom de Coöperatie en haar voorzieningen.
Producteigenaar
Deze persoon valt onder de staf van het uitvoerende bedrijf van de Coöperatie en heeft de inhoudelijke verantwoordelijkheid voor de voorzieningen.
Protocol datalekken
Het protocol hoe te handelen op het moment dat een datalek zich bij de Coöperatie Mbo Voorzieningen U.A. als verantwoordelijke, of bij een (sub)verwerkers voordoet. Goedgekeurd door de AV van 14-9-2020 en te vinden op de site xxxxx://xxxxxxxxxxxxxxxx.xx/xxxxxxx/.
saMBO-ICT
saMBO-ICT is een zelfstandige organisatie van en voor alle mbo-instellingen en is belangenbehartiger van de sector op een breed terrein.
Note: saMBO-ICT gaat met ingang van 1 januari 2022 onderdeel worden van de MBO Raad zoals besloten in de Algemene Vergadering van de MBO Raad d.d. 24 november 2020. Overal waar nu saMBO-ICT genoemd staat, kan vanaf 1 januari 2022 MBO Raad gelezen worden.
Staf
De mensen die bedrijfsmatig betrokken zijn bij het uitvoerend bedrijf van de Coöperatie.
Statuten
De statuten van de Coöperatie, zoals weergegeven in de akte van oprichting d.d. 4 april 2019.
Voorzitter
De Voorzitter van het Bestuur van de Coöperatie, gekozen uit en door het bestuur.
VVA
Voorziening Vroegtijdig Aanmelden.
Voorziening centraal aanmelden (CAMBO) 7
5.2 Herstel- en reactietijden 9
5.3 Escalatie bij calamiteit 9
6.4 Proces nieuwe strategische ontwikkelingen 14
8.2 De functioneel beheerders werkgroep 19
Alle diensten rondom de voorzieningen die de Coöperatie uitvoert voor haar leden.
Alle specifieke software voor één of meerdere leden.
De onderstaande processen worden geborgd via deze DAP, zie hoofdstuk 4
• Verstoringen
• Wijzigingen
• Back-up en recovery
• Problemen
• Rollen en rechten
• Escalatie
Alle contactpersonen van de leden horen op de hoogte te zijn van deze procesbeschrijvingen.
De Coöperatie ondersteunt de voorzieningen VVA en CAMBO voor haar leden. Hieronder een uitleg hoe welke meldingen geadresseerd kunnen worden. Belangrijk is dat de leverancier het eerste aanspreekpunt is en, binnen werkuren, altijd een helpdesk beschikbaar heeft. De coöperatie is voor de escalatie en vragen.
Voor zowel VVA als CAMBO is Topicus de leverancier.
Er kan contact worden opgenomen met de leverancier indien een verstoring van de afgesproken dienstverlening optreedt. Hiervoor houdt de coöperatie een overzicht bij van alle leden met de twee contactpersonen die de leverancier, Xxxxxxx, kunnen bellen bij een storing. Het lid blijft zelf verantwoordelijk voor het correct aanleveren van deze contactpersonen. Voor vragen rondom de processen, implementaties, escalaties of overige vragen kan contact worden gezocht met de Coöperatie.
Contact Topicus Helpdesk | |
Telefoon | x00 000 000000 |
xx_xxxxxxxxxxx@xxxxxxx.xx (voorkeur aan communicatie) | |
Website | xxx.xxxxxxx.xx/xxxxxxx |
Contact de Coöperatie | |
Telefoon | Alleen voor prioriteit 1 (prio bepaling zie onder) verstoringen kan, naast de e- mail of de contactmogelijkheid op de site gebeld worden met de Coöperatie op 0348 75 36 66. Overige prioriteiten en zaken kunnen worden gemeld via e- mail of de contactmogelijkheid op de website. |
Website | |
Bereikbaarheid | De e-mail wordt zeer regelmatig gecontroleerd, zeker in de drukke aanmeld periodes. Minimaal zal echter éénmaal per dag deze mailbox gecontroleerd worden. |
Voorziening centraal aanmelden (CAMBO)
De verantwoordelijkheid van de Coöperatie begint wanneer de aspirant student die zich wil aanmelden en zich meldt bij de CAMBO tot waar de aanmelding kan worden opgehaald door het SIS van het lid. De connectie van en naar het SIS van de instelling blijft de verantwoordelijkheid van het lid. Indien het probleem in een “grijs” gebied bevindt ligt de verantwoordelijkheid bij de eigenaar van de software welke de oorzaak is van het probleem. Indien de aanmelder een bevestiging heeft ontvangen maar de aanmelding niet terecht komt in de SIS van het lid. Ligt het probleem bij de SIS welke de data niet goed ophaalt, dan is dit de verantwoordelijkheid van het lid. Ligt de oorzaak in een fout in de voorziening welke de data niet goed klaarzet, dan is de Coöperatie verantwoordelijk.
Indien een aspirant student zijn aanmelding intrekt via CAMBO, dan valt het intrekken van de aanmelding onder de verantwoordelijkheid van de Coöperatie. Indien het lid deze aanmelding heeft doorgezet naar het SIS en daar het proces is doorgezet, dan zijn beide verantwoordelijk voor hun eigen proces.
De prioriteitstelling is afhankelijk van de impact van de verstoring tot een getroffen persoon, meerdere personen, een instelling of meerdere instellingen. Daarnaast heeft de urgentie invloed op de prioriteit en of er helemaal geen doorgang van het aanmeldproces kan plaatsvinden, beperkt of dat het gewoon door kan gaan.
Impact | Aanmeldproces stopt | Aanmeldproces hapert | Aanmeldproces gaat door |
Één persoon | 3 | 3 | 3 |
Beperkt aantal personen | 2 | 2 | 3 |
Instelling | 1 | 1 | 3 |
Meerdere instellingen | 1 | 1 | 3 |
De Coöperatie heeft de ondersteuning op zowel VVA als CAMBO ondergebracht bij Topicus. De onderstaande herstel- en reactietijden heeft de Coöperatie met Topicus d.m.v. een SLA afgesloten. Xxxxxxx is ook meegenomen in deze DAP en is bekend en heeft zich gecommitteerd aan de afspraken die hierin gemaakt worden. Twee keer per jaar wordt in de AV hierover gerapporteerd.
De prioriteit van de verstoring bepaalt de snelheid waarmee deze wordt verholpen (= hersteltijd) of een eenvoudig verzoek wordt afgehandeld (= reactietijd). Het spreekt voor zich dat de Coöperatie verstoringen die impact hebben op het lid nauw zal volgen en bijsturen indien nodig. De leverancier heeft een skilled helpdesk. Deze is bemenst tussen 8.30 en 17.00 op werkdagen. Bij prioriteitsmeldingen kan gebeld worden en hierdoor is de reactietijd minimaal.
Prio | Hersteltijd |
1 | < 4 uur |
2 | < 16 uur |
3 | < 1 werkweek |
Een prio 1 melding is een grote verstoring van de dienstverlening waarbij er geen aanmeldingen doorkomen bij minstens één lid.
De Coöperatie beheert een up-to-date escalatieprocedure, zie hiervoor paragraaf 6, welke zal worden gebruikt in geval van een escalatie.
De software heeft ook beheer en onderhoud nodig. Dit zal, indien mogelijk, gebeuren binnen het onderhoudswindow. Hierbij zal er weinig tot geen overlast ervaren worden. Dit is duidelijk afgesproken met de leverancier en gecontroleerd door de Coöperatie. Het onderhoudsvenster is elke donderdag tussen 16.00 en 17.00. In het uitzonderlijke geval van onderhoud waarbij een duidelijke onderbreking van de voorzieningen te verwachten is, wordt dit pas na overleg met de Coöperatie uitgevoerd. Deze zal dit dan communiceren met de aangegeven contactpersonen van de instellingen. Indien een lid problemen heeft met een bepaald tijdstip, zal een alternatief tijdstip gezocht worden in gezamenlijk overleg. Indien er noodzakelijke maar niet voorziene werkzaamheden hebben moeten plaatsvinden waardoor de voorziening niet tijdelijk beschikbaar was zal de Coöperatie hiervan direct op de hoogte worden gesteld. Dit zal indien mogelijk vergezeld worden met een beheersmaatregel van de leverancier om dit in de toekomst te voorkomen. De contactpersonen van de leden worden zo spoedig mogelijk door de coöperatie op de hoogte gesteld.
De onderstaande processen worden geborgd via deze DAP:
• Basisproces
• Incidenten
• Wijzigingen
• Problemen
• Nieuwe wensen
• Rechten en rollen
vraag
Document
Data- base
Start/einde
Aktie
Uitgangspunten proces beschrijving
• Ieder proces begint met een start en eindigt met een stop
• Iedere stap naar een volgend item is genummerd. In de beschrijving staat hier de uitleg wie verantwoordelijk is en hoe de output eruit ziet.
• Escalatie
Ander proces |
6.1 Basis proces
1
1. Het hoofdproces wordt gestart doordat een melding gedaan wordt via mail naar xxxxxxx@xxxxxxxxxxxxxxxx.xx, xxxx@xxxxxxxxxxxxxxxx.xx of via de contact mogelijkheid op de site. Indien verzoek op een
Ja
Nee
Protocol datalekken |
andere manier binnenkomt zal gevraagd worden bovenstaande manieren te gebruiken. De eigenaar van de mailbox is verantwoordelijk voor het (laten) uitlezen van de mailbox en het routeren van het contact. Er is geen direct contact met studenten, dit gaat via het lid. Er kunnen meldingen gedaan worden over verstoringen of wensen van de delen die onder
de verantwoordelijkheid vallen van de coöperatie, zie gegevens stroom en verantwoordelijkheden.
Ja
Incidenten proces |
2. Indien de vraag betrekking heeft op informatie beveiliging of privacy gaat het protocol datalekken in werking. Iedereen die een melding binnen krijgt doet deze check.
Nee
Ja
Ja
3. Indien de vraag gelijk te beantwoorden is, kan het gelijk afgehandeld worden. Essentieel is dat dit altijd gebeurt via de support of info mailbox. Pas na OK van de melder kan naar de afsluiting worden doorgegaan.
4. Indien het een product inhoudelijke vraag betreft
Nee
Nee
Wijzigingen proces |
Ja
5. Indien het een bestuurlijke vraag betreft wordt deze doorgezet naar de algemeen manager met de bestuursleden in de cc.
7
6. Indien het een overige vraag betreft wordt het contact doorgezet naar de algemeen manager.
7. De persoon aan wie het verzoek is doorgezet is verantwoordelijk om het liefst binnen een werkdag of zeker binnen een week een reactie geven over het te volgen proces ter beantwoording van het verzoek. Deze eigenaar blijft eindverantwoordelijk voor het hele proces
8. Indien het een probleem betreft (“hij doet het niet en gisteren wel”) gaat het incidentenproces in
werking anders gaat het om een wens en gaat het
wijzigingen proces in werking. De melder wordt hiervan op de hoogte gesteld
9. De probleemhouder is verantwoordelijk dat de juiste informatie in de FAQ op de website xxx.xxxxxxxxxxxxxxxx.xx komt. De algemeen manager ziet hierop toe.
10. De probleemhouder zorgt ook voor het afsluitende contact met de melder.
11. Indien de melder niet OK is met het antwoord, en er geen alternatief geboden kan worden, gaat het contact over naar het bestuur welke een beslissing kan nemen.
Contact aanmelder
Stuur contact door naar management
Aktie
Start
2
IBP
Incident
3
Direct te be-
antwoorden
4
8
Issue?
Betrekking op
voorziening
5
Betrekking
op bestuur
Nee
6
9
10
Werk evt FAQ
bij
11
Nee
OK?
Ja
einde
1
Incident
2
Contact de SIS leverancier
2
Contact
Aanmelder
7
Ja
Opgelost?
Nee 3
Ja
Nee
Opgelost?
4
Start
5
Nee
Opgelost?
Ja
6
Web-
site
Einde
Product eigenaar contact
Proces Coöperatie
Proces Lid
Contact de leverancier
Probleem proces |
Beschrijving
1. Een (deel) van het aanmeldproces geeft een fout. Het werkte eerder wel en vandaag niet.
2. Het lid neemt als eerste contact op met SIS leverancier
3. Indien er geen oplossing door de SIS leverancier gevonden kan worden neemt het lid contact op met de leverancier van de voorzieningen (contact gegevens DAP)
4. Indien zowel de SIS leverancier als de leverancier van de voorziening het niet kunnen oplossen wordt de Coöperatie betrokken. De producteigenaar is verantwoordelijk voor de coördinatie van deze incidenten. De producteigenaar kan zorgen dat de partijen samen komen om het probleem op te lossen of kan evt. een externe partij betrekken.
5. Blijft ook hierna het issue bestaan dan wordt het probleem proces gestart.
6. De producteigenaar neemt contact op met aanmelder. Probleem en oplossing worden, indien behulpzaam, op de website kenbaar gemaakt voor de overige leden in de FAQs. Belangrijk is dat alle communicatie wordt gedaan via de mailbox xxxxxxx@XXXxxxxxxxxxxxxx.xx of deze in de cc wordt meegenomen
7. Einde proces
Beschrijving
1. Er is een wens om de bestaande voorziening aan te passen. Deze komt binnen via het hoofdproces. In principe kan ieder contactpersoon van de coöperatie het proces starten
2. De producteigenaar is verantwoordelijk voor dit proces en zorgt dat er een up to date lijst is van alle aanvragen en hun status en gepubliceerd op de website 🡪 roadmap
Nee
3. De producteigenaar zorgt er voor een eerste impactbepaling. Hierbij spelen privacy, security, governance en architectuur een rol. Een mogelijke nieuwe DPIA wordt hier bepaald.
4. De producteigenaar bepaalt of de aanvraag binnen de huidige functionaliteit valt zoals beschreven binnen het programma van eisen.
5. Minimaal elk half jaar is er een vergadering van de expertgroep, voorgezeten door de producteigenaar. Dit is een expertgroep van afgevaardigden van potentieel alle leden maar minimaal 5. De wijzigingsvergadering bepaalt de inhoud van de wijzigingen met de producteigenaar als eindverantwoordelijke. Indien de wijziging niet kan wachten tot het volgende overleg zal een spoed vergadering worden ingelast. De producteigenaar stelt ook alle contactpersonen van de gebruikersgroep op de hoogte en houdt bij of hier reacties uit komen die eventueel nog met de expertgroep besproken meten worden.
6. Wensen voor nieuwe functionaliteit die evt uit dit proces naar voren komen worden vermeld op de website en deze worden meegenomen in het proces voor nieuwe ontwikkelingen
7. De producteigenaar zorgt voor een up to date lijst van wijzigingen genaamd de roadmap. Deze lijst is een vast onderwerp in de AV.
8. De producteigenaar bepaald het tijdstip van opleveren in dialoog met de expertgroep.
9. De producteigenaar heeft de vrijheid om, binnen het gegeven budget, de opdracht te geven voor de doorontwikkeling. De tekenbevoegdheid is bepaald in het procuratiereglement
10. De realisatie van de wijziging wordt uitgevoerd door een externe partij onder regievoering van de producteigenaar.
11. De producteigenaar test de wijziging, mbv expertgroep en gebruikersgroep, werkt de documentatie bij en publiceert deze op de website
12. Einde proces
Start
1
2
Werk wzv lijst
bij
Web-
site - road map
3
Impact
bepaling
4
Binnen
PvE
Ja
5
6
Bespreek
status in wzv vergadering
Nieuwe
ontwikke-
lingen
7
Werk wzg lijst
bij
Web-
site - road map
Nee
9
ealiseren?
8
10
Ja
Realisatie
11
Testen en
Documentatie bijwerken
Web-
site
Einde
6.4 Proces nieuwe strategische ontwikkelingen
Hieronder het proces van doorontwikkeling van de bestaande voorzieningen die binnen de coöperatie gevoerd worden, inclusief nieuwe voorzieningen die aan de dienstverlening kunnen worden toegevoegd. Van de huidige voorzieningen heeft VVA echter een wettelijke grondslag. De doorontwikkeling zal ook deze wettelijke kaders volgen.
Wensen kunnen worden gemeld bij xxxxxxx@xxxxxxxxxxxxxxxx.xx of via de site xxx.xxxxxxxxxxxxxxxx.xx/xxxxxxx.
Het jaarplan staat centraal in dit proces. Het goedkeuren van de begroting geeft mandaat aan het jaarplan om uitgevoerd te worden. De algemeen manager van de Coöperatie is verantwoordelijk voor de realisatie van dit jaarplan. Het bestuur legt verantwoording hiervoor af in de AV.
Nieuwe voorzieningen en toevoegingen aan de bestaande voorzieningen met impact op privacy of beveiliging, de architectuur of de prijs, zullen aangedragen worden door de expertgroep en en door een nog op te richten gebruikersgroep voor de nieuwe ontwikkelingen.
Deze gebruikersgroep voor de vraagarticulatie van de nieuwe ontwikkelingen zal onder beheer vallen van saMBO-ICT en zal zich niet alleen beperken tot de voorzieningen van de coöperatie. Deze bepalen de vraag en vertalen dat naar een voorstel aan de AV. Het management van de Coöperatie en de product eigenaar zijn aanwezig bij elke bijeenkomst van deze groep. Aan de input van deze groep is geen enkel recht te ontlenen, deze is slechts richtinggevend. De uiteindelijke goedkeuring komt door de goedkeuring van het jaarplan in de AV.
• Mei of zoveel eerder als wenselijk – Op uitnodiging van de directeur van saMBO-ICT is er een samenkomst met een ledenafvaardiging om samen te denken over de uitdagingen van het volgende jaar (of jaren) op het gebied van gezamenlijke voorzieningen;
• Juli- Directie van de Coöperatie schrijft op basis van deze input een voorstel jaarplan welke centraal gepubliceerd wordt in september van waarop alle leden kunnen reflecteren;
• September – Het management van de Coöperatie rekent de plannen door op de mate waarin ze bijdragen aan de missie van de Coöperatie (verwoord in de PDC) en wat er moet gebeuren vanuit een risico perspectief met de financiële consequenties;
• Oktober ligt er een begrotingsvoorstel door het management van de Coöperatie welke zal worden doorgesproken met het bestuur en de controllers van alle instellingen;
• In de AV van november/december wordt goedkeuring gegeven aan de uitvoer van het jaarplan.
• Twee keer per jaar wordt in de AV een reflectie gegeven over de voortgang
Wegen en adviseren van de gewenste nieuwe functionaliteit
De groep nieuwe ontwikkelingen zorgt voor een weging en advies van alle ideeën op basis van toegevoegde waarde van de wijziging voor de leden en de verwachte kosten en de hoeveelheid werk voor het lid. In het jaarplan zal deze afweging vermeld worden.
Noodzakelijke technische wijzigingen kunnen bepaald worden door de leverancier en de product eigenaar maar zullen wel altijd ter informatie aan de wijzigingen groep worden doorgegeven.
Uitvoeren van de nieuwe functionaliteit
Het management van de Coöperatie is verantwoordelijk voor het, laten, uitvoeren van de aanpassing van de voorziening na accordering van het jaarplan door de AV. De aanpassingen zullen altijd verlopen in samenspraak met de kerngroep. Hier worden ook de release momenten bepaald.
Testen van de nieuwe functionaliteit
De eerste, technische test wordt gedaan door de leverancier. Daarna zal de producteigenaar de eerste functionele test (laten) doen. Na deze accordering zijn de leden zelf verantwoordelijk voor het functioneel testen van de wijziging. Dit kan meestal eerst in de testomgeving plaatsvinden.
Implementeren van de nieuwe functionaliteit
De leverancier is verantwoordelijk voor het kundig en tijdig implementeren van de nieuwe functionaliteit in de voorziening. De leden zijn zelf verantwoordelijk voor eventuele werkzaamheden aan de kant van het lid of hun SIS. Hierover zal uitgebreid met de leden en de bekende SIS leveranciers gecommuniceerd worden. De communicatie hierover is de verantwoordelijkheid van de producteigenaar.
Controleren van de nieuwe functionaliteit
De functionaris gegevensbescherming van de Coöperatie is verantwoordelijk om, indien nodig, een DPIA te organiseren rondom de nieuwe functionaliteit. Deze check gebeurt bij de impactbepaling van de nieuwe wijziging. De producteigenaar is verantwoordelijk dat deze check gebeurt.
De medewerkers van de Coöperatie hebben geen account voor de voorzieningen met een daaraan gekoppelde rol. Zij hebben hierdoor geen recht om de software in te zien of op een andere manier de werking ervan te beïnvloeden. Ze kunnen geen persoonsgegevens inzien of zijn in een positie de software beschadigen.
Op de systemen van de voorzieningen hanteert de leverancier intern keyHub (zie xxxxx://xxxxxxx- xxxxxx.xxx/) met auditing en restricties. Hiermee is zowel toegang tot de servers als het inloggen op de applicatie inzichtelijk en geregeld.
Zowel de aangewezen gebruiker van het lid met een admin account als de medewerkers van de leverancier, met een account in CAMBO, kunnen wel zicht hebben op persoonsgegevens. De leverancier voor alle data en de leden slechts voor de data van aanmeldingen die bij hun instelling gedaan zijn.
De rechten en rollen van de leverancier zijn gedekt door een ISO27000 certificaat. Het management van de Coöperatie is verantwoordelijk toe te zien dat dit certificaat alle voorzieningen voldoende dekt en een periodieke audit te houden.
Back-up en restore van de data en de systemen zijn de verantwoordelijkheid van de leverancier. Deze zijn gedekt door een ISO27000 certificaat en afgesproken door middel van SLA's. Het management van de Coöperatie is verantwoordelijk dat dit certificaat alle voorzieningen voldoende dekt of in geval van twijfel om een jaarlijkse audit te houden.
Alle aanmeldingen tot één jaar geleden kunnen binnen 48 uur opnieuw gezonden worden.
De broncode van de voorzieningen is eigendom van de Coöperatie en kan in geval van wisseling leverancier of faillissement van de leverancier direct opgevraagd worden.
De leden kunnen een contactpersoon opgeven voor de escalaties. Dit kan ook een helpdesk of ander groepsmailbox zijn. Om ervoor te zorgen dat niet alle leden deze verstoring hoeven te melden of op te letten wanneer het is opgelost is er een escalatie procedure.
Bij een gedeeltelijke verstoring zullen per e-mail de functioneel beheerders van de leden op de hoogte worden gesteld. Is het een escalatie omdat de gehele voorziening niet bereikbaar is kan ook via de telefoon, sms, app of gesprek, de escalatie in gang worden gezet. Elk uur tussen 7 uur in de morgen en 10 uur in de avond zal er een update verstuurd worden via de mail. Dit is de verantwoordelijkheid van de producteigenaar.
Per kalenderjaar wordt een actief verzoek gedaan om de gegevens van de contactpersonen per instelling up-to-date te houden. We kennen hierbij een viertal groepen. De bestuurder(s), de formele contactpersoon, de functioneel beheerder(s) en de functionaris gegevensbescherming van het lid.
Bij wisselingen gedurende het jaar is het lid zelf verantwoordelijk om correcties aan te brengen door middel van het melden hiervan via een e-mail naar xxxx@xxxxxxxxxxxxxxxx.xx. Het management van de Coöperatie is verantwoordelijk voor het (laten) uitvoeren van deze escalatieprocedure en de jaarlijkse update van de contact gegevens.
De Coöperatie verwerkt bij de uitvoering van haar dienstverlening persoonsgegevens. Hiervoor is een privacy statement beschikbaar en een reglement voor de functionaris gegevensbescherming
De leverancier van de voorziening bewaard de gegevens tot minimaal 1 jaar na indiening. Binnen 1 werkdag kunnen berichten opnieuw worden gezonden door de leverancier. Na de bewaartermijn wordt de data vernietigd.
De DAP komt tot stand door afstemming tussen het management van de Coöperatie en de contactpersonen van de leden die zijn aangedragen door het bestuur. Om een effectief en efficiënt overleg en besluitvorming te hebben rondom de DAP gelden de afspraken die in de volgende hoofdstukken uiteen zijn gezet.
Het is essentieel dat elke onderwijsinstelling een functioneel beheerder aangewezen heeft. De officiële contact personen zijn niet noodzakelijkerwijs de functioneel beheerders maar hebben wel een directe lijn hiermee.
8.2 De functioneel beheerders werkgroep
De afstemming tussen de algemeen manager en de product eigenaar van de Coöperatie en de functioneel beheerders- vindt plaats doormiddel van een meeting die minstens eenmaal per jaar plaatsvindt, of vaker indien gewenst.
Van de functioneel beheerders verwachten wij de verantwoordelijkheid voor:
• Functionele contacten tussen de Coöperatie en het lid waarbij belangrijk is dat ook andere interne rollen hun aandeel hebben in centraal aanmelden zoals communicatie, marketing, deelnemers administratie etc.
• Configuratie van centraal aanmelden voor de eigen instelling
• Deelnemen (actief of passief) aan de expertgroep
• Controleren van aangeboden opleidingen in DUO
• Contacten tussen de leverancier (Topicus) en het lid
• Contacten tussen de SIS leverancier en het lid