1. Kort fortalt
#FlowDule er en B2B SaaS-platform, hvor behandlere og klinikker arbejder med klient-, journal- og helbredsoplysninger. Oplysningerne er private, og sikkerhedsniveauet er lagt derefter. Her kan du og jeres rådgiver se, hvad vi gør, og hvad I selv står for.
Beskrivelsen er et overblik. Den indeholder ikke credentials, netværksdetaljer, kendte sårbarheder eller kundespecifikke opsætninger. Det bindende sikkerhedsniveau står i den databehandleraftale, I har accepteret, og i det versionsbundne TOMS-bilag.
Sikkerhedsarbejdet hviler på fire ting:
- fortrolighed: kun identificerede og bemyndigede personer og systemer får den adgang, opgaven kræver;
- integritet: ændringer, delinger, sletninger og administrative handlinger kan følges bagefter;
- tilgængelighed og robusthed: kritiske data og funktioner kan gendannes;
- databeskyttelse gennem design og standardindstillinger: mindst mulig adgang, mindst mulige data, mindst mulig deling og opbevaring og færrest mulige tredjeparter er udgangspunktet.
Vi afprøver og vurderer foranstaltningerne regelmæssigt.
2. Ansvarsfordeling
#| Part | Primært sikkerhedsansvar |
|---|---|
| FlowDule | Platform, kode, cloudmiljø, sikker konfiguration, interne adgange, leverandører, support, backup/gendannelse, hændelseshåndtering og bistand til kunden. |
| Kunden | Lovligt formål, bruger- og behandlingsrelationer, korrekt faglig profil, lokale enheder og netværk, brugeradministration, delinger, retention, kontrol af opslag og lokale nødprocedurer. |
| Brugeren | Personlig konto, beskyttelse af login og enheder, dataminimering, korrekt brug, kontrol af AI-output og hurtig rapportering af mistanke. |
| Underdatabehandleren | De aftalte sikkerheds- og databeskyttelsesforpligtelser for den konkrete tjeneste og konfiguration. FlowDule fører risikobaseret kontrol. |
Jeres ansvar begrænser ikke vores ansvar for vores egne foranstaltninger. Og vores sikkerhed fjerner ikke jeres pligt til at vælge en passende opsætning og følge med i, at jeres egne brugere har lovlig adgang.
3. Infrastruktur og miljøer
#FlowDules produktion drives hos Kinsta (Sevalla) i Google Clouds datacentre: API, database, webapp og bookingsider; databasen ligger i Frankfurt. Cloudflare leverer edge og TLS foran platformen og objektlager (Cloudflare R2) til medier og databasebackup. AWS (EU) anvendes til login, e-mail, AI-tjenester og nøglehåndtering. Den aktuelle oversigt over leverandører, tjenester og regioner fremgår af Underdatabehandlere og leverandører.
Udvikling, staging og produktion er adskilte miljøer. Produktion bruger vi ikke til afprøvning, og vi kopierer ikke rigtige klient- og journaldata til udvikling eller almindelig afprøvning. Der bruger vi opdigtede oplysninger eller oplysninger, der på anden måde lovligt er godkendt og minimeret til formålet.
4. Identitet og adgang
#Brugerne logger ind med personlige konti via AWS Cognito, ikke med delte loginoplysninger. Adgangen følger rollen og relationen efter mindste privilegium, så en bruger ser kun det, rollen i kæden og på lokationen giver adgang til.
FlowDules egne platformsbrugere logger ind med multifaktorgodkendelse. Jeres egne brugere kan selv slå den til på deres konto. Adgangstokens valideres centralt og har begrænset levetid.
Vi lukker en adgang, når en person fratræder, når en konto er kompromitteret, eller når arbejdsbehovet falder væk, og vi ser de brede og privilegerede adgange efter med jævne mellemrum.
Vores support åbner kun jeres indhold i en konkret sag, efter den nødvendige godkendelse, med personligt login, i kortest mulig tid og med logning. Der findes ikke en skjult permanent administratorrolle.
5. Kunde- og dataseparation
#FlowDule er en multi-tenant platform: flere kunder deler den samme platform. Kundeadskillelsen håndhæves i de relevante lag, i appen, i api’et, i applikationslogikken, i databasen og i filadgangen. I databasen sker det med row-level security. Adskillelsen afprøves også med forsøg på adgang på tværs af kunder, lokationer og roller.
Adgang afgøres af kædetilhørsforhold, rolle, lokation og den konkrete arbejds- eller behandlingsrelation. En bruger får ikke adgang til en klient alene, fordi brugeren hører til samme kunde, hvis den valgte kundemodel bygger på en snævrere relation. Det samme princip gælder for privilegerede database- og supportveje.
6. Kryptering og hemmeligheder
#Trafikken mellem jer og platformen krypteres med TLS. Følsomme journalfelter krypteres desuden på feltniveau med nøgler, der håndteres i AWS KMS.
Credentials, tokens, krypteringsnøgler og andre hemmeligheder ligger ikke i kildekode, i almindelige logs eller på skærmen. Adgang til dem gives efter behov, registreres og roteres ved kompromittering og efter nøgleplanen.
Detaljer om krypteringen og adgangen til nøgler giver vi kun efter behov og gennem en sikker kanal.
7. Logning og opfølgning på adgang
#Handlinger med klient- og journaldata kan spores til en navngiven bruger eller en entydig systemkomponent. Afhængigt af risikoen omfatter det blandt andet læsning, søgning, oprettelse, ændring, download, eksport, deling, tilbagekaldelse, sletning og administrative handlinger med udvidede rettigheder.
Logs indeholder den sammenhæng, der skal til for at undersøge en handling, men ikke journaltekst, adgangskoder eller tokens. De er beskyttet mod ændring og uautoriseret læsning, gemmes i en fast periode og slettes derefter automatisk. Opfølgning på logs er saglig, begrænset til et formål og adgangsbegrænset.
Opslag i journaler logges. Vi har automatiske alarmer ved fejl, ved mislykkede skrivninger til revisionsloggen, ved masseopslag i journaler og når en ny platformsejer oprettes. Alarmerne samles i en e-mail, og de kritiske eskaleres desuden via sms.
I følger selv op på, om jeres egne brugeres opslag er arbejdsbetingede. Vi leverer funktionen og den aftalte bistand.
8. Udvikling og ændringer
#Ændringer gennemgår automatiske test og kodegennemgang, før de frigives. Afhængighederne i api’et overvåges automatisk med Dependabot, som advarer om nye versioner og foreslår opdateringer. Finder vi et kritisk forhold, blokerer vi, begrænser eller tilbagefører ændringen. Ændringer i dataflow, adgang, netværk, kryptering, logning, opbevaring, regioner og leverandører vurderes for risiko først, og de kan rulles tilbage.
9. Filer og skadeligt indhold
#Vi begrænser uploads efter filtype, størrelse, filsignatur og den funktion, filen hører til. Hverken filen eller dens metadata giver vej uden om kundeadskillelsen, adgangsreglerne eller den sikre filvisning.
Uploadede filer virusscannes ikke.
10. Leverandører og overførsel
#Før en leverandør modtager personoplysninger, ser vi på:
- leverandørens juridiske rolle, tjenesten, de oplysninger, den behandler, og de registrerede;
- aftalegrundlaget, herunder databehandleraftalen og de relevante sikkerhedsgarantier;
- behandlingslande, fjernsupport og underleverandørkæden;
- adgang, kryptering, logs, opbevaring, sletning, hændelser og exit;
- et eventuelt overførselsgrundlag og de supplerende foranstaltninger.
Vi indgår en databehandleraftale med de nødvendige sikkerhedsgarantier.
Hosting i EU udelukker ikke i sig selv overførsel til tredjelande, for eksempel via fjernsupport eller en leverandør uden for EU. Videomodulet anvender LiveKit (USA); sessionerne er ikke bundet til EU, og overførslen sker efter LiveKits databehandlertillæg, som er en del af LiveKits vilkår: EU-US Data Privacy Framework, hvor LiveKit er certificeret, ellers EU’s standardkontraktbestemmelser. Den aktuelle leverandøroversigt findes i Underdatabehandlere og leverandører.
11. Backup, gendannelse og kontinuitet
#Databasen sikkerhedskopieres dagligt til Cloudflare R2 med 30 dages rotation. Som led i gendannelsesproceduren skal gendannelse afprøves i et isoleret miljø, og registrerede sletninger og legal holds skal genanvendes, før miljøet åbnes.
FlowDule lover ikke bestemte RPO-, RTO-, backup- eller oppetidsmål, medmindre de er udtrykkeligt aftalt i et SLA. Jeres lokale nødprocedure skal kunne fungere uden usikre private e-mails, chats, delte dokumenter eller uautoriserede enheder.
Efter en gendannelse gennemgår vi, at data er teknisk fuldstændige. I gennemgår jeres egne kritiske faglige oplysninger og efterregistrerer det, der mangler, så det kan spores.
12. Sikkerhedshændelser og persondatabrud
#Mistanke om tab af fortrolighed, integritet eller tilgængelighed behandler vi som en sikkerhedshændelse. Vi registrerer, begrænser og undersøger den og gemmer det nødvendige materiale uden at lave unødvendige kopier af følsomt indhold.
Vedrører et brud på persondatasikkerheden jeres oplysninger, underretter vi jer uden unødig forsinkelse og giver jer de oplysninger, vi har, efterhånden som vi har dem. I beslutter som dataansvarlig, om bruddet skal anmeldes til tilsynsmyndigheden, og om de registrerede skal informeres. Vores egen proces forsinker ikke jeres frist.
Har du mistanke om en sikkerhedshændelse, så skriv straks til security@flowdule.com. Almindelige supportspørgsmål sender du til support@flowdule.com.
13. Opbevaring, sletning og legal hold
#Jeres opbevaringsprofil følger faggruppe, land, datakategori og formål. Vi lægger ikke automatisk en sundhedsretlig journalfrist på selvstændige psykoterapeuter, der ikke er omfattet af den særregel.
En sletning omfatter de relevante databaser, filer, delinger, køer, caches, eksportfiler og andre aktive kopier. Sikkerhedskopier udfases gennem den løbende rotation. Indtil de udløber, er de beskyttet og bruges ikke til andet.
Legal hold bruger vi kun ved en konkret pligt, en tvist eller en lovlig instruks. Det afgrænses til de nødvendige personer, objekter og datakategorier, vurderes med jævne mellemrum og ophæves sporbart.
14. AI-sikkerhed
#AI-funktionerne i journalen er en del af journalmodulet og ikke en generel adgang til jeres data. De er tilgængelige for kædens brugere efter deres rolle; der er ikke et særskilt aktiveringstrin for hver enkelt AI-funktion. Model, data, regioner, opbevaring og leverandører fremgår af AI-informationen, jeres data bruges ikke til at træne AI-modeller, og vi kan straks slå en funktion eller model fra ved alvorlige eller gentagne fejl.
AI-output, der skal bruges i journalen eller over for en klient, er et udkast. En fagperson skal gennemgå kilde, fakta, negationer, tal, datoer, person og faglig sammenhæng, før resultatet gemmes eller deles. Nogle resultater godkendes ikke enkeltvis, blandt andet den automatiske notatfeedback og maskinoversættelsen af delt indhold for klienten. FlowDules AI træffer ikke selv diagnose-, triage-, behandlings- eller adgangsafgørelser.
Yderligere information findes i AI-information.
15. Træning og fortrolighed
#Alle med intern eller privilegeret adgang har tavshedspligt. De bliver instrueret, før de får adgang, og derefter med jævne mellemrum i blandt andet phishing, credentials, journaldata, supportadgang, logning, hændelser, AI og straksrapportering.
Vi registrerer, hvem der har adgang, og hvornår de er instrueret. Bevidst misbrug, deling af credentials, omgåelse af sikkerhedsregler eller fortielse lukker adgangen med det samme og kan få ansættelses- eller kontraktretlige følger.
16. Dokumentation, audit og kunder
#I kan få dokumentation og gennemføre audit efter Databehandleraftalen. Udgangspunktet er det TOMS-bilag, I har accepteret, resultater af vores egne afprøvninger, leverandørernes egen dokumentation og eventuelle uafhængige erklæringer. Oplysninger, der kan svække sikkerheden eller andre kunders fortrolighed, giver vi kun videre gennem en sikker og fortrolig proces.
17. Begrænsning af offentlige løfter
#Denne beskrivelse er ikke et SLA og giver ikke i sig selv garanti for bestemt oppetid, gendannelsestid, datatabsgrænse eller certificering. FlowDule er ikke ISO 27001- eller SOC 2-certificeret.
Hvis teksten afviger fra det accepterede, versionsbundne TOMS-bilag, har TOMS-bilaget forrang for den konkrete kunde. En senere forbedring ændrer ikke stiltiende kundens aftalte instruks eller sikkerhedsniveau.
18. Retskilder
#Trust Center forklarer sikkerhed og GDPR i almindeligt sprog: Gå til Trust Center. Alle gældende dokumenter har dato og version: Se alle dokumenter.