Een NDA regelt vertrouwelijkheid. De overeenkomst bepaalt niet wie toegang krijgt tot de productieomgeving, of een developer klantgegevens mag downloaden of hoe snel toegang wordt ingetrokken wanneer een samenwerking eindigt. Die controles moeten vóór de eerste sprint zijn ingericht.
IT staff augmentation security omvat de contractuele, technische en operationele controles die bepalen hoe externe developers toegang krijgen tot code, systemen en persoonsgegevens, terwijl de klant de dagelijkse delivery aanstuurt. In een veilige samenwerking heeft ieder toegangsrecht een eigenaar, iedere uitzondering een goedkeuringsroute en iedere securityclaim bewijs dat de klant kan controleren.
TL;DR
- Veilige IT staff augmentation vereist rolgebaseerde toegang, beheerde identiteiten, peer review, incidentescalatie en geteste offboarding vóór de eerste sprint.
- AVG Artikel 28 is van toepassing wanneer de provider als verwerker optreedt. Toegang tot gegevens tussen Nederland en Vietnam kan ook waarborgen uit Hoofdstuk V vereisen, zoals Standard Contractual Clauses (SCC’s).
- ISO/IEC 27001-certificering ondersteunt de leveranciersbeoordeling alleen wanneer het certificaat actueel is, de scope de deliveryorganisatie omvat en de leverancier operationeel bewijs kan tonen.
Wat veilige IT staff augmentation vereist
Veilige IT staff augmentation vereist vóór onboarding een schriftelijke verdeling van verantwoordelijkheden. De klant moet bevoegd blijven voor dataclassificatie, architectuur, goedkeuring van toegang, productiereleases en risicoacceptatie. De provider moet eindverantwoordelijk zijn voor de mensen, devices en het operationele bewijs waarover de provider controle heeft.
Die verdeling is belangrijk omdat staff augmentation verschilt van managed outsourcing. Externe engineers sluiten aan op het deliverysysteem van de klant en werken volgens de prioriteiten van de klant. Als u het model zelf nog definieert, legt de volledige gids over IT staff augmentation de verschillen in controle en management uit.
Een werkbaar verantwoordelijkheidsmodel heeft drie lagen:
- Beslissingen van de klant: welke repositories en omgevingen de rol nodig heeft, of toegang tot productie is toegestaan, welke gegevenscategorieën mogen worden gebruikt, wie uitzonderingen accepteert en wie een inbreuk op persoonsgegevens meldt bij de toezichthouder.
- Controles van de leverancier: identiteitsverificatie, geheimhoudingsverplichtingen, securitytraining, controles voor beheerde devices, joiner- en leaverprocessen en tijdige escalatie wanneer personeel of systemen van de leverancier bij een incident zijn betrokken.
- Gedeelde operationele controles: code review, regels voor veilige ontwikkeling, incidentoefeningen, toegangsreviews, bewijsverzameling en bevestiging van offboarding.
De klant kan de verantwoordelijkheid voor de eigen systemen niet uitbesteden. De provider kan security niet als uitsluitend een probleem van de klant behandelen omdat de klant het dagelijkse werk aanstuurt. Gebruik vóór ondertekening een brede checklist voor staff augmentation providers om de commerciële en operationele fit te bevestigen. Pas daarna de security evidence matrix verderop in deze gids toe.
Het toegangsmodel: wie krijgt toegang tot wat?
Het toegangsmodel moet iedere bevoegdheid koppelen aan een benoemde rol, systeemeigenaar en vervalvoorwaarde. ‘Developertoegang’ is te breed. Een backend engineer heeft mogelijk een broncoderepository, een ontwikkeldatabase en geselecteerde logs nodig, maar geen permanente toegang tot facturatiegegevens of de productieconsole.
Begin met vier toegangszones: collaboration tools, broncode en CI/CD, niet-productie-infrastructuur en productie of gevoelige gegevens. Documenteer voor iedere zone de toegestane rol, authenticatiemethode, verantwoordelijke voor goedkeuring, loggingvereiste en trigger voor intrekking.
Vijf controles doen het meeste werk:
- Geef iedere persoon een individuele identiteit. Gedeelde accounts maken toeschrijving onmogelijk en offboarding onbetrouwbaar.
- Verplicht SSO en multi-factor authentication wanneer het platform deze ondersteunt. Gebruik voor privileged access een afzonderlijke beheerdersidentiteit.
- Sta standaard geen toegang tot productie toe. Verleen tijdgebonden toegang voor een goedgekeurde taak wanneer productiewerk noodzakelijk is.
- Bewaar secrets buiten broncode en lokale bestanden. Gebruik een goedgekeurde secrets manager en leg vast wie ieder secret mag ophalen.
- Review toegang na iedere rolwijziging en minstens ieder kwartaal bij langdurige samenwerkingen. Trek toegang op het afgesproken eindtijdstip in en leg daarna de voltooiing vast.
Toegangsbeheer is ook afhankelijk van teamroutines. De engineering lead van de klant moet weten wie pull requests goedkeurt, wie pipelineregels mag wijzigen en waar uitzonderingen worden vastgelegd. De gids over het managen van augmented IT-teams behandelt eigenaarschap en de reviewfrequentie na onboarding.
AVG en verplichtingen van de verwerker
AVG-verplichtingen hangen af van de feitelijke verwerkingsrelatie, niet van het label ‘staff augmentation’. Bepaal eerst of de provider namens de klant persoonsgegevens verwerkt of uitsluitend personeel levert dat onder het directe gezag van de klant werkt.
De richtlijnen van de European Data Protection Board voor verwerkingsverantwoordelijken en verwerkers leggen uit dat deze rollen voortkomen uit de werkelijke activiteiten en besluitvorming van de partijen. Een leverancier wordt niet automatisch verwerker omdat een medewerker aan een sprint deelneemt. De leverancier kan wel verwerker zijn wanneer de organisatie persoonsgegevens voor de klant verwerkt volgens gedocumenteerde instructies. Legal- en privacyteams moeten de rol bevestigen voordat het contract wordt ondertekend.
Wanneer de provider verwerker is, vereist AVG Artikel 28 een bindende overeenkomst waarin onderwerp, duur, doel, gegevenstypen, betrokkenen en de rechten en plichten van beide partijen zijn vastgelegd. De verwerker moet ook voldoende garanties bieden voor passende technische en organisatorische maatregelen. Artikel 32 koppelt die maatregelen vervolgens aan het risico, waaronder vertrouwelijkheid, integriteit, beschikbaarheid en het vermogen om de toegang tot persoonsgegevens te herstellen.
De verwerkersovereenkomst (DPA) moet gedocumenteerde instructies, vertrouwelijkheid, beveiligingsmaatregelen, goedkeuring van subverwerkers, ondersteuning bij verzoeken van betrokkenen, hulp bij incidenten, verwijdering of teruggave van gegevens en het recht van de klant op compliance-informatie omvatten. De gids over IT staff augmentation-contracten legt uit hoe deze eisen aansluiten op afspraken over intellectueel eigendom, aansprakelijkheid, vervanging en offboarding.
Gegevenstoegang tussen Nederland en Vietnam
Toegang op afstand vanuit Vietnam vereist een afzonderlijke doorgiftecontrole wanneer EU-persoonsgegevens beschikbaar worden gesteld aan een organisatie buiten de EU of EER. AVG Hoofdstuk V vereist een goedgekeurd doorgiftemechanisme en waarborgen die ook bij verdere doorgiften blijven gelden.
De Europese Commissie biedt Standard Contractual Clauses voor doorgiften van de EU naar landen buiten de EU. Het dossier voor de leveranciersbeoordeling moet de juiste SCC-module, de gegevensexporteur en -importeur, subverwerkers, doorgiftelocaties, beveiligingsmaatregelen en aanvullende waarborgen uit de doorgiftebeoordeling vermelden. Een DPA en SCC’s regelen verschillende onderdelen; de ene vervangt de andere niet.
Deze sectie biedt operationele richtlijnen voor leveranciersbeoordeling, geen juridisch advies. De DPO of juridisch adviseur van de klant moet de rolbeoordeling en het doorgiftemechanisme voor de feitelijke gegevensstroom goedkeuren.
Welk ISO 27001-bewijs u van een leverancier moet vragen
Vraag eerst om het certificaat en controleer daarna of de scope aansluit op de samenwerking. ISO/IEC 27001-certificering bewijst dat een informatiebeveiligingsmanagementsysteem (ISMS) is geaudit. Het garandeert niet dat iedere developer, delivery hub of klantomgeving binnen de scope valt.
De officiële norm is ISO/IEC 27001:2022. Een bruikbare certificaatcontrole registreert de juridische entiteit, gecertificeerde locaties en diensten, uitgifte- en vervaldatums, certificeringsinstantie, accreditatiestatus en lopende toezichtscyclus. ‘In lijn met ISO’ en ‘gecertificeerd volgens ISO/IEC 27001:2022’ zijn geen gelijkwaardige claims.
Vraag operationeel bewijs op voor de controles die de samenwerking beïnvloeden:
- de joiner-, mover- en leaverprocedure voor toegewezen developers;
- een procedure voor toegangsbeheer en privileged access;
- registraties van securitytraining voor de betrokken medewerkers;
- vereisten voor beheerde devices, encryptie, patching en endpointmonitoring;
- het proces voor veilige ontwikkeling en peer review;
- de workflow voor incidentclassificatie, contact en escalatie;
- het register van subverwerkers en het proces voor wijzigingsmeldingen;
- een geredigeerde risico- of controlesamenvatting die laat zien hoe delivery door leveranciers wordt gemonitord.
Een leverancier mag interne auditrapporten en gedetailleerde securityarchitectuur beschermen. Accepteer een geredigeerd document, een gecontroleerde review onder NDA of een verklaring van een auditor wanneer het alternatief de controle nog steeds bewijst. Geen enkel bewijs willen verstrekken is iets anders dan gevoelig bewijs beschermen.
Voor organisaties die binnen de scope vallen, voegt NIS2 Artikel 21 supply-chain security toe aan het beheer van cybersecurityrisico’s. NIS2 is niet op iedere inkoper of iedere staff augmentation-samenwerking van toepassing. De logica voor leveranciersrisico biedt wel een bruikbaar referentiepunt voor bedrijven die moeten aantonen hoe externe toegang wordt beheerst.
Als augmented developers toegang krijgen tot broncode, productiesystemen of klantgegevens, moet security onderdeel zijn van de inrichting van de samenwerking. Sunbytes kan vóór de eerste sprint helpen met het toegangsmodel, de DPA, onboardingcontroles en een deliveryproces op basis van ISO.
Checklist voor leveranciersbeoordeling vóór onboarding van developers
De leveranciersbeoordeling moet eindigen met een bewijsregister, niet met een verzameling ja/nee-antwoorden. Iedere controle heeft een artefact, eigenaar, reviewmoment en voorwaarde nodig die onboarding blokkeert.
Security evidence matrix
| Controlegebied | Op te vragen bewijs | Eigenaarschap | Reviewmoment | Blokkeren of verduidelijken als |
|---|---|---|---|---|
| Verwerkingsrol en gegevensstroom | Rolbeoordeling, systeem- en gegevensstroomkaart, gegevenscategorieën | DPO of legal van de klant; privacyverantwoordelijke van de leverancier | Vóór het contract en na een materiële wijziging | Partijen niet kunnen uitleggen wie welke gegevens verwerkt of waarom |
| DPA en doorgiftewaarborgen | Voorwaarden conform Artikel 28, SCC-module indien nodig, lijst van subverwerkers, doorgiftebeoordeling | Gedeeld eigenaarschap van legal en privacy | Vóór het contract; wanneer locaties of subverwerkers veranderen | De leverancier alleen een NDA of een algemene verklaring ‘AVG-compliant’ aanbiedt |
| Identiteit en toegang | Rollen- en toegangsmatrix, SSO- en MFA-configuratie, registraties van goedkeuring en intrekking | Systeemeigenaar van de klant; operations van de leverancier | Vóór dag één, ieder kwartaal en bij vertrek | Er gedeelde accounts bestaan of intrekking van toegang niet kan worden aangetoond |
| Mensen en devices | Screeningbeleid waar wettelijk toegestaan, geheimhoudingsvoorwaarden, trainingsregistratie, security baseline voor devices | Security- en people operations van de leverancier | Vóór toewijzing en jaarlijks | Developers onbeheerde devices gebruiken voor gevoelig werk zonder goedgekeurde controles |
| Code en release | Branch protection, regels voor peer review, secret scanning, workflow voor uitzonderingen | Engineering lead van de klant; gedeeld deliveryteam | Iedere release of goedgekeurde uitzondering | Eén developer zelfstandig een wijziging met hoog risico kan schrijven, goedkeuren en releasen |
| Incidentafhandeling | Severity-model, contactstructuur, contractueel meldingsvenster, proces voor behoud van bewijs | Incidentverantwoordelijke van de klant; security lead van de leverancier | Vóór dag één en tijdens oefeningen | ‘Zo snel mogelijk melden’ geen eigenaar, kanaal of escalatiepad heeft |
| Monitoring en audit | Registratie van toegangsreviews, controledashboard, uitzonderingenregister, beschikbare verklaringen | Gedeelde controle-eigenaren | Maandelijkse operationele review; driemaandelijkse governancereview | Security wordt besproken maar er geen bewijs wordt bewaard |
| Offboarding | Registratie van ingetrokken toegang, controle van devices en secrets, teruggave of verwijdering van gegevens, bevestiging van handover | Systeemeigenaar van de klant; operations van de leverancier | Bij rolwijziging en einde van het contract | De samenwerking kan eindigen zonder ondertekende bevestiging van voltooiing |
Vraag niet iedere leverancier om dezelfde diepgang aan bewijs. Een developer die alleen toegang heeft tot openbare testdata en één repository vereist niet dezelfde review als een platform engineer met privileged cloud access. Verhoog de bewijseis wanneer toegang, gevoeligheid van gegevens of impact op productie toeneemt.
Security monitoren tijdens delivery
Monitor security met bewaard bewijs en afgesproken drempelwaarden, niet met een driemaandelijks assurancegesprek. De maandelijkse operationele review moet accountstatus, controle-uitzonderingen en incidenten behandelen. Een driemaandelijkse governancereview moet bevestigen dat toegang, subverwerkers, deliveryscope en aannames over doorgifte nog steeds bij de samenwerking passen.
Gebruik een kleine set controlesignalen:
| Signaal | Voorbeeld van operationele doelstelling | Bewijs |
|---|---|---|
| Externe en privileged access gereviewd | 100% vóór de geplande reviewdatum | Ondertekende registratie van de toegangsreview |
| Toegang ingetrokken na vertrek of rolwijziging | Binnen de contractuele SLA; direct bij een security-incident | Logs van de identity provider en systemen |
| Dekking van MFA en beheerde devices | 100% voor identiteiten en devices binnen de scope | Identiteits- en endpointrapporten |
| Peer review op beschermde branches | 100% van de wijzigingen, tenzij een goedgekeurde nooduitzondering bestaat | Repositoryinstellingen en pull-requestgeschiedenis |
| Afsluiting van vulnerability- of controle-uitzonderingen | Binnen de risicogestuurde SLA die op basis van severity is vastgesteld | Ticket- en uitzonderingenregister |
| Incidentmelding | Binnen het venster dat in het contract is vastgelegd | Incidenttijdlijn en communicatieregistratie |
Dit zijn voorbeelden van operationele doelstellingen, geen wettelijke drempelwaarden. Stel de definitieve waarden vast op basis van het systeemrisico, het incidentproces van de klant en het contract.
DORA metrics bieden een tweede perspectief. De vijf metrics voor software delivery performance van DORA meten throughput en instabiliteit van deployments: change lead time, deployment frequency, failed deployment recovery time, change fail rate en deployment rework rate. Ze laten zien of securitycontroles vermijdbare frictie in delivery veroorzaken of dat het aantal instabiele releases toeneemt. DORA metrics bewijzen geen toegangsbeheer, AVG-compliance of incidentgereedheid. Houd het securitydashboard daarom gescheiden.
Het operationele model werkt wanneer bewijs zonder apart verzoek beschikbaar is, het aantal verlopen toegangsrechten tijdens de review nul is en achterstallige security-uitzonderingen benoemde eigenaren en datums hebben. Als dezelfde uitzondering twee governancereviews overleeft, moet de reactie de controle aanpassen of de toegang beperken, niet de deadline opnieuw verschuiven.
Hoe Sunbytes veilige IT staff augmentation ondersteunt
Sunbytes neemt het securitymodel vóór het verlenen van toegang op in de teaminrichting. Dedicated senior developers of teams kunnen binnen 2 tot 4 weken operationeel zijn, met eindverantwoordelijkheid vanuit Nederland en een delivery hub in Vietnam die 4 tot 5 uur overlap met Amsterdam biedt.
Sunbytes heeft 15+ jaar ervaring, 300+ projecten opgeleverd en is sinds 2024 ISO 27001 gecertificeerd. Wanneer Sunbytes als verwerker optreedt, kan de samenwerking een DPA conform AVG Artikel 28 en de doorgiftewaarborgen voor de goedgekeurde gegevensstroom omvatten. Delivery op basis van ISO levert samen met DORA-gemeten resultaten operationeel bewijs op: benoemde eigenaren van toegang, gedocumenteerde beslissingen, controleerbare logs en een voltooide offboardingregistratie.
FAQs
Nee. ISO/IEC 27001-certificering toont aan dat een ISMS binnen een bepaalde scope onafhankelijk is beoordeeld. De inkoper moet nog steeds controleren of het certificaat actueel is, de relevante juridische entiteit en deliveryorganisatie binnen de scope vallen en bewijs voor de controles van de samenwerking beschikbaar is.
Nee. Een DPA is vereist wanneer de provider namens de klant als verwerker van persoonsgegevens optreedt. Partijen moeten de feitelijke gegevensstroom en besluitvorming beoordelen in plaats van aan te nemen dat iedere personeelsrelatie dezelfde rolverdeling onder de AVG heeft.
Ja, wanneer de verwerking een geldige AVG-grondslag, passende beveiligingsmaatregelen en waar nodig een goedgekeurd doorgiftemechanisme uit Hoofdstuk V heeft. Het dossier voor de leveranciersbeoordeling moet de gegevensexporteur en -importeur, de toepasselijke SCC-module, subverwerkers en aanvullende goedgekeurde waarborgen voor de doorgifte vermelden.
De klant is verantwoordelijk voor beslissingen over de eigen systemen, gegevens, toegang, architectuur en risicoacceptatie. De provider is verantwoordelijk voor controles rond personeel, devices en interne processen. Code review, incidentrespons, bewijsverzameling en offboarding vereisen doorgaans benoemde eigenaren aan beide kanten.
Het model is niet automatisch minder veilig. Het risico neemt toe wanneer externe toegang breder, minder zichtbaar of langzamer in te trekken is dan toegang van medewerkers. Pas dezelfde regels voor identiteit, devices, code review en incidenten toe op iedere contributor om het grootste deel van dat verschil weg te nemen.
Trek identiteiten en tokens in, verwijder toegang tot repositories en de cloud, roteer blootgestelde secrets, neem beheerde devices terug of wis ze, bevestig de teruggave of verwijdering van gegevens en voltooi de kennishandover. De klant en leverancier moeten een gedateerde bevestiging van voltooiing bewaren in plaats van offboarding als een informele HR-stap te behandelen.
Nee. De scope van NIS2 hangt af van de sector, omvang, diensten en nationale implementatie van de klant en provider. Voor entiteiten die binnen de scope vallen, maken leveranciersrelaties en externe toegang deel uit van het beheer van cybersecurityrisico’s. Bewijs van de leverancier moet daarom de supply-chain controls van de klant ondersteunen.
Nee. AVG is de Nederlandse naam voor de General Data Protection Regulation. Nederlandse organisaties passen dezelfde EU-verordening toe, samen met relevante Nederlandse uitvoeringsregels en richtlijnen van de Autoriteit Persoonsgegevens.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
