Waarom zou dat niet mogen? Security of Privacy staat hier los van.
De vraag zou eerder vanuit de techniek gesteld moeten worden.
Mag een ontwikkelaar in beide omgevingen zijn werkzaamheden doen?

Een ontwikkelaar heeft als het goed is een NDA getekend, of een geheimhoudings document. Of dit volgende is, is een tweede.

De vraag zou dus zijn, is de vraag vanuit de Techniek, of Privacy? En zoja waarom is deze vraag er?

Het betreft een vraag vanuit een MT.
Een aantal MT leden vroegen zichzelf dit af, zonder een achterliggende gedachte.

Na wat doorvragen gaat het zeker om deze vraag, "Mag een ontwikkelaar in beide omgevingen zijn werkzaamheden doen?"

Een NDA is getekend, ik ga me hier verder in verdiepen, om na te gaan of dit voldoende is.

THX

Wat is de insteek van je vraag, waarom zou dit *niet* mogen ? In een O/T/A omgeving hoor je trouwens helemaal geen privacy gevoelige data te hebben. En in de P omgeving heb je deze mogelijk wel.

Waarbij werknemers wel moeten werken met die data, om hun werkzaamheden uit te voeren, en daarbij bepaalde verplichtingen hebben, zoals geheimhouding.

Overigens hoeft een O/T/A/P omgeving niet perse privacy gevoelige data te bevatten (denk aan een voorraad beheer systeem bij een groothandel, om maar wat willekeurigs te pakken).

De vraag is zo generiek gesteld, dat er geen antwoord op te geven is. Je geeft geen uitleg of er sprake is van privacy gevoelige data, wat voor soort data indien dat het geval is, en evenmin of dergelijke informatie ook te vinden is in O/T/A omgevingen, en indien dat het geval is, waarom er privacy gevoelige data te vinden is in O/T/A.

Ik zou verwachten dat mijn gegevens bij bedrijven die mijn gegevens verwerken enkel in produktie gevonden kunnen worden. Mijn gegevens behoren niet in een ontwikkel, test of acceptatie omgeving. Daar werk je met fictieve data ?

Dit is nog eens geen smart vraag. Is je vraag vanuit Privacy (data) settings, of afscheiding tussen omgevingen. Vaak mag een developer bij bij productie komen, zodat ze niet zomaar dingen kunnen aanpassen.

Simpel: als in een omgeving (zoals T) potentieel privacygevoelige gegevens worden opgeslagen/getransporteerd/verwerkt, waar een specifiek persoon niet bij hoort te kunnen komen (bijv. door niet positief te zijn gescreend voor geautoriseerde toegang tot die gegevens), hoor je die persoon geen toegang te geven.

Bijv. een stagiëre kan best meehelpen met ontwikkelen van een systeem met patiëntgegevens, maar indien echte data wordt gebruikt voor testen, hoort die stagiëre daar niet bij te kunnen (ervan uitgaande dat deze niet positief gescreend is voor dat doel).

Nog simpeler - een T omgeving behoort geen privacy gevoelige data te bevatten, maar dummy data. Klanten geven je hun gegevens niet af met de doelstelling om deze te gebruiken in ontwikkel, test af acceptatie omgevingen. Derhalve mag je deze data dan ook niet hiervoor gebruiken.


Werknemer of stagiaire, screening of geen screening. Weinig relevant, aangezien je echte data niet in test omgevingen hoort te gebruiken. Wat doet patient data in hemelsnaam in een andere omgeving, dan produktie ?....

Voor het MT van de vraagsteller -


Het verbod op het gebruik van privacy gevoelige data in test omgevingen (behoudens situaties waar de klant hiervoor toestemming heeft verleend) lijkt mij vrij duidelijk. Het is in strijd met de wet - en je kan er flinke boetes voor krijgen.

@Bitwiper: Sinds wanneer mag je privacy gevoelige klant data gebruiken in een T omgeving ?

Zoals eerder en vaker vermeld hoort O/T/A geen privacy data te bevatten.

Omgekeerd horen O/T omgevingen door devs benaderd te kunnen worden, en A/P omgevingen niet. Daarmee realiseer je de scheiding zoals die ooit bedacht is, zowel voor security als privacy redenen.

Lastiger wordt het in devops omgevingen, waar ops wel toegang kan geven aan dev voor A/P maar onder strikte begeleiding.

Voor: afhankelijk van hoe goed je gesimuleerde testdata is, levert echte data vaak betrouwbaarder (en, in mijn ervaring, onverwachte) testresultaten op.

Tegen: risico op ongeautoriseerde toegang tot die privacygevoelige gegevens. Echter, als de T omgeving volstrekt gescheiden is van de P omgeving (en van internet natuurlijk, iets dat regelmatig vergeten wordt), en iedereen met toegang tot het T systeem is geautoriseerd om die gegevens in te zien, en er ordentelijke maatregelen zijn getroffen voor het verwijderen van bedoelde gegevens na de tests en/of bij afvoer van apparatuur, is dat risico beperkt. Nb. als T onvoldoende gescheiden is van P, is privacy niet je enige zorg (testdata, al dan niet echt, kan P dan vervuilen).

Het is een kwestie van een afweging of het restrisico acceptabel is voor de uitvoerende organisatie.

Otap dtap is een beladen iets.
In de klassieke waterval cobol (java phyton) methode ga je vanuit een functioneel ontwerp iets bouwen wat naar productie gaat.
Dan hebben we het over code / business logica. Indien de programma's niets bijzonders bevatten, zeg maar open source,
dan is er geen enkele reden om de TAP versies voor de programmeurs als read-only beschikbaar te stellen.
In dat geval kun je het onderhoud vereenvoudigen door enkel die modules in onderhoud te geven die onderhouden moeten worden. De pc aanpak is alle code naar de betreffende persoon te kopiëren (ook de tap versies) en later uit te zoeken wat veranderd is.

De aanpak met de data is anders in deze Java werkwijze. De programmeur moet zijn eigen testdata maar zien samen te stellen evenals de tester. Het gevaar met toegan tot prod data is dat ze deze als testdata gaan gebruiken. Voorhanden en snel geregeld. Dan krijg je testprints etc met echte data. Dat wil je voorkomen.
Een programmeur voor project A kan wel de rol van tester in een heel ander iets vervullen. Hij kan ook regulier ofwel p werk doen. Met devops scrum is de aanname dat het gebeurt.
Je zult dd balances en checks voor kwaliteit moeten afdekken.

Heel anders is het met analytics big data. De modellen kun je alleen bouwen met productiegegevens. Je moet de klassiek dtap cobol denkwijze loslaten. Het modelleren zou wel zonder privacy gevoelige data moeten kunnen waar het exploiteren van de modellen juist alles raakt.
Dat betekent dat je meerdere data concepten aan moet kunnen.

Je hebt net alle analyse omgevingen evenals de verplichte opleverinlg van jaarrapportages als verboden verklaard. Dat klopt niet.
Kijk eens naar de iso27k richtlijnen. Functiescheiding en data governance zijn de zaken waar intern conform die hoog over doelen richtlijnen voor gemaakt moeten worden.

Het enige belangrijke is vaak dat je zo min mogelijk mensen toegang wil geven tot de data van de P.
Als je echte gebruikersdata (niet geanonimiseerd) gebruikt in T of A ben je verkeerd bezig als bedrijf.

Wat bazel je? Developers mogen werken in de O en T omgeving. De A omgeving wil je productielike houden. Developers hebben hier niks te zoeken, behalve misschien meekijken met de business acceptanten/testers. Wanneer je je beleid t.a.v. testdate op orde hebt, heb je voor elke omgeving een correct set aan testdata die je kan gebruiken (dummy data, of voldoende geanonimiseerd). Dit is niet de verantwoordelijkheid van de developer. Wanneer je vanuit verschillende rollen toch toegang tot P moet hebben zal je moeten borgen dat data uit P nergens anders wordt gebruikt, dan alleen voor het nodige (onderhoud, support) binnen de P-omgeving. Hiervoor dien je beleid vast te leggen en bijvoorbeeld een NDA te laten ondertekenen.

Als de vraag vanuit het MT komt, gewoon negeren totdat ze komen met specifieke vragen waar een passend antwoord op te geven is zonder dat je de vraag moet beantwoorden met alle mogelijkheden die de MT vraag kan bevatten.

Als je tijd hebt voor zulke vragen is er niet genoeg werk :-)

Hangt wel erg af van de vraag hoe groot een organisatie is, en hoeveel mensen je hebt. In grote organisaties gaat dit allemaal wellicht op; in kleinere bedrijven met 1 of 2 developers heb je al snel meerdere petten op. Overigens is het weinig constructief denigrerende taal te gebruiken, zoals ''wat bazel je''.

Privacy gevoelige gegevens van klanten mogen enkel gebruiken voor het doel waarvoor je deze verkregen hebt. Klanten staan deze gegevens niet af met als doel dat deze gebruikt kunnen worden in test omgevingen. En dus is het niet conform de wet (art. 8 en 9 Wbp).

Iso richtlijnen, functiescheiding en dergelijke hebben daar verder bar weinig mee van doen. Voor het opleveren van jaarrapportages hoef je ook niet op de wet te overtreden; sinds wanneer heb je privacy gevoelige klant data nodig in een test omgeving, om een jaarrapportage op te kunnen leveren ?


En dus mag je de wet overtreden ? Echte data kan je anonimiseren.


En het juridische risico, wanneer je de wet overtreed, neem je dat ook mee in je overweging ?

AP / WPB / GDPR (Ja die is WEL live je kan er alleen niet voor vervolgd worden tot mei 2018) heeft eerder aangegeven dat productie data niet in een testomgeving mag worden gebruikt. ISO 27001 is maar een framework.. en geen wet.

Eminus

En zo heb ik ook geantwoordt naar het MT.
Toch goed om te zien wat zo'n vraag teweeg brengt.

De uiteindelijk vraag was, "mogen mijn ontwikkelaars naast toegang tot O&T ook kijken op A&P?"
Dat antwoordt was heel duidelijk....NEE.
Dit wordt netjes geregeld doormiddel van een RBAC.

k heb niet zo goede ervaringen met MT dat dit soort fundamentele vragen stelt.

het gevaar is dat er een of ander besluit du-jour genomen wordt waarbij de organisatie jaren lang aan vast gaat zitten ook al veranderen situaties en tijden. procedures gaan dan de overhand hebben tov kwaliteit en het werkelijke doel: operatie geslaagd, patient overleden.

ik ken namelijk zo een IT omgeving die met beperkt overzicht en begrip van de diverse werkzaamheden in academia door MT van IT vastgelegd is en toen ze bij een andere faculteit kwamen paste het beeld niet meer met een jaren lange worsteling tussen de IT met die strigente visie en de accademici waar het om zou moeten gaan tot gevolg. de IT dwingt nu vaak effectief af welk onderzoek plaats vindt vanwegen hun gekozen strategie en regels en niet de prof of een wetenschappelijk directeur meer. elke verandering kost maanden vergader en beslis tijd bij IT mensen die niet zelf werkzaam zijn of ervaring hebben in het veld en bovenal ook niet met die onderzoeker in gesprek gaat. en dat allemaal omdat een paar jaar geleden een harde beperkte keuze is gemaakt vanuit IT. een dit of niets anders keuze daarin. leuk een meet apparaat van een miljoen die inet eenvoudig te vervangen is, maar ja geen windows versie weet-ik-wat, dus hoe jij je meet gegevens dan weer op je desktop krijgt waar je papers schijft? we noemen dat de werkt-niet-plek onderling :).

dus kijk uit met MT beslissingen die over techniek gaan voor een langere tijd in grote diverse organisaties.

Nu maar hopen dat het duidelijke antwoord niet meer schade veroorzaakt dan het oplost. Bijvoorbeeld omdat er een bepaalde bedoeling achter zat. Oplossing shadow ict in de cloud.

Sorry linkjes ontbreken, wat jij maar een framewerk noemt http://www.toezicht.dnb.nl/3/50-203304.jsp# , https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/rs/rs_2013_richtsnoeren-beveiliging-persoonsgegevens.pdf pag14 onderaan. 2.5 en je krijgt ncsc en nen7510. Het zijn bijna wetboek verplichtingen.
Internationaal https://www.bsi.bund.de/DE/Themen/ZertifizierungundAnerkennung/Managementsystemzertifizierung/Zertifizierung27001/GS_Zertifizierung_node.html

Van de gdpr is de tekst http://eur-lex.europa.eu/legal-content/NL/TXT/?uri=OJ:L:2016:119:TOC artikel 28 en 32 hebben het over ict security in een zeer globale insteek waarbij je vanzelf waar bij iso27k uitkomt. Das AP en GDPR zeggen niets over ICT invullingen.
Stokpaardjes wegens "het moet van SOX" in de herhaling is niet leuk.

Als je de iso27k kent zul je zien dat er globale richtlijnen van een insteek gegeven worden nergens iets over een exacte technische invulling. Ik ben benieuwd naar jouw links/referenties.

Links en referenties naar de wetgeving zijn hierboven reeds gegeven. Als je benieuwd bent, neem dan de moeite daarnaar te kijken, en op die links en referenties in te gaan....

Waarom jij door blijft gaat over Iso27k in relatie tot zaken die wettelijk simpelweg niet zijn toegestaan, beats me. Mensen moeten zich simpelweg houden aan de wet op dit gebied, zoals vastgelegd in art. 8 en 9 Wbp.

Verder kan je data anonimiseren, zodat er geen sprake meer is van persoonsgegevens, alvorens je data gaat gebruiken in O, T, A omgevingen. Conform de richtlijnen waar jij naar refereert.

Ehm, als jij bezig bent met een ICT invulling, zoals je dat noemt, dan is de wet nog altijd van kracht. Het overtreden van deze wetgeving kan ook tot behoorlijke boetes leiden. Wetten zijn niet relatief, en kan je niet aan de kant schuiven omdat deze je bij een ICT implementatie in de weg zitten.


Niemand noemt SOX in deze discussie behalve jijzelf. Wel worden er wetten genoemd. Indien jij implicaties van wetgeving niet leuk vind, dan moet je dat natuurlijk geheel zelf weten.

Verder lijk je geen aandacht te besteden aan de maatregelen die je kunt nemen om data te anonimiseren, waardoor je gerust kunt testen zonder dat je in overtreding bent van de WBP. Dat is gewoon de juiste weg, legaal en proportioneel.

Volgens mij wat bedoelt wordt.... De AD of GDPR zeggen niets over de technische oplossing. Wat voor een ecryptie je gebruikt, maakt voor de wetten niet uit. Zolang het maar toegepast is/wordt.

Dat jij de wettelijke voorschiften moet volgens is heel iets anders.

Ik heb het genoemd omdat ICT ers geneigd zijn hun eigen idee door te drijven met verwijzing naar hyped richtlijnen ook al staat er daar bij de genoemde richtlijnen niets over in.
Sox en met name paragraaf 404 zegt iets over inrichten van Ict omgeving. De financiële gegevens zijn gevoelige productiegegevens waar de nodige onderbouwing intern voor gedaan wordt. Dan praat je of je over retention policies herkomst bron bewijs afscherming ofwel rbac etc. In de praktijk is het vaak hap snap Excel werk totdat het management het goed vind. Otap scheiding lukt niet eens. https://nl.wikipedia.org/wiki/Sarbanes-Oxley
"Een bijzondere plaats in het geheel neemt de IT in. IT is geen direct doel van SOx, dat is interne controle, maar in die interne controle speelt de IT een centrale rol." En dat is prima verwoord.

Met GDPR WBP heb je het over gevoelige persoonsgegevens. Dat staat op zich los van OTAP doosjes plaatsen.
De doosjeschuivers halen het er wel bij want het verdient goed. Je komt in de picture voor promotie. Het heeft zo helaas niets met wetgeving via GDPR te maken.


Ik heb de links gegeven met de richtlijnen. Deze is van het WBP http://wetten.overheid.nl/BWBR0011468/2017-07-01 Nergens iets dat OTAP gebonden is aan een afscherming van persoonsgegevens. Sterker die regels zijn juist van toepassing op de reguliere productieverwerking. Artikel 7 is voordat je over een SDLC mag gaan nadenken, je begint er niet eens aan, dat gaat verder in de volgende totdat je artikel 13 ziet. "-- legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen --" gangbare norm voor dat vastleggen en passend is nu net de ISO27k reeks.

Je advies is prima, nu nog de invulling/uitwerking.

Kijken we naar marketing big data analytics dan moet je beseffen dat modellen bouwen ontwikkelen alleen met productie data kan. Zijn het metingen van b.v een spoorwissel dan valt dat buiten GDPR. Zijn het adviezen van AH voor het persoonlojke boodschappenmandje dan heeft dat alles met GDPR te maken. In beide gevallen gaat het om productiegegevens.

Kijk even mijn eerder post na. Data modellering kan je op een data lake zonder persoonsgegevens doen. De voorwaarde is een vooraf aangebrachte juiste koppeling op de vermoedelijke persoon.is aangebracht (even los van herleidbaarheid naar de persoon uit de data)
Het uiteindelijke advies is gewoon op de persoon gericht en kan je niet anoniem doen. Dat betekent scheiding in je data governance met Analytics voor die twee data fases. Toch moet ze wat structuur betreft identiek zijn. Een dooddoener dat het dan maar in Java herbouwd moet worden faalt.

Als vreemde eend voor de cobol/java kloppers is analytics nou niet bepaald goed in ict gedragen. De klassieke ict mentaliteit veroorzaakt juist de problemen in die hoek. Ze (marketing big data)zoeken dan zelf wel iets in de Cloud met open source etc., Denk eens aan MongoDB. Denk eens aan de financiële crisis waar geen enkel bank wist wat er nu intern aanwezig was .... Ik verwijt het de big data mensen niet ik wijt heet aan de onaangepaste houding van de ict.

Het gaat in dit stadium ook niet zo zeer om persoonsgegevens als wel het feit dat je graag wilt kunnen zien wie wat wanneer heeft aangepast. Dit heeft betrekking op de betrouwbaarheid van de op te leveren systemen.
ISO27k zegt daarover duidelijk "Gebruikers behoren verschillende gebruiksprofielen voor operationele en proefsystemen te gebruiken, en de menu's behoren de juiste identificatieboodschappen te tonen om het risico op fouten te verminderen"
Kortom: het mag best wel, maar zorg dat 1. voor elke gebruiker is bepaald wanneer hij/zij toegang tot waar mag hebben en 2. er per omgeving een aparte inlog is. Op die manier scheidt je verschillende functies en is bij problemen later makkelijker terug te zoeken wie wat wanneer heeft gedaan.

Zie artikel 9 in de wet die je aanhaalt. Het verwerken van persoonsgegevens in OTA is niet het doel waarvoor persoonsgegevens zijn verkregen, en daardoor is deze verwerking in principe strijdig met deze wetgeving.

Dat er niets staat over afscherming van persoonsgegevens in OTA klopt; deze horen er in principe immers niet thuis. Jij lijkt bij voorbaat uit te gaan van het idee dat je wel persoonsgegevens mag verwerken in OTA, en zoekt vervolgens naar informatie over het afschermen daarvan ?

Dat volgt helemaal niet .

Een OTA omgeving heeft exact hetzelfde doel als de productie omgeving - het leveren/ondersteunen van een bepaalde dienst.

Je mag alleen geen *andere* dienst voeden met die persoonsgegevens - je hebt een bankrekening gekregen om te betalen - je mag het rekeningnummer niet gebruiken als unieke klant-tracker .

Je geeft een mening als vaststaand feit zonder referenties of onderbouwing of iets met redenering. Laten we eens kijken.

Je noemt de Ict dienstverlening voor een OTA P maar zegt niets wat dat dan zou kunnen zijn.
Gewoon administratief heb al:
1/ de klassieke cobol/java bouw met een vooraf bedacht functioneel en technisch ontwerp van een lopende band proces.
2/ het analyseren van wat er gebeurt is en wat er zou kunnen gebeuren. Ofwel reporting analytics. Het is vaak eenmalig en wat er ontwikkeld is is dan meteen produktie.
3/ vastlegging hr , boekhouding financials, email en andere productiviteitstools het zijn andere bedrijsprocessen met een compleet ander dienstenmodel.
Ga je naar technische systemen wetenschapoelijk onderzoek en meer dan kom je weer met compleet andere diensten.
Als je de diensten en bedrijfsdoelen niet kent of niet eens snapt dan wordt je er vanzelf een bedreiging voor.

Neem een pinbetaling als voorbeeld. Daarbij mogen rekeninggegevens alleen gebruikt worden om die betaling af te handelen, dat is vaak genoeg nadrukkelijk zo gesteld. Het testen van de software die de betaling afhandelt is iets anders dan het afhandelen van de betaling waarvoor de rekeninggegevens verkregen zijn. Daar mag je die gegevens dus niet voor gebruiken. En er is ook geen noodzaak toe omdat er heel goed met fictieve of geanonimiseerde gegevens getest kan worden.

Jij hebt de neiging om het doel zo ruim op te vatten dat wat je met gegevens wilt doen erbinnen valt. Daar moet je voorzichtig mee zijn, als je een beetje volgt hoe de AP in concrete zaken redeneert dan zie je dat er juist een behoorlijk krappe opvatting wordt gehanteerd. Je doet er goed aan om dat ook te doen, anders kan je voor dure verrassingen komen te staan.

Exact. Dat staat omschreven als 'doelbinding' en wordt nog strakker geregeld in de GDPR, waar voor ieder doel bewijsbare toestemming moet zijn van de klant. Daar valt testen/ontwikkelen met zekerheid niet onder.

Nope fout.
Je neemt aan dat de ontwikkelaar/bouwer als doel heeft persoonsgegevens uit productie naar zijn ontwikkel test omgeving te kopiëren. Doelbinding heeft niets met otap te maken maar met gegevensverwerking in p.

Een gebruiker uit productie moet je zeker vragen om mee te draaien bij acceptatietesten. Het heet niet voor niets gebruikers acceptatietesten. Doe dat niet met dezelfde accounts en niet met de zelfde systeem aanduidingen om verwisseling uit te sluiten.

Een bouwer onwikkelaar moet je zeker laten meedraaien in testen en operatie devops is daaruit voortgekomen. Alleen aanpassen code in productie mag niet net zo min als ongecontroleerd overhalen van data op wat voor manier dan ook. Gebruik dan ook aparte meerdere accouns per gebruiker in die situaties.

Grappig dat je het beter denkt te weten dan een auditor en specialist op GDPR gebied... Ja, ik ben IT auditor.

De doelbinding bestaat niet in OTA omdat daar geen toestemming voor is gegeven. Je zit fout. De constructie die je bedacht hebt zou door mij worden afgekeurd.

jeetje wat heb je hier eigenlijk een boel 'eigenwijze systeembeestjes' ;-)

Maar verder best schokkend om te lezen hoeveel IT afdelingen hun bedrijfsbelang (goede maar vooral goedkope testdata) kennelijk laten prefereren op het algemene belang (geen ongeoorloofd gebruik van klantgegevens maken/privacy klant waarborgen/ je houden aan bestaande wet en regelgeving)

ja en ze hebben allemaal een das om, snel op ego getrapt, vlotte bak euh bek, enzo meer. cowboys galore!

maar dat is ook niet verbazingwekkend allemaal, als je eens afvraagt waarom er een concept als mode en adverteren bestaat!

schone schijn glimmende kraatjes en spiegels het werkt echt wel als mensen onbewust zijn over wat zaken. hoeveel denken er bijvoorbeeld te kunnen fietsen en smsen tegelijk? je zou ze eens moeten filmen en confronteren met de beelden. een hele hoop mensen kunnen hun mobiel niet eens drie dagen uit in een kast leggen!

Je mag dan IT auditor zij, je mist de IT proces zaken. Ooit de goedkeuring meegemaakt door dat soort mensen van een backup proces waar er geen Backup was. Ja dat programma startte maar dat was nadat alle data om te backuppen verwijderd was. Dat liep veel sneller. Met KPMG EY en ander audit schandalen zou ik wat minder op dat "want ik ben auditor" strepen staan.

Geef mij eens aan welke constructie ik verzonnen zou hebben die niet aan gdpr zou voldoen.
Waar ik het gewoonlijk over heb is een gedegen functiescheiding d.m.v. serviceaccounts testaccounts beheerdersaccounts waarbij een persoon meerdere accounts gebruikt afhankelijk van type werk. Geen van die accounts is in staat om over die muren heen data uit te wisselen buiten geaccordeerde beschreven interfaces.
Dat is geheel volgens cobit iso27k etc.

In de devops aanpak "you build it, you run it". Wat bij elke grote organisatie tegenqoordig gangbaar is dankzij accountancy adviezen, )zul je dat minder aantreffen.
Dat is niet verzonnen door mij.

Nogmaals een OTA proces en een gdpr zijn verschillende zaken. Ik zou zeggen ga een bij een audit afdeling kijken hoe die werken. Een OTA process, ze zouden niet weten hoe.

grappig he dat iemand altijd alles over alles beter weet, analytics, big data, python versus r, iso standaarden galore, fijloos weet wanneer iemand 'in een doosje vast zit', met veel groot praat reageerd, op de stoel van een ceo cio denkt te zitten, de wetgever en auditors nu eventje gaat vertellen hoe de wereld in elkaar zit :). ik zou zijn/haar partner wel eens willen spreken, die moet zeeen van begrip en geduld hebben en daar kunnen we misschien allemaal nog wat van leren!

Hallo beiden, wat praten jullie langs elkaar heen. JULLIE ZIJN HET MET ELKAAR EENS!!!

Anoniem (die op mij reageerde) bevestigde dat doelbinding NIET op OTA betrekking heeft. Net wat karma4 na het "fout" te noemen ook schrijft. Waar Anoniem weer in leest dat karma4 zou vinden dat doelbinding wel op OTA betrekking heeft, wat hij dus juist niet vindt. Reageer allebei niet als een stier op een rode lap op woordjes als "fout", alsjeblieft (en gebruik ze ook niet te snel), maar laat alsjeblieft even doordringen wat de ander schrijft en reageer daarop, en niet op wat je in je haast om te reageren denkt dat er staat.

Oeps sorry en bedankt voor je karma achtige reactie.

Sooo heee, dat je DAT durft toe te geven !