Tijdlijn implementatie SASE: van pilot tot volledige uitrol in 90 dagen

Hoe lang duurt een SASE implementatie?

Een cloud-native SASE-implementatie voor een organisatie in het middensegment met 50 tot 400 gebruikers volgt zes fasen en neemt 60 tot 90 dagen in beslag vanaf de scoping tot de volledige uitrol. De fasen zijn assessment, identity en policy design, gecontroleerde pilot, gefaseerde uitbreiding, legacy decommission en voortdurende optimalisatie. Platforms zoals Jimber, die ontworpen zijn voor een snelle onboarding, kunnen een pilotgroep binnen enkele dagen operationeel hebben, in plaats van weken, omdat er geen hardware aangeschaft of geïnstalleerd hoeft te worden.

De meeste IT-teams gaan ervan uit dat een SASE-migratie zal aanvoelen als de firewallvervangingsprojecten waar ze nu al bang voor zijn. Twaalf maanden plannen. Zes maanden parallel lopen. Drie maanden van dingen repareren die kapot gingen. Die verwachting komt van hardware-centrische projecten waar elke site een vrachtwagen, een rack mount en een change window nodig heeft. Cloud-native SASE werkt anders. Beleidsregels worden centraal gedefinieerd en direct gepushed. Gebruikers maken verbinding via software, niet via site-specifieke apparaten. De hele tijdlijn van de SASE-implementatie verkort zich van kwartalen tot weken. Deze gids doorloopt elke fase met concrete stappen, teamverantwoordelijkheden en de veelvoorkomende blokkades die implementaties vertragen.

Fase 1: beoordeling en scoping (week 1-2)

Elke SASE implementatie begint met een duidelijk beeld van wat je hebt en wat er eerst moet veranderen. Als je deze stap overslaat, repliceer je oude VPN-toegangspatronen in een nieuwe tool, wat het doel tenietdoet.

Breng eerst uw huidige beveiligingsstapel in kaart. Maak een lijst van alle apparaten, abonnementen en consoles die uw team beheert. Voor de meeste organisaties in het middensegment brengt deze oefening alleen al de versnippering aan het licht: een VPN-concentrator hier, een standalone webfilter daar, firewalls van filialen met hun eigen regelsets en een endpoint tool die niemand meer controleert.

Breng vervolgens gebruikers naar applicaties in kaart. Niet “het verkoopteam gebruikt het netwerk”. Specifieke applicaties. CRM, ERP, fileshares, het facturatieportaal, het dashboard voor productiemonitoring. Deze inventarisatie wordt later de basis voor je ZTNA-beleid. De meeste organisaties ontdekken dat de gemiddelde gebruiker toegang nodig heeft tot drie tot vijf applicaties, niet tot het hele netwerk dat VPN toestond.

Bepaal je quick wins. Welke gebruikersgroep ervaart de meeste VPN-fricties? Meestal externe medewerkers en buitendienstmedewerkers. Welke toepassing veroorzaakt de meeste supporttickets? Begin daar. Je SASE-leveranciervergelijkingsgids zou moeten aangeven welk platform aan je scopingvereisten voldoet.

Spreek ten slotte succescriteria af voordat je begint. Meetbare doelen zoals “verminder VPN-gerelateerde supporttickets met 50%” of “bereik een latentie van sub-30ms voor externe gebruikers die cloud-apps openen” geven het project een duidelijke eindstreep in plaats van een eindeloze optimalisatielus.

Fase 2: identiteit en beleidsontwerp (week 2-3)

Identiteit is het fundament van SASE. Zonder een werkende identity provider integratie functioneert niets anders. Deze fase loopt gedeeltelijk parallel met het einde van assessment.

Maak eerst verbinding met uw identiteitsprovider. Microsoft Entra ID, Okta, Google Workspace of welke IdP uw organisatie ook gebruikt. Synchroniseer gebruikersgroepen en controleer of roltoewijzingen overeenkomen met bedrijfsfuncties, niet met oude AD-groepen die in de loop der jaren zijn opgebouwd. In onze gids over identity providers worden de integratiepatronen voor SAML en OIDC in detail uitgelegd.

Definieer vervolgens uw toegangsbeleid. Het principe is eenvoudig: elke gebruiker krijgt alleen toegang tot de applicaties die zijn rol vereist. Meer niet. Een financieel teamlid heeft toegang tot het facturatiesysteem en de rapportageportal. Een engineer heeft toegang tot de productiemonitoring tool en de code repository. Geen van beiden ziet de applicaties van de ander.

Stel baselines voor de apparaatstatus in naast het toegangsbeleid. Bepaal welke signalen belangrijk zijn voor uw organisatie: OS-versie, schijfversleutelingsstatus, endpointbeveiliging actief, apparaatregistratie. Het platform van Jimber dwingt deze controles af op het punt van toegang, zodat niet-conforme apparaten automatisch worden geblokkeerd of een beperkte reikwijdte krijgen. Zie voor een stapsgewijze uitleg onze handleiding over apparaatposture-controles voor NIS2.

Documenteer je beleidsbeslissingen. Deze documentatie wordt later bewijs voor naleving en voorkomt de “waarom was dit zo geconfigureerd?” gesprekken over zes maanden.

Fase 3: gecontroleerde pilot (week 3-5)

De pilot bewijst dat het platform werkt in jouw omgeving voordat je de rest van de organisatie inzet. Begin klein, meet alles, repareer wat kapot gaat.

Selecteer 10-20% van je gebruikers voor de pilot. Werknemers op afstand zijn om twee redenen de ideale eerste groep. Ze ervaren de meeste VPN-frictie, dus ze merken direct verbetering. En ze testen het moeilijkste toegangsscenario: verbinding maken vanaf onvoorspelbare netwerken via consumenten-ISP’s.

Publiceer twee tot drie applicaties via ZTNA. Kies applicaties die veel gebruikt worden, maar weinig risico inhouden als er iets fout gaat. Een interne wiki, een tijdregistratiesysteem of een tool voor projectbeheer. Zo kan je team leren hoe het platform zich in de praktijk gedraagt terwijl de inzet beheersbaar blijft.

Cloud-native platforms zoals Jimber kunnen een pilotgroep in dagen, niet weken, in gebruik nemen omdat er geen hardware geleverd of geconfigureerd hoeft te worden. De beheerder creëert de applicatiedefinities in de console, wijst ze toe aan de pilotgroep en gebruikers maken verbinding via een lichtgewicht agent of browsergebaseerde toegang.

Laat VPN parallel lopen tijdens de hele pilot. Gebruikers hebben een fallback nodig als ze op een edge case stuiten die de ZTNA-configuratie nog niet dekt. Houd drie dingen goed in de gaten: gebruikerservaring (latentie, stabiliteit van de verbinding), het aantal supporttickets en toegangslogs met hits en blokkades. Deze gegevens vormen het uitrolplan voor fase 4.

Voer de pilot minstens twee weken uit. Eén week is niet genoeg om intermitterende problemen op te vangen, zoals problemen met het vernieuwen van certificaten of randgevallen met DNS-resolutie.

Fase 4: gefaseerde uitrol (week 5-10)

Met pilotgegevens in de hand breidt u de dekking methodisch uit. Het doel is om 80% of meer van de gebruikers en applicaties te bereiken voordat de legacy-infrastructuur wordt aangeraakt.

Rol site voor site of afdeling voor afdeling uit. Elke golf volgt hetzelfde patroon: synchroniseer de gebruikersgroep, publiceer hun applicaties, schakel apparaatposture checks in, monitor gedurende twee tot drie dagen en ga dan naar de volgende golf. Dankzij de enkele console van Jimber worden beleidswijzigingen direct doorgevoerd op alle locaties. Er is geen configuratiedrift per site om te beheren.

Voeg in deze fase bedrijfskritische applicaties toe. ERP, CRM, financiële systemen en elke applicatie die gevoelige gegevens aanraakt. Deze vereisen strengere regels en een strakker toegangsbeleid dan de pilotapplicaties. Definieer uitzonderingsworkflows voor randgevallen: een aannemer die tijdelijk toegang nodig heeft, een gedeeld werkstation in een magazijn, een legacy applicatie die alleen RDP spreekt.

Voor organisaties met OT-omgevingen omvat deze fase de inzet van NIAC-hardware voor agentloze apparaten. Printers, camera’s, industriële controllers en IoT-sensoren kunnen geen ZTNA-agent uitvoeren. De NIAC-appliances van Jimber bevinden zich inline tussen het apparaat en het netwerk en dwingen Zero Trust-controles af zonder dat er software op het apparaat zelf nodig is.

Servicepartners die meerdere klanten beheren, profiteren in deze fase van de multi-tenantarchitectuur. Elke klantomgeving is geïsoleerd, maar sjablonen en basisbeleidslijnen kunnen worden gedeeld tussen tenants. Onze post over hoe MSP’s managed SASE leveren gaat in detail in op het operationele model.

Volg uw succescriteria van fase 1 gedurende de hele uitrol. Als de VPN supporttickets niet afnemen, moet er iets in de configuratie worden opgelost voordat je verder gaat.

Fase 5: legacy ontmanteling (week 8-12)

Zodra de applicatiedekking 80% of meer is en de pilotgegevens stabiele prestaties bevestigen, begint u met het buiten gebruik stellen van de legacy-infrastructuur. Dit is de fase waarin de kostenbesparingen werkelijkheid worden.

Begin met VPN. Schakel VPN-toegang uit voor applicaties die volledig gepubliceerd zijn via ZTNA. Doe dit stapsgewijs: verwijder de applicatie uit de VPN-configuratie, monitor een week en ga dan verder met de volgende applicatie. Houd gedocumenteerde noodprocedures beschikbaar totdat u zeker weet dat de overgang is voltooid.

Vervolgens worden firewalls op bijkantoren buiten gebruik gesteld. Cloud-levered FWaaS vervangt de noodzaak voor on-premise firewall hardware op elke locatie. Voor de meeste organisaties in het middensegment elimineert dit de cycli voor firmware-updates, het beheer van regelsets en de kosten voor het vernieuwen van hardware die een onevenredig deel van de IT-tijd in beslag namen.

De enkele console van Jimber betekent dat IT-teams tijdens de overgangsperiode geen twee dashboards hoeven te beheren. Toegangsbeleid, webbeveiliging, SD-WAN-connectiviteit en logboekregistratie bevinden zich vanaf dag één in één interface. De overgang gaat over het verwijderen van oude infrastructuur, niet over het leren van nieuwe tools.

Afbouwen van contracten en licenties voor buiten gebruik gestelde producten. VPN-concentrator ondersteuningsovereenkomsten, standalone webfilterabonnementen en firewalllicenties per site kunnen aanzienlijke jaarlijkse kosten vertegenwoordigen. Een Belgisch vermogensbeheerbedrijf verminderde de totale beveiligingskosten met 58% na het voltooien van deze consolidatie.

Fase 6: optimaliseren en bewaken (doorlopend)

SASE is geen set-and-forget implementatie. In de doorlopende fase verfijn je het beleid op basis van echte gebruiksgegevens en bouw je het compliancebewijs op dat auditors verwachten.

Controleer de toegangslogs maandelijks. Zoek naar gebruikers die rechten hebben die ze nooit gebruiken en verscherp de reikwijdte ervan. Zoek naar applicaties die vaak beleidsblokkades genereren en onderzoek of het beleid te beperkend is of dat iemand iets probeert te bereiken wat niet mag.

Voer elk kwartaal een beleidscontrole uit. Controleer of gebruikersgroepen nog steeds de werkelijke rollen weergeven, of de baseline van de apparaatstatus actueel is (drempels voor OS-versies moeten worden bijgewerkt als leveranciers nieuwe versies uitbrengen) en of beleidsregels voor uitzonderingen niet zijn uitgegroeid tot permanente workarounds.

Voor organisaties die vallen onder de NIS2-regelgeving zijn de logging- en rapportagemogelijkheden van je SASE-platform je compliance-engine. De ingebouwde logboekregistratie en apparaatstatuscontroles van Jimber voldoen vanaf dag één aan verschillende NIS2-vereisten: documentatie van toegangscontrole, incidentdetectie binnen 24 uur en bewijs van apparaatcompliance. Onze NIS2 compliance checklist koppelt deze vereisten aan specifieke platformmogelijkheden.

Wat SASE implementaties vertraagt (en hoe het te vermijden)

De bovenstaande tijdlijn van 90 dagen gaat uit van een competente uitvoering. In de praktijk zorgen vier veel voorkomende blokkades ervoor dat implementaties onnodig worden verlengd.

Geen bereidheid tot identiteitsprovider. Als je IdP verkeerd geconfigureerd is, verouderde gebruikersgroepen heeft of geen MFA afdwinging heeft, stokt de SASE integratie in fase 2. Ruim je directory op voor je begint. Verwijder verweesde accounts, controleer groepslidmaatschappen en schakel MFA in. Dit voorbereidende werk betaalt zichzelf terug.

DNS misconfiguratie. Gesplitste DNS-omgevingen, aangepaste DNS-resolvers en toepassingen die DNS-servers hard coderen, veroorzaken allemaal problemen wanneer de routering van verkeer verandert. Controleer uw DNS-configuratie tijdens de beoordeling. Documenteer elke interne DNS-zone en aangepaste resolver.

Geen executive sponsoring. De implementatie van SASE raakt elke gebruiker in de organisatie. Zonder zichtbare steun van de directie blijven individuele afdelingen veranderingen tegenhouden, stagneren pilots in afwachting van goedkeuringen en worden oude contracten verlengd “voor het geval dat”. Zorg voor een sponsor op directieniveau vóór Fase 1.

Geen legacy sunset plan. Sommige teams implementeren SASE perfect, maar ontmantelen nooit de oude infrastructuur. VPN blijft actief “voor back-up”. Firewalls van filialen blijven gepatcht. De organisatie betaalt voor onbepaalde tijd voor beide systemen. Stel een einddatum vast tijdens de scoping en houd je daaraan.

Hoe NIS2 deadlines je SASE implementatietijdlijn beïnvloeden

De Belgische CyberFundamentals (CyFun)-verificatiedeadline van april 2026 is verstreken. Organisaties die moesten aantonen dat ze aan het basisniveau of het belangrijke niveau voldeden, zouden hun technische controles al moeten hebben ingevoerd. Voor organisaties die nog steeds bezig zijn met de naleving, is elke week uitstel een week blootstelling aan handhavingsacties.

Artikel 21 van NIS2 vereist gedocumenteerde toegangscontroles, mogelijkheden voor incidentdetectie en beveiligingsmaatregelen voor de toeleveringsketen. Een SASE-platform voldoet aan ongeveer 90% van deze technische vereisten door identiteitsgebaseerde toegang, gecentraliseerde logging en handhaving van de apparaatstatus. Het NIS2-nalevingsoverzicht beslaat de volledige regelgevingscontext.

De praktische implicatie voor je SASE implementatietijdlijn: behandel de implementatie niet als een project dat meerdere kwartalen duurt. De complianceklok loopt al. Een implementatie van 90 dagen die werkende controles oplevert, is meer waard dan een plan van 12 maanden dat een perfect gedocumenteerd stappenplan oplevert maar geen bescherming.

Voor organisaties in Nederland wordt de Cyberbeveiligingswet begin 2026 geactiveerd. De Britse NIS-regelgeving volgt een eigen handhavingsschema. Ongeacht de jurisdictie is de richting hetzelfde: aantoonbare technische controles, geen gedocumenteerde intenties.

Veelgestelde vragen

Kunnen we SASE naast onze bestaande firewall gebruiken?

Ja, en dat zou je ook moeten doen tijdens de overgang. SASE-platforms zijn ontworpen voor gefaseerde implementatie. Houd je firewalls actief terwijl je applicaties migreert naar ZTNA en webbeveiliging verschuift naar SWG. Zodra de dekking 80% of meer is, kunt u de firewalls op de filialen buiten gebruik stellen. Sommige organisaties behouden een perimeter firewall in het datacenter voor specifieke noord-zuid verkeerscontroles tijdens de overgang, maar de lange termijn richting is volledige consolidatie.

Hoeveel gebruikers moeten deelnemen aan de pilot?

Streef naar 10-20% van je gebruikersbestand, met een minimum van 15-20 gebruikers om zinvolle gegevens te genereren. Neem externe werknemers, frequente reizigers en ten minste één afdeling die toegang heeft tot gevoelige applicaties op. Te weinig gebruikers en je zult geen randgevallen ontdekken. Te veel en je verliest de gecontroleerde omgeving die een pilot nuttig maakt.

Moeten we ons SD-WAN vervangen?

Niet noodzakelijk. Als je al een werkende SD-WAN implementatie hebt en alleen cloud-gebaseerde beveiliging nodig hebt, kan SSE (Security Service Edge) voldoende zijn. Als je SD-WAN-contracten aflopen of als je één enkel beheervlak wilt voor zowel externe gebruikers als bijkantoren, dan is unified SASE het betere pad. Onze gids met uitleg over de SASE-architectuur behandelt het onderscheid tussen SSE en volledige SASE.

Hoe zit het met apparaten waarop geen agents kunnen draaien?

Printers, IoT-sensoren, camera’s en industriële apparatuur hebben inline isolatie nodig in plaats van agentgebaseerde bescherming. NIAC-hardware plaatst deze apparaten achter identiteitsbewuste toegangscontroles die de communicatie beperken tot expliciet gedefinieerde flows. Het apparaat maakt alleen verbinding met de aangewezen bestemming. Verder niets. Dit sluit de blinde vlek die traditionele beveiligingstools negeren.

Hoe werkt de implementatie van SASE voor organisaties met meerdere vestigingen?

SD-WAN verwerkt connectiviteit voor meerdere locaties als onderdeel van het SASE-platform. Filialen maken verbinding via versleutelde tunnels over standaard internetverbindingen. Zero-touch provisioning betekent dat een apparaat naar de locatie wordt verzonden, wordt aangesloten door niet-technisch personeel en automatisch zijn configuratie ophaalt uit de cloud. De implementatietijd per locatie daalt van dagen naar minuten.

Wat als een servicepartner onze IT beheert?

Servicepartners versnellen de tijdlijn. Ze brengen implementatie-ervaring van vorige klanten mee en multi-tenant SASE-platforms laten hen uw omgeving beheren vanaf dezelfde console die ze voor hun andere klanten gebruiken. Beleidssjablonen, gestandaardiseerde basisregels en herhaalbare onboardingprocessen zorgen ervoor dat de partner niet bij elke opdracht opnieuw hoeft te beginnen.

Klaar om een SASE implementatietijdlijn voor jouw organisatie in kaart te brengen? Boek een demo en doorloop een implementatieplan dat is afgestemd op de grootte van je team, het aantal locaties en de compliance-eisen. Jimber’s platform is ontwikkeld voor organisaties in het middensegment die behoefte hebben aan enterprise-grade beveiliging zonder het 12 maanden durende implementatieproject.