HIPAA Compliance-eisen: De Complete Gids, Bijgewerkt voor de Security Rule Wijzigingen van 2025

De Health Insurance Portability and Accountability Act (HIPAA) stelt federale standaarden vast voor de bescherming van patiëntgegevens binnen organisaties die deze informatie aanmaken, ontvangen, bewaren of verzenden. HIPAA-naleving is geen eenvoudige checklist, maar een raamwerk van vier onderling verbonden regels die privacy, beveiliging, meldingsplicht bij datalekken en gegevensverwerking regelen — zowel voor de covered entities die rechtstreeks betrokken zijn bij patiëntenzorg, als voor de business associates die hen ondersteunen.

Begrijpen wat HIPAA daadwerkelijk vereist — niet alleen dat de wet bestaat — is het startpunt voor het opbouwen van een nalevingsprogramma dat bestand is tegen onderzoek door de OCR (Office for Civil Rights). Deze gids behandelt alle vier de regels, de voorgestelde Security Rule-updates van 2025 — de grootste herziening in meer dan tien jaar — de sanctiestructuur bij niet-naleving, en wat organisaties in de praktijk moeten implementeren om aan elke vereiste te voldoen.

Samenvatting

Kernboodschap: HIPAA-naleving vereist het voldoen aan vier regels — de Privacy Rule, de Security Rule, de Breach Notification Rule en de Omnibus Rule — op administratief, fysiek en technisch vlak. Voor zowel covered entities als business associates betekent naleving niet alleen het implementeren van beheersmaatregelen, maar ook het bijhouden van gedocumenteerd bewijs dat deze maatregelen daadwerkelijk functioneren. Als de voorgestelde Security Rule-wijzigingen van 2025 worden bekrachtigd, worden encryptie, multi-factor authenticatie en netwerksegmentatie verplicht voor alle covered entities en business associates — waarmee de flexibiliteit van ‘addressable’ (aanbevolen, maar niet verplicht) maatregelen waar organisaties zich historisch op konden beroepen, komt te vervallen.

Waarom dit belangrijk is: Het Office for Civil Rights rondde in 2024 alleen al 63 handhavingszaken af, met boetes variërend van tienduizenden tot tientallen miljoenen dollars. De zorgsector was voor het veertiende jaar op rij de sector met de meeste datalekken. De handhavingsaanpak van OCR is verschoven van reactief — reageren op gemelde datalekken — naar proactief, met een actief auditprogramma gericht op covered entities en business associates, ongeacht of er al een datalek heeft plaatsgevonden. De norm voor HIPAA-naleving is niet het hebben van een programma op papier, maar het kunnen aantonen dat dit programma daadwerkelijk werkt zodra OCR daarom vraagt.

Belangrijkste Inzichten

1. HIPAA is in gelijke mate van toepassing op covered entities en business associates.

Sinds de Omnibus Rule van 2013 gelden voor business associates — de leveranciers, cloudproviders, factureringsbedrijven en technologiepartners die namens covered entities met PHI werken — dezelfde HIPAA-nalevingsvereisten en boeterisico’s als voor de zorgorganisaties die zij bedienen. Een Business Associate Agreement (BAA) is wettelijk verplicht, maar vervangt geen technische maatregelen. Een BAA die nalevingsverplichtingen toewijst zonder de onderliggende encryptie, toegangscontroles en auditlogging om deze te onderbouwen, is een contractueel document met een onafdwingbaar beveiligingsniveau.

2. De voorgestelde Security Rule-wijzigingen van 2025 schaffen het ‘addressable’ vangnet af.

Onder de oorspronkelijke HIPAA Security Rule werden beveiligingsmaatregelen ingedeeld als ‘required’ (verplicht) of ‘addressable’ (aan te pakken). Verplichte maatregelen moesten worden geïmplementeerd. Addressable maatregelen moesten worden geïmplementeerd, tenzij een covered entity een redelijk alternatief kon documenteren. In de praktijk gebruikten veel organisaties deze addressable-status om encryptie en andere maatregelen uit te stellen. De voorgestelde wijzigingen van 2025 schaffen dit onderscheid volledig af — waardoor encryptie in rust en tijdens verzending, multi-factor authenticatie, netwerksegmentatie en verschillende andere maatregelen verplicht worden voor alle covered entities en business associates, zonder mogelijkheid tot een gedocumenteerd alternatief.

3. Risicobeoordeling is verplicht, niet optioneel — en moet actueel zijn.

De HIPAA Security Rule vereist dat covered entities en business associates een accurate en grondige beoordeling uitvoeren van de potentiële risico’s en kwetsbaarheden voor de vertrouwelijkheid, integriteit en beschikbaarheid van ePHI. OCR heeft in handhavingszaken expliciet aangegeven dat een risicoanalyse die jaren geleden is uitgevoerd zonder latere updates, niet aan deze vereiste voldoet. Een HIPAA-risicobeoordeling is geen eenmalige exercitie — ze moet periodiek worden herzien en bijgewerkt, en telkens wanneer er belangrijke operationele of omgevingsveranderingen plaatsvinden.

4. Relaties met business associates verbreden uw nalevingsperimeter — én uw aansprakelijkheid.

Elke leverancier, cloudserviceprovider of technologiepartner die namens u toegang heeft tot, PHI opslaat of verzendt, is een business associate. Hun beveiligingsfouten vormen uw nalevingsrisico. Onder HIPAA moeten covered entities technische en contractuele waarborgen implementeren die bepalen hoe business associates met PHI omgaan — en deze waarborgen moeten operationeel worden afgedwongen, niet alleen worden vastgelegd in een BAA. De voorgestelde wijzigingen van 2025 versterken de toezichtvereisten voor business associates, waaronder jaarlijkse audits en strengere termijnen voor incidentmelding.

5. Auditlogs zijn verplichte infrastructuur, geen optionele rapportagefunctie.

De Audit Controls-standaard van de HIPAA Security Rule (45 C.F.R. § 164.312(b)) vereist dat covered entities en business associates mechanismen implementeren die activiteiten registreren en analyseren in systemen die ePHI bevatten. Dit zijn geen vrijblijvende vereisten — OCR-handhavingszaken noemen regelmatig onvolledige of ontbrekende auditlogging als schending van de Security Rule. Een audittrail die vastlegt wie wanneer, vanaf welk systeem, onder welke autorisatie en met welk resultaat toegang had tot PHI, is zowel het detectiemechanisme voor beveiligingsincidenten als het bewijsmateriaal dat naleving aantoont wanneer er een audit plaatsvindt.

Op wie is HIPAA van toepassing?

HIPAA is van toepassing op twee categorieën organisaties: covered entities en business associates.

Covered entities zijn zorgverleners die gezondheidsinformatie elektronisch verzenden (ziekenhuizen, artsenpraktijken, klinieken, apotheken), zorgverzekeraars (verzekeraars, HMO’s, werkgeversgefinancierde zorgplannen) en zorgverwerkingsinstanties (healthcare clearinghouses) die gezondheidsinformatie van het ene formaat naar het andere omzetten.

Business associates zijn organisaties die namens een covered entity functies of activiteiten uitvoeren waarbij PHI wordt gebruikt of vrijgegeven. Denk aan cloudserviceproviders die ePHI opslaan, managed service providers die zorg-IT-systemen beheren, factureringsbedrijven, transcriptiediensten, juridisch adviseurs, accountants en elk technologieplatform waarlangs PHI stroomt. Sinds de Omnibus Rule van 2013 lopen business associates hetzelfde boeterisico als covered entities bij overtredingen — de BA-status biedt geen nalevingsbuffer.

Organisaties die geen PHI aanmaken, ontvangen, bewaren of verzenden, vallen doorgaans niet onder HIPAA. Maar de drempel om als business associate te worden aangemerkt, ligt lager dan de meeste organisaties denken. Een cloudopslagprovider die versleutelde PHI host — zelfs zonder de mogelijkheid deze in te zien — is onder HIPAA een business associate en moet een BAA aangaan en passende waarborgen implementeren.

De Vier HIPAA-Regels

De Privacy Rule

De HIPAA Privacy Rule stelt nationale standaarden vast voor de bescherming van individueel identificeerbare gezondheidsinformatie — met een definitie van wat Protected Health Information (PHI) is, wie deze mag gebruiken of vrijgeven, onder welke omstandigheden, en welke rechten patiënten daarbij hebben.

PHI is elke informatie die betrekking heeft op de voorbije, huidige of toekomstige gezondheidstoestand van een individu, de verleende zorg, of de betaling voor zorg — en die het individu identificeerbaar maakt. De 18 HIPAA-identificatiegegevens variëren van namen en data tot geografische gegevens en apparaatidentificatoren. Geanonimiseerde gegevens — waaruit alle 18 identificatiegegevens zijn verwijderd volgens een goedgekeurde methode — vallen buiten het toepassingsgebied van HIPAA.

De Privacy Rule staat gebruik en vrijgave van PHI toe voor behandeling, betaling en zorggerelateerde bedrijfsvoering, zonder toestemming van de patiënt. Voor de meeste andere vormen van vrijgave is wél toestemming vereist. Patiënten hebben het recht om hun eigen PHI in te zien, wijzigingen aan te vragen, een overzicht van vrijgaven te ontvangen en beperkingen op het gebruik aan te vragen. De Minimum Necessary-standaard vereist dat covered entities en business associates de toegang tot PHI beperken tot wat noodzakelijk is voor elk specifiek doel — een vereiste die zowel geldt voor menselijke toegang als voor toegang door AI-systemen.

Voor een gedetailleerd overzicht van de Minimum Necessary-vereisten en de implementatie van rolgebaseerde toegang, zie HIPAA Minimum Necessary Rule: Complete Compliance Guide.

De Security Rule

De HIPAA Security Rule stelt nationale standaarden vast voor de bescherming van elektronische PHI (ePHI) — PHI die elektronisch wordt aangemaakt, ontvangen, bewaard of verzonden. De regel vereist dat covered entities en business associates administratieve, fysieke en technische waarborgen implementeren die de vertrouwelijkheid, integriteit en beschikbaarheid van ePHI garanderen.

Administratieve waarborgen zijn het beleid, de procedures en de trainingsprogramma’s die bepalen hoe een organisatie de beveiliging van ePHI beheert. Denk aan het security management-proces (risicoanalyse en risicobeheer), training van medewerkers, toegangsbeheer, noodplanning en toezicht op business associates. De Security Rule vereist een aangewezen Security Officer die verantwoordelijk is voor het ontwikkelen en implementeren van beveiligingsbeleid en -procedures.

Fysieke waarborgen regelen de toegang tot de fysieke systemen en locaties waar ePHI zich bevindt. Denk aan toegangscontrole tot gebouwen, beleid voor werkstationgebruik, beveiliging van werkstations, en controle op apparaten en media, waarmee wordt bepaald hoe elektronische media met ePHI worden gehanteerd, verplaatst en vernietigd.

Technische waarborgen zijn de technologiegebaseerde maatregelen die ePHI beschermen en de toegang ertoe beheersen. Denk aan toegangscontrole (unieke gebruikersidentificatie, automatische uitlogfunctie, encryptie en decryptie), auditcontrole, integriteitscontrole (om te voorkomen dat ePHI onterecht wordt gewijzigd of vernietigd) en transmissiebeveiliging (bescherming van ePHI die via elektronische communicatienetwerken wordt verzonden).

Voor een volledig overzicht van de technische waarborgen, zie HIPAA Security Rule Requirements and 2025 Updates.

De Breach Notification Rule

De HIPAA Breach Notification Rule verplicht covered entities om betrokken personen, HHS en in sommige gevallen de media te informeren na een datalek met onbeveiligde PHI. Business associates moeten de covered entity zonder onredelijke vertraging en uiterlijk binnen 60 dagen na ontdekking van een datalek op de hoogte stellen.

De meldingstermijn voor covered entities is strikt: betrokken personen moeten zonder onredelijke vertraging en uiterlijk binnen 60 dagen na ontdekking worden geïnformeerd. Datalekken die 500 of meer personen in één staat of rechtsgebied treffen, vereisen ook melding aan prominente media. Alle datalekken moeten aan HHS worden gemeld — datalekken met 500 of meer betrokkenen moeten binnen 60 dagen na ontdekking worden gemeld; kleinere datalekken mogen jaarlijks worden gerapporteerd.

PHI die op het moment van een datalek versleuteld was — en waarvan de encryptiesleutels veilig bleven — komt in aanmerking voor de veilige haven (safe harbor) van de Breach Notification Rule. Versleutelde gegevens worden beschouwd als ‘onbruikbaar, onleesbaar of niet te ontcijferen’ en leiden niet tot een meldingsplicht. Deze veilige haven is een van de belangrijkste praktische redenen om encryptie te implementeren: een datalek van correct versleutelde PHI is geen meldingsplichtig HIPAA-datalek. Voor een volledige analyse van deze veilige haven, zie AES-256 Encryption for HIPAA: Breach Safe Harbor Guide.

De Omnibus Rule

De Omnibus Rule van 2013 bracht verschillende structurele wijzigingen aan in HIPAA die nog altijd van kracht zijn. Het belangrijkste effect: volledige HIPAA-nalevingsverplichtingen en boeterisico’s werden uitgebreid naar business associates en hun onderaannemers — waarmee het aansprakelijkheidshiaat werd gedicht dat downstream-leveranciers voorheen toestond om onder minder strenge vereisten te opereren. Daarnaast werden patiëntrechten versterkt (waaronder het recht om kopieën op te vragen van ePHI in elektronische patiëntendossiers), werd het gebruik van PHI voor marketingdoeleinden beperkt, en werd de verkoop van PHI zonder toestemming van de patiënt verboden.

De Voorgestelde Security Rule-Wijzigingen van 2025

In januari 2025 stelde HHS de meest ingrijpende herziening van de HIPAA Security Rule sinds de oorspronkelijke publicatie voor. De voorgestelde wijzigingen zijn een reactie op de toename van datalekken en ransomware-aanvallen in de zorgsector, die de tekortkomingen hebben blootgelegd van de inconsistente toepassing van de ‘addressable’-classificatie uit de oorspronkelijke regel.

De kernwijziging: de voorgestelde amendementen schaffen het onderscheid tussen ‘required’ (verplichte) en ‘addressable’ (aan te pakken) implementatiespecificaties af. Onder de gewijzigde regel zouden de volgende waarborgen verplicht worden voor alle covered entities en business associates, zonder mogelijkheid tot een gedocumenteerd alternatief:

Encryptie van ePHI in rust en tijdens verzending. Zowel encryptie in rust (voor opgeslagen ePHI in databases, bestandssystemen en back-upmedia) als encryptie tijdens verzending (voor ePHI die via een elektronisch netwerk wordt verzonden) zou verplicht worden. De voorgestelde wijzigingen verwijzen naar FIPS-gevalideerde encryptiestandaarden — waarmee FIPS 140-3 gevalideerde cryptografische modules effectief de verplichte implementatiestandaard worden.

Multi-factor authenticatie. MFA zou verplicht worden voor alle toegang tot systemen met ePHI. Authenticatie op basis van alleen een wachtwoord zou niet langer voldoen aan de vereisten van de Security Rule.

Netwerksegmentatie. Covered entities en business associates zouden netwerkcontroles moeten implementeren die systemen met ePHI isoleren van andere netwerksegmenten — om laterale beweging bij een datalek te beperken.

Jaarlijkse inventarisatie van technologische assets. Organisaties zouden verplicht worden actuele overzichten bij te houden van alle technologische assets die toegang hebben tot, ePHI opslaan of verzenden — een fundamentele vereiste voor een nauwkeurige risicobeoordeling en incidentrespons.

Gedocumenteerde risicoanalyse met specifieke scope-vereisten. De voorgestelde wijzigingen maken de vereiste voor risicoanalyse specifieker, door te definiëren wat de analyse moet omvatten en organisaties te verplichten geïdentificeerde risico’s, hun waarschijnlijkheid en impact, en de geïmplementeerde beheersmaatregelen te documenteren.

Schriftelijke incidentrespons- en noodherstelplannen met hersteltijd van 72 uur. Organisaties zouden verplicht worden gedocumenteerde plannen bij te houden voor de respons op beveiligingsincidenten en het herstellen van systemen binnen 72 uur na een verstoring.

Jaarlijkse nalevingsaudits en verscherpt toezicht op leveranciers. De voorgestelde wijzigingen versterken de toezichtvereisten voor business associates, waaronder contractuele bepalingen voor jaarlijkse nalevingsverificatie.

Vanaf juli 2026 hebben deze wijzigingen nog altijd een voorgestelde status — het formele wetgevingsproces loopt nog. Organisaties doen er goed aan niet te wachten op de definitieve publicatie om met de implementatie te beginnen. De voorgestelde wijzigingen weerspiegelen hoe dan ook de handhavingsaanpak van OCR, en de HISAA-wetgeving van 2025, geïntroduceerd door senatoren Wyden en Warner, zou bij aanname nog strengere eisen opleggen. Voor de actuele status van deze voorstellen, zie HIPAA Security Rule Requirements and 2025 Updates.

HIPAA-Boetes en Handhaving

Overtredingen van HIPAA kunnen leiden tot civiele en strafrechtelijke sancties, die opschalen naarmate de overtreding ernstiger of opzettelijker is.

Civiele boetes zijn ingedeeld naar mate van kennis en verwijtbaarheid. Organisaties die zich niet bewust waren van een overtreding, krijgen een minimumboete van $100 per incident. Overtredingen met redelijke oorzaak maar zonder opzettelijke nalatigheid kennen een minimumboete van $1.000 per incident. Opzettelijke nalatigheid die wordt gecorrigeerd, kent een minimumboete van $10.000 per incident. Opzettelijke nalatigheid die niet wordt gecorrigeerd, kent een minimumboete van $50.000 per incident. De jaarlijkse maxima per boetecategorie liggen tussen $25.000 voor de laagste categorie en $1,5 miljoen voor de hoogste — al hanteert OCR dit maximum per kalenderjaar per type overtreding, waardoor meerjarige niet-naleving het risico aanzienlijk vermenigvuldigt.

Strafrechtelijke sancties gelden voor bewuste overtredingen en worden vervolgd door het Department of Justice. Het bewust verkrijgen of vrijgeven van PHI in strijd met HIPAA kan leiden tot boetes tot $50.000 en maximaal één jaar gevangenisstraf. Overtredingen onder valse voorwendselen verhogen dit maximum naar $100.000 en vijf jaar. Overtredingen met het oogmerk om PHI te verkopen, over te dragen of te gebruiken voor commercieel voordeel of persoonlijk gewin, kunnen leiden tot boetes tot $250.000 en maximaal tien jaar gevangenisstraf.

OCR richt zijn handhaving in toenemende mate op het volledige spectrum van de zorgsector — niet alleen op grote zorgsystemen, maar ook op artsenpraktijken, zorgverzekeraars en business associates. Corrective Action Plans die gepaard gaan met schikkingen leggen doorgaans meerjarige monitoringverplichtingen en verplichte verbeteringen van het nalevingsprogramma op, die veel verder reiken dan de oorspronkelijke boete.

Een HIPAA-Conforme Technische Architectuur Opbouwen

De technische vereisten van de Security Rule vertalen zich naar een specifieke set platformfunctionaliteiten die covered entities en business associates moeten implementeren. De kloof tussen losse tools die aan afzonderlijke vereisten voldoen en een geïntegreerde architectuur die ze allemaal tegelijk vervult, is waar de meeste organisaties nalevingsrisico opbouwen.

Encryptie over alle kanalen. ePHI verplaatst zich via meer kanalen dan de meeste organisaties beseffen: e-mail, bestandsdeling, managed file transfer, webformulieren, API-integraties en in toenemende mate AI-systemen die toegang hebben tot klinische gegevens. Elk kanaal moet AES-256-encryptie toepassen voor opgeslagen gegevens en minimaal TLS 1.2 (TLS 1.3 heeft de voorkeur) voor gegevens onderweg. Kanalen die sommige PHI-stromen wel versleutelen en andere niet, creëren hiaten in de veilige haven — een datalek van onversleutelde PHI via een onversleuteld kanaal leidt tot een meldingsplicht, ongeacht hoe goed andere kanalen beveiligd zijn. Voor een checklist voor audittrails, zie HIPAA Audit Logs: Complete Requirements.

Toegangscontrole die Minimum Necessary afdwingt. Technische toegangscontroles moeten de toegang tot ePHI beperken tot wat noodzakelijk is voor elk specifiek doel. Role-based access control (RBAC) bepaalt welke medewerkers toegang hebben tot welke PHI-categorieën. Attribute-based access control (ABAC) past dynamisch, contextgevoelig beleid toe dat Minimum Necessary afdwingt op het niveau van de individuele handeling — niet alleen op accountniveau. Unieke gebruikersidentificatie, automatische sessiebeëindiging en noodtoegangsprocedures zijn aanvullende technische vereisten.

Onveranderlijke auditlogging over alle systemen die ePHI verwerken. Auditlogs moeten elke toegangsgebeurtenis vastleggen — wie welke PHI heeft geraadpleegd, wanneer, vanaf welk systeem, onder welke autorisatie en welke actie is ondernomen. Logs moeten worden opgeslagen in een formaat dat achteraf niet kan worden gewijzigd. Organisaties met versnipperde logging over e-mailsystemen, platforms voor bestandsdeling, auditmodules van EPD’s en netwerkinfrastructuur, kunnen geen samenhangende audittrail opleveren voor OCR-onderzoek — daarom is geconsolideerde, kanaaloverschrijdende logging een praktische nalevingsvereiste, geen best practice die je kunt overslaan.

Technische governance voor business associates. Een BAA is wettelijk verplicht. Technische controles die bepalen tot welke PHI business associates toegang hebben, hun toegang loggen in dezelfde audittrail als interne gebruikers, en toegang intrekken zodra de relatie eindigt, zijn verplicht onder de Security Rule. De nalevingsverplichting volgt de data — PHI in de omgeving van een business associate blijft de nalevingsverantwoordelijkheid van de covered entity.

Voor het volledige implementatiekader in vijf stappen, zie 5 Steps to Achieve HIPAA Compliance.

Hoe Kiteworks HIPAA-Naleving Ondersteunt

Kiteworks is ontworpen voor de datagovernance-vereisten die HIPAA oplegt aan covered entities en business associates die ePHI verwerken via meerdere uitwisselingskanalen.

Op het gebied van encryptie: Kiteworks past AES-256-encryptie toe, zowel op bestandsniveau als op schijfniveau — dubbele encryptie — met FIPS 140-3 gevalideerde cryptografische modules. Klanteigen encryptiesleutels zorgen ervoor dat Kiteworks technisch niet in staat is om klantgegevens te decoderen. ePHI die via elk Kiteworks-kanaal wordt verzonden — beveiligde e-mail, beveiligde bestandsdeling, managed file transfer, SFTP, of beveiligde dataformulieren — wordt beschermd met minimaal TLS 1.2, met TLS 1.3 als optie. Correct versleutelde PHI op het Kiteworks-platform komt in aanmerking voor de meldingsplicht-veilige-haven van HIPAA.

Op het gebied van toegangscontrole: Kiteworks handhaaft zowel RBAC- als ABAC-beleid via een geïntegreerde Data Policy Engine. Toegang wordt beheerd per bestand, per map en per gebruiker — met handhaving van Minimum Necessary op het niveau van de individuele handeling. Externe ontvangers (business associates, doorverwijzende partners, patiënten die hun eigen dossiers raadplegen) worden geauthenticeerd voordat toegang wordt verleend. Toegang kan achteraf worden ingetrokken. SafeVIEW alleen-lezen-toegang maakt het mogelijk PHI te delen voor beoordeling zonder dat deze de Kiteworks-omgeving verlaat.

Op het gebied van auditlogging: elke toegangsgebeurtenis over elk Kiteworks-kanaal wordt vastgelegd in één geconsolideerde, onveranderlijke audittrail. Het log registreert wie wanneer, vanaf welk systeem, onder welke autorisatie en met welke actie toegang had — over e-mail, bestandsdeling, MFT, SFTP, beveiligde formulieren en AI-gegevenstoegang. De audittrail is SIEM-geïntegreerd en beschikbaar in HIPAA-specifieke nalevingsrapportages. Dit is de audit-infrastructuur die voldoet aan de Audit Controls-standaard van de Security Rule en die OCR-bestendig onderzoek naar datalekken ondersteunt.

Op het gebied van naleving door business associates: Kiteworks ondertekent Business Associate Agreements als business associate en beschikt over FedRAMP Moderate-autorisatie — een onafhankelijk beoordeeld en continu gemonitord beveiligingsniveau dat covered entities een documenteerbare basis biedt voor due diligence bij business associates, verder gaand dan de contractuele BAA.

Voor AI-specifieke HIPAA-vereisten, waaronder hoe de Security Rule-wijzigingen van 2025 van toepassing zijn op AI-agents die toegang hebben tot ePHI, zie AI Agents and HIPAA: Solving the PHI Access Challenge.

Wilt u zien hoe Kiteworks aansluit op uw specifieke HIPAA-nalevingsomgeving? Plan een demo op maat.