De meeste teams behandelen ISO 27001 als een procurementvereiste. Tegen de tijd dat securityvragenlijsten verschijnen, zijn architectuurbeslissingen al genomen, leveranciers al geselecteerd en productietijdlijnen al onder druk komen te staan. In ISO 27001-appontwikkelingsprojecten werkt het framework het best wanneer het de delivery vanaf het begin vormgeeft, voordat infrastructuurtoegang uitbreidt, third-party tools zich vermenigvuldigen en gevoelige gebruikersdata tussen omgevingen begint te bewegen. Het beïnvloedt hoe teams permissies beheren, securitybesluiten documenteren, incidenten afhandelen en compliancerisico’s verminderen terwijl het product opschaalt.
Dit artikel legt uit wat ISO 27001-certificering daadwerkelijk betekent voor de app die uw team bouwt: welke Annex A-controls invloed hebben op development, welk bewijs kopers kunnen opvragen, wat de certificering niet garandeert en hoe deze overlapt met GDPR- en NIS2-verwachtingen voor Nederlandse en EU-bedrijven.
Voor een bredere deliverybaseline, lees onze complete mobile app development guide om ISO-gestuurde delivery te vergelijken met platformkeuze, sprintplanning, testing en release governance.
TL;DR
- ISO 27001 appontwikkeling betekent dat het information security management system van de leverancier bepaalt hoe uw app wordt gepland, gebouwd, getest, toegankelijk gemaakt en ondersteund. Het certificeert niet de app zelf. Voor kopers zit de praktische waarde in bewijs: toegangsreviews, kwetsbaarheidsprocedures, secure development-regels, leverancierscontroles en incidentresponsregistraties die gekoppeld zijn aan het team dat uw product bouwt.
- De meest relevante Annex A-controls voor appprojecten zijn A.9, A.12, A.13, A.14 en A.15. Deze gaan over wie toegang heeft tot de codebase, hoe kwetsbaarheden worden opgelost, hoe data veilig beweegt, hoe security in elke sprint terechtkomt en hoe subcontractors of offshore teams worden aangestuurd.
- ISO 27001 is een procesgarantie, geen productgarantie. Het betekent niet dat elke regel code wordt geaudit, dus kopers moeten nog steeds projectspecifiek bewijs opvragen, zoals toegangsreviewregistraties, dependency scan-resultaten, secure development-beleid en bewijs van security testing.
Wat ISO 27001-certificering daadwerkelijk dekt in een softwareontwikkelingscontext
ISO 27001-certificering dekt het Information Security Management System van de leverancier, niet de individuele app als zelfstandig product.
Dat onderscheid is belangrijk.
Het ISMS definieert de beleidsregels, procedures, verantwoordelijkheden, risicocontroles en bewijspraktijken waaronder de leverancier werkt. Wanneer een softwareontwikkelingsbedrijf ISO 27001-gecertificeerd is, bevestigt de audit dat het security management system is geïmplementeerd en operationeel is. Het betekent niet dat elk klantproject een aparte ISO-audit krijgt.
Voor uw app is de nuttige vraag niet alleen: “Is de leverancier ISO 27001-gecertificeerd?”
De betere vraag is: omvat de ISMS-scope van de leverancier ook softwareontwikkelingsactiviteiten, deliverylocaties, cloud operations, subcontractors en de teams die aan uw codebase komen?
Als softwareontwikkeling buiten de ISMS-scope valt, kan het certificaat nog steeds geldig zijn voor het bedrijf, maar minder nuttig zijn voor uw project. Als softwareontwikkeling binnen de scope valt, wordt ISO 27001 een deliveryframework. Het bepaalt hoe toegang wordt verleend, hoe kwetsbaarheden worden afgehandeld, hoe incidenten worden geëscaleerd, hoe leveranciersrisico wordt beheerd en hoe securitybewijs tijdens de build wordt geproduceerd.
De Annex A-controls die direct beïnvloeden hoe uw app wordt gebouwd
ISO 27001 bevat veel controls, maar slechts een deel heeft directe invloed op softwareontwikkelingspraktijken. Deze sectie richt zich op de controls die veranderen hoe uw app wordt gepland, gecodeerd, getest, gedeployed en ondersteund. Voor de volledige achtergrond van certificering, zie hoe het ISO 27001-certificeringsproces werkt.
| Annex A-control | Controlnaam | Wat dit in de praktijk betekent voor de app-build | Bewijs dat u kunt opvragen |
|---|---|---|---|
| A.9 / 5.15–5.18 | Toegangscontrole | Wie toegang heeft tot de codebase, productieomgeving, database en cloudsystemen; rolgebaseerde permissies; gedocumenteerde toegangsreviews | Toegangscontrolebeleid; meest recente toegangsreviewregistratie, indien nodig geanonimiseerd |
| A.12 / 8.8 | Kwetsbaarhedenbeheer | Procedures voor het beheren van kwetsbaarheden in de development toolchain, third-party libraries, SDK’s en appdependencies | Procedure voor kwetsbaarhedenbeheer; dependency scan-resultaten; patch-SLA per ernstniveau |
| A.13 / 8.20–8.23 | Netwerk- en communicatiebeveiliging | TLS-bescherming, veilige remote access, netwerksegmentatie en gedocumenteerde controls voor data in transit | Netwerksecuritybeleid; bevestiging van TLS-versie; overzicht van omgevingssegmentatie |
| A.14 / 8.25–8.33 | Secure development lifecycle | Secure development-richtlijnen, code review, security testing en release controls ingebed in sprintdelivery | Secure development-beleid; bewijs van code review; security testing in CI/CD |
| A.15 / 5.19–5.22 | Leveranciersrelaties | Subcontractors, offshore teams en externe providers worden aangestuurd via leverancierssecurityprocedures en ISMS-scope | Leverancierssecuritybeleid; bevestiging dat alle deliverylocaties binnen scope vallen |
A.9 / 5.15–5.18: Toegangscontrole – wie toegang heeft tot de codebase en wanneer
Toegangscontrole is een van de eerste plekken waar ISO 27001 invloed heeft op appontwikkeling.
Een gecertificeerde leverancier moet gedocumenteerde regels hebben voor wie toegang heeft tot repositories, omgevingen, databases, clouddiensten, projectmanagementtools en klantdata. Voor uw app mag productietoegang niet afhangen van informeel vertrouwen of van “wie het langst aan het project heeft gewerkt”. Het moet volgen uit rolgebaseerde permissies, goedkeuringsworkflows, MFA, auditlogging en regelmatige toegangsreviews.
De kopersvraag is praktisch: wie mag deployen, wie mag productiedata lezen, wie mag infrastructuurinstellingen wijzigen en hoe vaak worden die rechten beoordeeld?
Een goede leverancier kan een toegangscontrolebeleid en bewijs van recente toegangsreviews leveren. Geanonimiseerd bewijs is meestal acceptabel, omdat het doel niet is om namen van medewerkers bloot te leggen. Het doel is om te bewijzen dat toegang wordt beoordeeld en gecontroleerd.
A.12 / 8.8: Operations en kwetsbaarhedenbeheer – de patch-SLA-vraag
ISO 27001 beïnvloedt ook hoe kwetsbaarheden tijdens development worden gevonden, geprioriteerd en opgelost.
Voor mobiele apps is kwetsbaarhedenbeheer niet beperkt tot productieservers. Het omvat third-party SDK’s, open-source libraries, CI/CD-tools, backend-API’s, clouddiensten en developer workstations. Als één dependency kwetsbaar wordt, heeft het project een duidelijk proces nodig voor ernstclassificatie, eigenaarschap, hersteltermijn, hertesten en releasebesluitvorming.
Dit sluit direct aan op uw mobile app security testing checklist, omdat testbewijs laat zien of het kwetsbaarhedenproces in de praktijk werkt.
Vraag uw leverancier om de procedure voor kwetsbaarhedenbeheer en de patch-SLA voor kritieke, hoge, middelhoge en lage bevindingen. “We lossen issues snel op” is niet genoeg. Een nuttig antwoord benoemt de ernstniveaus, verantwoordelijke eigenaar, beoogde hersteltermijn en verificatieproces vóór release.
A.14 / 8.25–8.33: Secure development lifecycle – security in elke sprint
Dit is de meest developmentrelevante controlcluster voor een Nederlandse B2B-appkoper.
Secure development lifecycle-controls definiëren hoe security wordt ingebed in delivery voordat de app de laatste testfase bereikt. In de praktijk betekent dit dat securityvereisten worden besproken tijdens architectuurplanning, gevoelige datastromen worden beoordeeld vóór implementatie, code reviews securitychecks bevatten en geautomatiseerde tests binnen de delivery pipeline draaien.
Dit is waar “ISO 27001-gecertificeerd” zichtbaar moet worden binnen sprintdelivery.
Als security pas vóór lancering verschijnt, is het project al laat. Tegen die tijd kunnen teams zwakke token handling, slechte logging, ontbrekende toegangsbeperkingen of onveilig gebruik van third-party SDK’s ontdekken nadat architectuurbeslissingen al vastliggen. Dat soort rework beïnvloedt zowel de planning als het vertrouwen in de release.
Een volwassen leverancier moet secure development-richtlijnen, code review-procedures en bewijs kunnen leveren dat security testing onderdeel is van CI/CD, in plaats van een geïsoleerde activiteit vlak voor lancering.
A.13 / 8.20–8.23: Netwerk- en communicatiebeveiliging – data in transit
Netwerk- en communicatiebeveiligingscontrols beïnvloeden hoe uw app data verplaatst tussen mobiele apparaten, API’s, clouddiensten, interne systemen en third-party platforms.
Voor appontwikkeling betekent dit meestal TLS-bescherming voor data in transit, gedocumenteerde netwerksegmentatie tussen development- en productieomgevingen, veilige remote access en gecontroleerde communicatie tussen systemen. Deze controls worden belangrijker wanneer teams verspreid over locaties werken of wanneer offshore developers toegang nodig hebben tot cloudomgevingen, repositories of interne tools.
Voor Nederlandse en EU-kopers is dit ook een punt waar regelgeving samenkomt. GDPR Artikel 32 verwacht passende technische en organisatorische maatregelen voor de beveiliging van verwerking. NIS2 Artikel 21 legt ook nadruk op technische en organisatorische maatregelen voor netwerk- en informatiesystemen.
Vraag om het netwerksecuritybeleid, de aanpak voor omgevingssegmentatie en bevestiging van de TLS-versie die wordt gebruikt voor appcommunicatie.
A.15 / 5.19–5.22: Leveranciersrelaties – uw subcontractors en de app supply chain
Controls voor leveranciersrelaties zijn belangrijk wanneer uw developmentpartner werkt met subcontractors, offshore teams, cloudproviders, testingpartners of gespecialiseerde consultants.
Voor appkopers is het risico versnipperd eigenaarschap. Eén team schrijft code. Een ander team beheert cloudinfrastructuur. Een derde team doet QA. Weer een ander heeft toegang tot analytics, crash reporting of user support tools. Zonder leverancierscontrols wordt onduidelijk wie verantwoordelijk is voor dataverwerking, incidentrapportage, het verwijderen van toegang of remediation wanneer er iets misgaat.
Dit is vooral relevant wanneer Nederlandse bedrijven appontwikkeling over regio’s heen outsourcen. Externe teams kunnen in de eerste weken van delivery toegang krijgen tot repositories, stagingomgevingen, productieachtige testdata of communicatietools.
Een sterke ISO 27001-gecertificeerde leverancier kan uitleggen of het volledige deliveryteam wordt gedekt door de ISMS-scope, inclusief offshore deliverylocaties. Het bewijs dat u kunt opvragen bestaat uit het leverancierssecuritybeleid en bevestiging dat alle deliverylocaties die bij uw app betrokken zijn, gedekt zijn.
Wilt u weten welke ISO 27001-controls relevant zijn voor uw app-build?
De vijf controlclusters hierboven vertalen zich naar concreet deliverybewijs: wie toegang heeft tot uw systemen, hoe kwetsbaarheden worden opgelost, hoe data tussen omgevingen beweegt, hoe secure development in elke sprint terechtkomt en hoe subcontractors worden aangestuurd.
Sunbytes kan uw appscope, deliverymodel en complianceverwachtingen beoordelen en vervolgens de relevante ISO 27001-controls koppelen aan het bewijs dat uw leverancier moet aanleveren. Praat met onze experts over ISO-gestuurde appdelivery.
Wat ISO 27001 NIET garandeert – drie veelvoorkomende misvattingen
ISO 27001 is nuttig omdat het structuur creëert. Het wordt riskant wanneer kopers er óf te veel op vertrouwen, óf het wegzetten als papierwerk.
Het certificaat betekent dat elke app die de leverancier bouwt, wordt geaudit
Nee. ISO 27001-certificering audit het ISMS van de leverancier, niet elke afzonderlijke app.
Dat betekent dat uw app alleen profiteert van het geaudite securitymanagementproces van de leverancier als de projectactiviteiten binnen de ISMS-scope vallen. Daarom is scope belangrijk. Vraag of softwareontwikkeling, cloud operations, subcontractors en deliverylocaties zijn inbegrepen.
Wat u in plaats daarvan nodig heeft: certificeringsscope, projectspecifiek bewijs en bevestiging dat het team dat uw app bouwt de gecertificeerde processen volgt.
Het certificaat betekent dat de code veilig is
Nee. ISO 27001 garandeert niet dat uw app geen kwetsbaarheden heeft.
Het bevestigt dat de leverancier securitymanagementcontrols heeft ingericht. Codesecurity hangt nog steeds af van architectuurbeslissingen, secure coding, code review, dependencymanagement, testing en remediation. Voor app-specifieke assurance heeft u nog steeds bewijs van security testing nodig.
Wat u in plaats daarvan nodig heeft: een mobile app security testing checklist, bewijs van code review, dependency scan-resultaten en hertestbewijs voor opgeloste kwetsbaarheden.
Het certificaat is statisch
Nee. ISO 27001 is geen eenmalige prestatie. Gecertificeerde leveranciers hebben doorlopende surveillance audits en periodieke hercertificering nodig. Een certificaat dat twee jaar geleden geldig was, bewijst niet automatisch dat dezelfde controls vandaag nog werken. Kopers moeten de certificerende instantie, de vervaldatum van het certificaat en de status van de meest recente surveillance audit controleren.
Wat u in plaats daarvan nodig heeft: huidig certificaat, vervaldatum, auditrecency en bevestiging dat de controls nog steeds van toepassing zijn op het team dat aan uw project werkt.
Hoe ISO 27001 zich verhoudt tot GDPR en NIS2 voor Nederlandse appkopers
Voor Nederlandse bedrijven die digitale producten bouwen, wordt ISO 27001 vaak beoordeeld naast GDPR en de NIS2-richtlijn. De overlap is belangrijk omdat enterprise-kopers steeds vaker verwachten dat leveranciers zowel operationele securitymaturiteit als regulatory readiness kunnen aantonen voordat delivery begint.
ISO 27001 maakt een app niet automatisch GDPR-compliant of NIS2-compliant. GDPR is een privacywetgeving voor gegevensbescherming. NIS2 is een cybersecurityrichtlijn. ISO 27001 is een securitymanagementstandaard.
De praktische waarde is dat meerdere ISO 27001-controls dezelfde technische en organisatorische maatregelen ondersteunen die Nederlandse kopers moeten aantonen onder GDPR en NIS2.
| Verplichting | ISO 27001-control | GDPR-artikel | NIS2-artikel | Wat dit betekent voor de app |
|---|---|---|---|---|
| Encryptie en veilige overdracht | A.13 / 8.20–8.23 | Artikel 32(1)(a) | Artikel 21(2)(h) | Appdata in transit moet worden beschermd met gedocumenteerde technische controls |
| Toegangscontrole | A.9 / 5.15–5.18 | Artikel 32 risicogebaseerde toegangsmaatregelen | Artikel 21(2)(i) | Toegang tot code, systemen en data moet worden beperkt, goedgekeurd en beoordeeld |
| Incidentrespons | A.16 / 5.24–5.28 | Artikel 33 | Artikel 23 | Incidentdetectie, escalatie, notificatie en eigenaarschap moeten worden gedocumenteerd |
Voor een diepere privacylaag, lees onze gids over GDPR technical requirements for mobile apps. Voor cybersecurityverplichtingen, zie NIS2 Article 21 and mobile app security.
De takeaway voor kopers is direct: een leverancier met ISO 27001 Annex A.9, A.13, A.14 en A.16 operationeel binnen scope geeft u niet standaard volledige regulatory compliance. Maar hij geeft uw appdelivery wel een sterkere bewijsbasis voor gesprekken over GDPR Artikel 32 en NIS2 Artikel 21.
Vragen die u uw appontwikkelingsleverancier moet stellen over hun ISO 27001-certificaat
De kwaliteit van de ISO 27001-implementatie van een leverancier wordt duidelijker wanneer u operationele vragen stelt. Een certificaat alleen is niet genoeg.
1. Valt softwareontwikkeling binnen jullie ISMS-scope?
Red flag: de leverancier zegt alleen “we zijn gecertificeerd”, maar kan de scope niet uitleggen.
Goed antwoord: softwareontwikkeling, delivery operations en relevante supportprocessen zijn expliciet inbegrepen.
2. Wie is jullie certificerende instantie en wanneer verloopt het huidige certificaat?
Red flag: de leverancier kan het certificaat, de certificerende instantie of de vervaldatum niet aanleveren.
Goed antwoord: de leverancier verstrekt het certificaat, de certificerende instantie, het certificaatnummer en de huidige geldigheidsperiode.
3. Omvat de certificaatscope alle developmentlocaties, inclusief offshore teams?
Red flag: het hoofdkantoor is gecertificeerd, maar de offshore delivery hub is onduidelijk.
Goed antwoord: de leverancier bevestigt welke locaties en teams gedekt zijn, inclusief subcontractors indien relevant.
4. Kunt u uw secure development-beleid voor Annex A.14 / 8.25–8.33 delen?
Red flag: secure development wordt mondeling beschreven, maar is niet gedocumenteerd.
Goed antwoord: de leverancier kan beleidsmatig bewijs, code review-regels en testprocedures delen.
5. Kunt u geanonimiseerd bewijs delen van uw meest recente toegangsreview voor Annex A.9 / 5.15–5.18?
Red flag: toegang wordt informeel verleend en pas verwijderd wanneer iemand eraan denkt.
Goed antwoord: toegangsreviews zijn gedocumenteerd, tijdgebonden en gekoppeld aan rolwijzigingen.
6. Wat is jullie vulnerability patch-SLA voor kritieke bevindingen?
Red flag: “we lossen het zo snel mogelijk op.”
Goed antwoord: ernstniveaus, eigenaar, beoogde hersteltermijn, hertestproces en escalatiepad zijn gedefinieerd.
7. Dekt jullie incidentresponsprocedure onze app specifiek, en wat is de notificatietijdlijn?
Red flag: de leverancier heeft een generiek incidentbeleid, maar kan niet uitleggen hoe uw app zou worden afgehandeld.
Goed antwoord: de leverancier benoemt het escalatiepad, de early warning-tijdlijn, het klantnotificatieproces en de verantwoordelijke eigenaar. Dit is vooral relevant voor kopers die NIS2 Article 21 and mobile app security beoordelen.
Hoe de ISO 27001-certificering van Sunbytes van toepassing is op uw mobile app-project
De zeven vragen hierboven hebben specifieke antwoorden bij Sunbytes, maar de projectspecifieke details moeten nog steeds worden bevestigd tijdens vendor evaluation.
Sunbytes is een ISO 27001-gecertificeerd technologiebedrijf met het hoofdkantoor in Nederland en deliverycapaciteit in Vietnam. U kunt de ISO 27001-certificering van Sunbytes bekijken als credential proof.
Voor mobile app-projecten omvatten de relevante deliverycontrols toegangscontrole, kwetsbaarhedenbeheer, secure development-workflows, leveranciersgovernance en incidentafhandeling. Deze staan niet los van delivery. Ze beïnvloeden hoe sprintwerk wordt gepland, hoe omgevingen worden benaderd, hoe code wordt beoordeeld en hoe bewijs wordt geproduceerd wanneer enterprise-klanten om security assurance vragen.
Bevestig de ISO 27001-versie, de huidige vervaldatum van het certificaat, de datum van de meest recente surveillance audit en of de ISMS-scope expliciet de volledige NL-VN-deliveryketen dekt.
Sunbytes’ Digital Transformation Solutions worden in de praktijk versterkt door Secure en Accelerate: Secure embedt ISO 27001/NIS2-gemapte controls in delivery, terwijl Accelerate de people layer achter stabiele teamopschaling ondersteunt. Het resultaat is een deliverymodel waarin de juiste mensen, securitycontrols en operationele governance aanwezig zijn voordat gevoelige appdata tussen systemen begint te bewegen.
Plant u een ISO-bewust appontwikkelingsproject? Ontdek de dedicated development teams van Sunbytes om te bouwen met duidelijker delivery-eigenaarschap, sterker securitybewijs en schaalbare engineeringcapaciteit.
Hoe de ISO 27001-certificering van Sunbytes van toepassing is op uw mobile app-project
ISO 27001 helpt uw appproject alleen wanneer de controls zichtbaar worden binnen delivery: toegangsbesluiten, code review, kwetsbaarhedenafhandeling, leveranciersgovernance en incidentescalatie. Daar wordt certificering praktisch voor CTO’s, productteams en IT-leiders.
Sunbytes is een Nederlands technologiebedrijf met het hoofdkantoor in Nederland en een delivery hub in Vietnam. Sinds 2011 ondersteunen we internationale bedrijven in meer dan 300 projecten bij het bouwen en moderniseren van digitale producten, platforms en deliveryteams.
Voor mobile app-projecten combineert Sunbytes ISO-gestuurde delivery, senior engineeringteams en DORA-gemonitorde deliveryresultaten. Dat betekent dat securitybewijs niet wordt behandeld als een documentverzoek aan het einde van het project. Het wordt ingebouwd in hoe sprintwerk wordt gepland, hoe omgevingen worden benaderd, hoe code wordt beoordeeld en hoe risico’s vóór release worden gevolgd.
Dit werkt omdat Digital Transformation Solutions worden ondersteund door twee operationele lagen. Cybersecurity Solutions embedden ISO 27001/NIS2-gemapte controls in architectuur, infrastructuurtoegang, developmentworkflows, leveranciersgovernance en incidentafhandeling. Accelerate Workforce Solutions ondersteunen de people layer achter stabiele delivery, inclusief teamopschaling, role ownership, onboarding en offboarding.
Bevestig vóór de start van een ISO-bewust appproject drie dingen: de certificaatscope dekt softwareontwikkeling, de deliverylocaties zijn inbegrepen en het projectteam kan bewijs produceren tijdens de build, niet alleen na lancering. Ontdek de dedicated development teams van Sunbytes om uw app te bouwen met duidelijker eigenaarschap, ISO-gestuurde delivery en sterker securitybewijs vanaf sprint één.
FAQs
Nee. ISO 27001 is een securitymanagementstandaard, terwijl GDPR een regelgeving voor gegevensbescherming is. ISO 27001-controls kunnen GDPR Artikel 32-vereisten ondersteunen rond beveiliging van verwerking, toegangscontrole, encryptie en incidentrespons, maar ze dekken niet alle GDPR-verplichtingen. Voor de app-specifieke privacylaag, zie GDPR technical requirements for mobile apps.
Nee. ISO 27001 bevestigt dat securitymanagementprocessen bestaan, maar een penetratietest controleert of de app bestand is tegen echte technische aanvalsscenario’s. U heeft nog steeds app-specifieke security testing, bewijs van remediation en hertesting nodig vóór lancering. Gebruik een mobile app security testing checklist om die bewijslaag te definiëren.
Vraag om het certificaatdocument, de certificerende instantie, het certificaatnummer, de geldigheidsperiode en de status van de meest recente surveillance audit. Controleer of de certificaatscope softwareontwikkeling en relevante deliverylocaties omvat. Als de leverancier de scope niet kan uitleggen, zegt de certificering mogelijk weinig over de app die wordt gebouwd.
Nee. NIS2 vereist ISO 27001-certificering niet als enige route naar compliance. ISO 27001-controls kunnen echter veel NIS2 Artikel 21-vereisten ondersteunen, vooral rond toegangscontrole, incidentrespons, leveranciersmanagement, kwetsbaarhedenbeheer en bedrijfscontinuïteit. Voor appdeliverycontext, zie NIS2 Article 21 and mobile app security.
ISO 27001 is een internationale standaard voor information security management systems. SOC 2 is een uit de VS afkomstige attestatie gericht op controls rondom security, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid en privacy. Voor Nederlandse en EU-appkopers is ISO 27001 vaak de bekendere vendor security credential, terwijl SOC 2 belangrijker kan zijn bij verkoop aan Amerikaanse enterprise procurement.
“ISO 27001 app ontwikkeling” verwijst naar appontwikkeling die wordt geleverd onder ISO 27001-gestuurde securityprocessen. Voor Nederlandse kopers is de belangrijke vraag niet alleen of de leverancier gecertificeerd is, maar of softwareontwikkeling, deliveryteams, leveranciersrelaties en toegangscontroles binnen de ISMS-scope vallen. Dat bepaalt of de certificering praktische waarde heeft voor het appproject.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
