Een beoordeling van gebruikersroutes
Privacyvragen bij de afgesproken schermen en handelingen, gekoppeld aan doelen, gegevens en betrokken rollen. Aannames en ontbrekende productinformatie blijven zichtbaar.
Privacy · Een gerichte opdracht
Privacy by design voor uw klantenportaal?
Maak het concreet vóór de lancering.
Een nieuw klantenportaal moet prettig werken én zorgvuldig omgaan met persoonsgegevens. Datajuristen helpt producteigenaar, ontwikkelaars en privacyverantwoordelijke de belangrijkste keuzes op tijd maken. U ontvangt concrete ontwerpvragen en acceptatiecriteria die het team kan meenemen in de bouw en controle.
Voorstel op maat · Werkzaamheden en kosten vooraf afgesproken
Voor producteigenarenTijdens ontwerp of herbouwVoor concrete privacy-eisen
Duidelijk afgebakend
Dit is waar we naartoe werken.
Voor een organisatie die een klantenportaal laat ontwerpen, bouwen of wezenlijk aanpassen. Deze opdracht richt zich op de verwerking in concrete gebruikersroutes. Het is geen algemene privacyverklaring, softwarecertificering of vervanging van een technische beveiligingstest.
Eisen voor ontwerp en acceptatie
Concrete criteria voor de geselecteerde onderdelen, met voorgestelde maatregelen en een intern aanspreekpunt. Uw projectteam kan ze koppelen aan bouwtaken en testscenario’s.
Een overzicht voor de lancering
Open besluiten, resterende risico’s en afgesproken vervolgacties. Waar inbegrepen beoordelen we aangeleverde onderbouwing van de opgevolgde privacycriteria.
Vooraf spreken we af welke functies, versies, gesprekken en controles worden meegenomen, met planning en prijs. Softwareontwikkeling, pentesten en volledige technische verificatie zijn niet automatisch inbegrepen. Het advies gaat over de onderzochte toepassing; latere wijzigingen kunnen herbeoordeling vragen.
Begin met de handelingen, niet met een algemene checklist
Een klant die een adres wijzigt, heeft iets anders nodig dan een gemachtigde die een dossier bekijkt. We volgen de afgesproken gebruikersroutes en bespreken waar informatie wordt gevraagd, getoond, gedeeld of bewaard. Dat maakt zichtbaar welke ontwerpkeuzes voor deze toepassing relevant zijn.
Privacy by design en privacyvriendelijke standaardinstellingen vragen aandacht tijdens het ontwerp en gebruik. In deze opdracht maken we dat praktisch: welke velden zijn noodzakelijk, welke informatie staat standaard open en welke keuzemogelijkheden werken daadwerkelijk? Een privacytekst aan het einde van het project kan die ontwerpbeslissingen niet zelfstandig oplossen.
- Aanmelden, account herstellen en gegevens wijzigen.
- Documenten bekijken, downloaden en uploaden.
- Een gemachtigde toevoegen of verwijderen.
- Notificaties ontvangen en voorkeuren aanpassen.
Toegang beschrijven vanuit herkenbare situaties
Een rollenmatrix wordt pas bruikbaar wanneer iemand haar kan toetsen aan het dagelijks werk. Kan een medewerker meerdere klantdossiers bekijken? Wat gebeurt er na een wijziging van een zakelijke contactpersoon? Wie kan handelen namens een klant, en hoe wordt het einde van die bevoegdheid verwerkt? We helpen zulke vragen omzetten naar concrete scenario’s.
Daarbij bespreken we ook informatie die buiten het scherm terechtkomt. Een notificatie met dossierdetails kan op een gedeeld apparaat verschijnen. Een download kan langer beschikbaar blijven dan het account. Dit zijn ontwerpvragen die product, privacy en security samen moeten beoordelen. Technische keuzes worden door de betrokken deskundigen bevestigd en getest.
- Een gewone gebruiker ziet alleen de bedoelde gegevens.
- Een ingetrokken machtiging werkt door in toegang en actieve sessies.
- Beheerhandelingen hebben een duidelijke eigenaar.
- Berichten tonen alleen de informatie die voor die route nodig is.
Privacycriteria meenemen in het besluit over lancering
Tijdens de bouw verandert vaak de scope. Een extra koppeling, nieuw uploadveld of analysefunctie kan de oorspronkelijke beoordeling raken. We spreken daarom af welke productversie wordt beoordeeld en welke wijzigingen opnieuw aandacht vragen. Dat geeft het team een duidelijker uitgangspunt dan een eenmalige algemene goedkeuring.
Voor de lancering brengen we de overeengekomen privacycriteria, beschikbare controle-uitkomsten en open besluiten bijeen. We geven aan wat is onderzocht en wat nog niet is aangetoond. Het management of de aangewezen productverantwoordelijke neemt het gebruiksbesluit. Als een DPIA nodig blijkt, spreken we af hoe dat afzonderlijke traject op het project aansluit.
- Acceptatiecriteria koppelen aan concrete functies.
- Geplande maatregelen onderscheiden van uitgevoerde maatregelen.
- Bewaar- en verwijdergedrag meenemen in de werking van het portaal.
- Een verantwoordelijke aanwijzen voor wijzigingen na de lancering.
Herkenbare situatie · illustratief voorbeeld
Een gemachtigde blijft toegang houden na intrekking.
In dit illustratieve voorbeeld kan een klant een gemachtigde verwijderen, maar blijft een eerdere sessie actief. De privacybespreking vertaalt de bedoelde bevoegdheid naar een concreet testscenario. Het ontwikkelteam moet vervolgens bepalen en controleren hoe intrekking in de techniek doorwerkt.
- 01Gebruikersroutes en doelen
- 02Eisen en ontwerpkeuzes
- 03Controle en besluitvorming
Van eerste gesprek naar aanpak
Begin met de vraag.
Wij helpen ordenen.
Beschrijf voor wie het portaal bedoeld is, welke functies worden gebouwd en in welke projectfase u zit. Een procesplaat, prototype zonder persoonsgegevens en globale planning helpen bij de intake. Deel geen klantdossiers, toegangsgegevens of productietoegang via het contactformulier.
Bespreek uw klantenportaal- 01
We maken de vraag concreet
We bespreken uw doel, de betrokken mensen en wat al beschikbaar is.
- 02
U krijgt een afgebakend voorstel
Met werkzaamheden, benodigde informatie, planning en kosten.
- 03
We bespreken de bevindingen
U weet welke keuzes voorliggen, wat nog ontbreekt en welke vervolgstappen passen.
Goed om vooraf te weten
Uw vragen.
Helder beantwoord.
Op welk moment in het project is deze beoordeling zinvol?
Zodra doelen en eerste gebruikersroutes bekend zijn, kunt u privacykeuzes meenemen voordat ze lastig aanpasbaar worden. Bij een bestaand prototype spreken we af welke onderdelen nog kunnen worden gewijzigd en welke besluiten prioriteit hebben.
Is een privacyverklaring voldoende voor ons portaal?
Nee. Informatie aan gebruikers is een onderdeel van de verwerking. Daarnaast moeten onder meer doelen, gegevenskeuze, toegang en instellingen worden beoordeeld. Een tekst kan niet vervangen dat functies en werkprocessen passend worden ingericht.
Krijgen ontwikkelaars concrete taken?
De afgesproken uitwerking bevat criteria en beslispunten die naar bouwtaken kunnen worden vertaald. We beschrijven het gewenste gedrag en de onderliggende privacyvraag. De technische oplossing en uitvoeringsplanning stemt u af met uw ontwikkelteam.
Testen jullie of gebruikers elkaars gegevens kunnen zien?
We kunnen daarvoor een privacycriterium en testscenario helpen formuleren. Een daadwerkelijke beveiligingstest of codeonderzoek is een afzonderlijke technische activiteit en moet expliciet worden afgesproken. We presenteren een documentbeoordeling niet als geslaagde penetratietest.
Is voor een klantenportaal altijd een DPIA verplicht?
Nee. De functies, gegevens, omvang en gevolgen bepalen of waarschijnlijk hoge privacyrisico’s bestaan. We kunnen een drempelbeoordeling afspreken. Een volledige DPIA en eventuele aanvullende maatregelen worden vervolgens afzonderlijk ingepland.
Wat kost privacy by design begeleiding?
De inzet hangt af van de gebruikersroutes, projectfase, documentatie en gewenste terugkoppelmomenten. U ontvangt een voorstel met de afbakening, planning en prijs. Een eenmalige ontwerpbeoordeling is een andere opdracht dan begeleiding gedurende meerdere ontwikkelrondes.
Bronnen bij deze uitleg · geraadpleegd 25 september 2026EDPB · privacy by design en privacy by default AVG · artikel 25 en bescherming door ontwerp en standaardinstellingen